从/system/framework/arm/boot.oat引发的Android本机崩溃
在最近更新了我在Google Play中的应用程序后，我开始收到大量的崩溃报告，它们都来自三星( Samsung )的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和NDK构建的(目标是Androd-19)，Java代码没有变化，本机代码和数据也有很多变化。在构建本机代码时，我开始使用LTO。我开始使用-z (Zopfli)参数的zipalign。
我的应用程序使用JNI，所以这可能是第一个嫌疑人。然而，CheckJNI没有报告任何问题。同样的代码在其他Android设备上、IOS和Linux上都没有崩溃。它没有显示出任何错误在英勇。所以我认为一些随机的记忆破坏是不可能的。
我认为我的Java代码是可以的，但是即使它有错误，它也不应该在java运行时导致分段错误.
用户报告说，应用程序在开始时崩溃，甚至在显示任何内容之前。
我问过三星开发者论坛，到目前为止没有任何回应。
我有两个问题：
- 回溯从boot.oat开始，在libart.so中继续。在boot.oat发生了什么？它有可能在到达我的代码之前就崩溃了吗？(这表明三星的技术存在缺陷。)
- 知道有什么不对吗，我能尝试什么？
回答 1
Stack Overflow用户
发布于 2015-05-29 17:36:38
与另一个在应用程序中遇到相同崩溃的开发人员一起，我们发现它是由-z参数zipalign工具触发的。(使用Zopfli的Recompress)
完全相同的APK会在Zopfli对齐和重新压缩时崩溃，而在对齐时不会崩溃而不需要重新压缩。
我只能猜测三星对Android 5做了一些修改，并在读取APK的代码中引入了一些奇怪的bug。除非这是固定的，否则我有更好的解释，不使用-z在zipalign中解决问题。
https://stackoverflow.com/questions/29628901
复制相似问题
腾讯云开发者
