Steps to reproduce:
0. Open attached project "Project.zip"
1. Build and deploy a development build on an Android device (we used a Samsung Galaxy S7)
2. Run the demo and connect the Unity profiler
3. Record in the profiler until the terrain is fully loaded (it’s an area of 7x7 sections and it takes 2-3 seconds to load)
4. Stop the recording and load the data into Profile Analyzer (to help us identify the frame where the issue occurs)
5. In the “Name Filter” section of the Profile Analyzer write “UpdateNavMeshDataAsync”
6. If the issue occurred, you should be able to see in the “Marker Summary” section that one or more frames took a considerable amount of time more than the rest. If this didn’t happen, you will need to run the demo again and capture new data.
7. By selecting the identified frames in the Profiler, you should see that inside the marker “UpdateNavMeshDataAsync” there is a call to “NavMesh.AcquireSharedMesh” and then a gap for several msecs. (UpdateNavMeshDataAsync should be at the beginning or the end of the frame).

Expected: There should be no spikes in frame time on any of the UpdateNavMeshDataAsync calls
Actual: One or more frames takes up more time than the others by a factor of 6x-7x~

Reproduced on: 2019.3.9f1, 2020.1.0b5
Couldn't open project on 2019.1, too many errors

Devices Under Test:
VLNQA00264, Samsung Galaxy S10+ (SM-G975F), Android 10, CPU: NOT FOUND, GPU: Mali-G76
N/A, Samsung Galaxy Fold (SM-F900F), Android 9, CPU: Snapdragon 855 SM8150, GPU: Adreno (TM) 640
N/A, Samsung Galaxy S20+ 5G (SM-G986B), Android 10, CPU: NOT FOUND, GPU: Mali-G77
VLNQA00165, Samsung Galaxy S7 (SM-G930F), Android 7.0, CPU: Exynos 8 Octa 8890, GPU: Mali-T880