Android 从 /system/framework/arm/boot.oat 发起的本机崩溃

Android native crash initiating from /system/framework/arm/boot.oat

最近在 Google Play 中更新我的应用程序后,我开始收到很多崩溃报告,所有这些都来自带有 Android 5 的三星设备。较低的 android 版本可以工作很好,其他制造商的 Android 5 的设备也可以正常工作。

我没有任何可以重现问题的设备,所以我无法对分。我试图从崩溃报告和自上一个工作版本(不幸的是很长)以来的更改列表中推断出可能有什么问题。

所有崩溃报告如下所示(只是地址因设备而异):

Build fingerprint: 'samsung/kltektt/kltektt:5.0/LRX21T/G900KKTU1BOB1:user/release-keys'
Revision: '15'
ABI: 'arm'
pid: 26265, tid: 26265, name: mt.AnnelidsDemo >>> cz.gdmt.AnnelidsDemo <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x76f57e84
r0 00000800 r1 0000004b r2 b4aa9f9a r3 00000000
r4 1426e019 r5 76f57e80 r6 0000012c r7 76e6b040
r8 00000019 r9 76f57d54 sl 000007ff fp b4e1b330
ip b4aa9f70 sp bea94b50 lr b4bc72c1 pc b4c0d9b8 cpsr 00070030

backtrace:
#00 pc 001099b8 /system/lib/libart.so (art::TypeLookupTable::Lookup(char const*) const+59)
#01 pc 000c32bd /system/lib/libart.so (art::ClassLinker::LookupClassFromImage(char const*, art::gc::space::ImageSpace*)+64)
#02 pc 000d27c1 /system/lib/libart.so (art::ClassLinker::DefineClass(char const*, art::Handle<art::mirror::ClassLoader>, art::DexFile const&, art::DexFile::ClassDef const&)+320)
#03 pc 000d2d89 /system/lib/libart.so (art::ClassLinker::FindClassInPathClassLoader(art::ScopedObjectAccessAlreadyRunnable&, art::Thread*, char const*, art::Handle<art::mirror::ClassLoader>)+452)
#04 pc 001fe20b /system/lib/libart.so (art::VMClassLoader_findLoadedClass(_JNIEnv*, _jclass*, _jobject*, _jstring*)+254)
#05 pc 0001b179 /system/framework/arm/boot.oat

我发现 art::TypeLookupTable 是三星对 ART 的修改,没有可用的资源。

这个版本和上一个工作版本都是使用相同的 android SDK 和 NDK 构建的(目标是 android-19),Java 代码没有变化,有本机代码和数据有很多变化。我在构建本机代码时开始使用 LTO。我开始使用 zipalign.

-z (Zopfli) 参数

我的应用程序使用 JNI,所以这可能是第一个怀疑对象。但是 CheckJNI 没有报告任何问题。相同的代码在其他 Android 设备、IOS 和 Linux 上运行清晰,没有任何崩溃。它在 valgrind 中没有显示任何错误。所以我认为不太可能出现随机内存损坏。

我认为我的 Java 代码没问题,但即使它有错误,也不应该在 java 运行时导致段错误...

用户报告应用程序在启动期间崩溃,甚至还没有显示任何内容。


我在三星开发者论坛上问过,到目前为止没有任何回应。


我有两个问题:

与另一位在他的应用程序中遇到同样崩溃的开发人员一起,我们发现它是由 zipalign 工具的 -z 参数触发的。 (使用 Zopfli 重新压缩)

完全相同的 APK 在使用 Zopfli 对齐和重新压缩时会崩溃,而在对齐而不重新压缩时不会崩溃。

我只能猜测三星对 Android 5 进行了一些修改,并在读取 APK 的代码中引入了一些奇怪的错误。在解决这个问题或者我有更好的解释之前,不使用 zipalign 中的 -z 可以解决问题。