Android natives Crash-Initiierung von /system/framework/arm/boot.oat

Question

Nach der letzten Aktualisierung meiner Anwendung in Google Play, erhielt ich viele Absturzberichte, alle von Samsung-Geräten mit Android 5. Niedrigere Android-Versionen funktionieren gut und Geräte anderer Hersteller mit Android 5 funktionieren auch.

Ich habe kein Gerät, wo ich das Problem reproduzieren könnte, so dass ich nicht halbieren kann. Ich versuche herauszufinden, was aus dem Absturzbericht und aus der Liste der Änderungen seit meiner letzten Arbeitsversion (die leider lang ist) schief gehen könnte.

Alle Crash-Berichte sehen wie folgt aus (nur die Adressen leicht variieren zwischen Geräten):

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 

Ich fand heraus, dass die art::TypeLookupTable ist Samsungs Modifikation von ART und es gibt keine Quellen zur Verfügung.

Sowohl diese als auch die letzte funktionierende Version sind mit dem gleichen Android SDK und NDK (Ziel ist Android-19), es gibt keine Änderungen in Java-Code, gibt es viele Änderungen in nativen Code und in Daten. Ich begann LTO zu verwenden, wenn ich nativen Code zusammenstellte. Ich begann mit -z (Zopfli) -Parameter von zipalign.

Meine Anwendung verwendet JNI, so dass dies wahrscheinlich der erste Verdächtige ist. CheckJNI meldet jedoch keine Probleme. Der gleiche Code läuft klar und ohne Abstürze auf anderen Android-Geräten, auf IOS und Linux. Es zeigt keine Fehler in Valgrind. Ich denke also, dass zufällige Speicherkorruption unwahrscheinlich ist.

Ich glaube, mein Java-Code ist in Ordnung, aber selbst wenn es Fehler hat, soll es nicht segfault in Java Runtime verursacht ...

Benutzer berichten werden, dass die Anwendung abstürzt während des Starts, bevor noch etwas zeigen.

---

Ich fragte auf Samsung-Entwickler-Forum, bisher ohne Antwort.

---

Ich habe zwei Fragen:

• Der Backtrace in boot.oat beginnt und in libart.so. Was passiert in boot.oat? Ist es möglich, dass es abstürzt, bevor ich meinen Code erreiche? (Das würde einen Fehler in Samsungs ART anzeigen.)

• Jede Idee, was könnte falsch sein, was könnte ich versuchen?

Answer 1

Zusammen mit einem anderen Entwickler, die den gleichen Absturz in seiner Anwendung erhalten wurden, stellten wir fest, dass es durch die -z Parameter zipalign Werkzeug ausgelöst wird. (Mit Zopfli erneut komprimieren)

Das genau gleiche APK stürzt ab, wenn es mit Zopfli ausgerichtet und rekomprimiert wird und stürzt nicht ab, wenn es ohne erneute Komprimierung ausgerichtet wird.

Ich kann nur vermuten, dass Samsung einige Änderungen an der Android 5 vorgenommen und einige seltsame Fehler in den Code, der die APK liest eingeführt. Bis das behoben ist oder ich eine bessere Erklärung habe, löst das -z in zipalign das Problem nicht.