从/system/framework/arm/boot.oat启动的Android本机崩溃



最近在Google Play中更新了我的应用程序后,我开始收到很多崩溃报告,所有这些报告都来自安卓5的三星设备。较低的安卓版本运行良好,其他制造商的安卓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没有报告任何问题。同样的代码在其他安卓设备、IOS和Linux上运行时没有任何崩溃。它没有显示出任何错误。所以我认为一些随机内存损坏是不可能的。

我认为我的Java代码是可以的,但即使它有错误,也不应该在Java运行时导致segfault。。。

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


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


我有两个问题:

  • 回溯从boot.oat开始,在libart.so中继续。boot.oat中发生了什么?它是否可能在到达我的任何代码之前就崩溃了?(这表明三星的ART存在漏洞。)

  • 知道哪里出了问题吗?我能试什么?

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

完全相同的APK在与Zopfli对齐并重新压缩时崩溃,而在未重新压缩的情况下对齐时不会崩溃。

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

最新更新