Heremaps原生崩溃(SIGABRT)

Question

我们正在调查另一个团队开发的一个与HereMaps (这里是SDK导航版，navigate-4.10.2.0.7878)相关的本机崩溃应用程序，这个堆栈跟踪：

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> com.mydomain.myapp <<<

backtrace:
  #00  pc 0000000000051010  /apex/com.android.runtime/lib64/bionic/libc.so (abort+164)
  #00  pc 0000000000e0143c  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 0000000000e0158c  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 0000000000e014f4  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 0000000000e01478  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 0000000000debfe4  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 000000000144cc84  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 00000000014035bc  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 00000000013fa668  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 000000000155cff0  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 00000000011273f8  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so (Java_com_here_sdk_navigation_VisualNavigator_disposeNativeHandle+480)
  #00  pc 0000000000042020  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.odex (art_jni_trampoline+96)
  #00  pc 000000000020988c  /apex/com.android.art/lib64/libart.so (nterp_helper+1948)
  #00  pc 0000000000b6999c  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.sdk.navigation.VisualNavigator.access$000)
  #00  pc 0000000000209124  /apex/com.android.art/lib64/libart.so (nterp_helper+52)
  #00  pc 0000000000b69974  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.sdk.navigation.VisualNavigator$1.disposeNative)
  #00  pc 0000000000073c6c  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.odex (com.here.NativeBase$DisposableReference.dispose+156)
  #00  pc 000000000020a0a0  /apex/com.android.art/lib64/libart.so (nterp_helper+4016)
  #00  pc 00000000009a3834  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase.cleanUpQueue+26)
  #00  pc 0000000000209124  /apex/com.android.art/lib64/libart.so (nterp_helper+52)
  #00  pc 00000000009a380e  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase.access$100)
  #00  pc 0000000000209124  /apex/com.android.art/lib64/libart.so (nterp_helper+52)
  #00  pc 00000000009a37be  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase$DisposableReference.<init>+22)
  #00  pc 000000000020a044  /apex/com.android.art/lib64/libart.so (nterp_helper+3924)
  #00  pc 00000000009a37ca  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase$DisposableReference.<init>)
  #00  pc 000000000020a748  /apex/com.android.art/lib64/libart.so (nterp_helper+5720)
  #00  pc 00000000009a37fc  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase.<init>+28)
  #00  pc 000000000020a044  /apex/com.android.art/lib64/libart.so (nterp_helper+3924)
  #00  pc 00000000009ac7f8  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.sdk.core.threading.RunnableImpl.<init>+10)
  #00  pc 00000000002cdd64  /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+548)
  #00  pc 00000000003d5660  /apex/com.android.art/lib64/libart.so (art::JNI<false>::CallNonvirtualVoidMethodV(_JNIEnv*, _jobject*, _jclass*, _jmethodID*, std::__va_list)+492)
  #00  pc 00000000003d4ab4  /apex/com.android.art/lib64/libart.so (art::JNI<false>::NewObjectV(_JNIEnv*, _jclass*, _jmethodID*, std::__va_list)+736)
  #00  pc 0000000000e0e858  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 0000000000e37fac  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 0000000000e37a5c  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 000000000140dad0  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 000000000144c5e8  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 000000000144d2bc  /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
  #00  pc 00000000000b2fd0  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+264)
  #00  pc 0000000000052834  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)

编辑：

在代码中进行了一些重构和清理操作之后，我们已经达到了一个干净的状态，在这种情况下，我们确信没有任何泄漏；我们已经使用LeakCanary来调查和删除所有这些漏洞，但是它仍然存在。

因此，我们尝试返回到basis，我们从github中克隆了github导航示例，我们发现在导航样本中没有任何本机崩溃，但是在整个应用程序中，使用HEREMaps实例引用的活动也是唯一的。

为了复制类似的用例，我们在示例的MainActivity之前添加了一个活动，并尝试启动该活动并返回到第一个活动，以显示库在资源释放方面的行为。

只有从一开始就打开和关闭MainActivity也没有任何本机崩溃，因为VisualNavigator (它似乎是回溯中有本机崩溃的类)由它的委托(也就是监听器) => setupListeners() in NavigationExample保留。因此，当MainActivity调用onDestroy时，我们还删除了所有侦听器，通过这种方式，我们看到了与应用程序相同的本机崩溃，从MainActivity返回到启动。

注意:为了始终能够再现本机崩溃，我们使用LeakCanary，因为库会在MainActivity被销毁时强制GC；如果删除它，GC操作将由系统随机执行。

链接：

1. 我们的版本的HEREMaps导航SDK示例被修改以在github上再现本机崩溃
2. 样本的崩溃视频：https://youtube.com/shorts/edY-TRvWh3I

因此，这里的最大问题是:我们实现了错误的HEREMaps SDK集成(以及管理实例发布)，还是本机崩溃在库中，必须由库所有者修复？

Answer 1

尝试找到一种使VisualNavigator持久的方法:使用StopRendering()可以，但不要使VisualNavigator为空。

当取消路由太快的时候，我不得不经历同样的问题，尽管它比最近的更新更糟糕，只是在停止导航时崩溃了，这修复了它。

Answer 2

在这里的SDK开发人员指南中，有一章展示了如何使用停止导航。建议将其命名为stopRendering()。在您的示例应用程序中，当中间活动被破坏时，您似乎不会调用visualNavigator.stopRendering()。试着叫它。

在设备的developer options菜单中，您可以打开“不要保持活动”来模拟这样的场景。