0

I'm working on a project for a client where I have to update the existing Android MapBox SDK (5.1.3) to the latest MapBox SDK (5.5.0). The application worked perfectly fine on the older SDK but as soon as I updated the SDK, my application freezes, showing a white screen and/or blocking my entire UI thread resulting in an ANR after a delay.

//Mapbox
implementation('com.mapbox.mapboxsdk:mapbox-android-sdk:5.5.0@aar') {
    transitive = true
}
implementation('com.mapbox.mapboxsdk:mapbox-android-services:2.2.10@aar') {
    transitive = true
}

My logcat only shows the below error when the application shows the ANR:

Thread[3,tid=28995,WaitingInMainSignalCatcherLoop,Thread*=0xaa430300,peer=0x12c638b0,"Signal Catcher"]: reacting to signal 3 03-07 16:20:53.831 28989-28995/package.name I/art: Wrote stack traces to '/data/anr/traces.txt'

And this is the stacktrace:

----- pid 28989 at 2018-03-07 16:20:53 -----
Build fingerprint: 'lge/g3_global_com/g3:6.0/MRA58K/15351124649f4:user/release-keys'
ABI: 'arm'
Build type: optimized
Zygote loaded classes=4378 post zygote classes=1932
Intern table: 42456 strong; 201 weak
JNI: CheckJNI is on; globals=636 (plus 174 weak)
Libraries: /data/app/package/lib/arm/libmapbox-gl.so /system/lib/libandroid.so /system/lib/libcompiler_rt.so /system/lib/libjavacrypto.so /system/lib/libjnigraphics.so /system/lib/libmedia_jni.so /system/lib/libwebviewchromium_loader.so libjavacore.so libopenjdk.so (9)
Heap: 40% free, 5MB/8MB; 46716 objects
Dumping cumulative Gc timings
Start Dumping histograms for 2 iterations for partial concurrent mark sweep
ProcessMarkStack:       Sum: 27.538ms 99% C.I. 0.021ms-23.012ms Avg: 4.589ms Max: 23.259ms
SweepMallocSpace:       Sum: 10.491ms 99% C.I. 0.027ms-6.440ms Avg: 2.622ms Max: 6.444ms
UpdateAndMarkImageModUnionTable:        Sum: 9.937ms 99% C.I. 3.536ms-6.401ms Avg: 4.968ms Max: 6.401ms
MarkConcurrentRoots:    Sum: 6.869ms 99% C.I. 0.006ms-5.420ms Avg: 1.717ms Max: 5.443ms
MarkAllocStackAsLive:   Sum: 4.808ms 99% C.I. 1.282ms-3.526ms Avg: 2.404ms Max: 3.526ms
MarkRootsCheckpoint:    Sum: 3.898ms 99% C.I. 312us-1672us Avg: 974.500us Max: 1672us
ScanGrayAllocSpaceObjects:      Sum: 2.394ms 99% C.I. 1us-1776us Avg: 598.500us Max: 1793us
UpdateAndMarkZygoteModUnionTable:       Sum: 2.344ms 99% C.I. 0.209ms-2.131ms Avg: 1.172ms Max: 2.135ms
SweepLargeObjects:      Sum: 1.729ms 99% C.I. 294us-1435us Avg: 864.500us Max: 1435us
ScanGrayImageSpaceObjects:      Sum: 1.191ms 99% C.I. 285us-906us Avg: 595.500us Max: 906us
ReMarkRoots:    Sum: 1.064ms 99% C.I. 283us-781us Avg: 532us Max: 781us
EnqueueFinalizerReferences:     Sum: 732us 99% C.I. 30us-702us Avg: 366us Max: 702us
SweepSystemWeaks:       Sum: 710us 99% C.I. 205us-505us Avg: 355us Max: 505us
FinishPhase:    Sum: 231us 99% C.I. 80us-151us Avg: 115.500us Max: 151us
ImageModUnionClearCards:        Sum: 220us 99% C.I. 28us-99us Avg: 55us Max: 99us
(Paused)ScanGrayAllocSpaceObjects:      Sum: 206us 99% C.I. 0.333us-190us Avg: 51.500us Max: 190us
MarkNonThreadRoots:     Sum: 183us 99% C.I. 19us-79us Avg: 45.750us Max: 79us

What exactly changed that might crash the application? Did anyone else experience this issue?

Verhelst
  • 1,492
  • 2
  • 22
  • 46

1 Answers1

1

Make sure that MapView.onDestroy is not called before MapView.onStop, since that will cause a freeze in mapbox versions after 5.1.5. Earlier you got away with that contract error.

For example: There is a Fragment containing the mapbox.MapView. If the Activity does not call Fragment.detach before attaching/replacing with a new Fragment, then the MapView will not get the onPause and onStop calls before onDestroy.

That was the case for me anyway, the app freezed in MapView.onDestroy after reloading the map from the app's NavigationDrawer menu. Adding call to detach solved it for me:

    if (mMapboxFragment != null) {
        // results in calls to fragment's: onPause(), onStop() and onDestroyView():
        FragmentManager fragMgr = getSupportFragmentManager();
        fragMgr.beginTransaction().detach(mMapboxFragment).commit();
    }
solgule
  • 51
  • 2