Arresto nativo di Android avviato da /system/framework/arm/boot.oat

Question

Dopo il recente aggiornamento della mia applicazione in Google Play, ho iniziato a ricevere molti rapporti sugli arresti anomali, tutti provenienti da dispositivi Samsung con Android 5. Versioni Android inferiori funziona bene e anche i dispositivi di altri produttori con Android 5 funzionano bene.

Non ho alcun dispositivo in cui sia possibile riprodurre il problema, quindi non posso bisetterlo. Sto cercando di dedurre ciò che potrebbe essere sbagliato dal rapporto di crash e dall'elenco delle modifiche dalla mia ultima versione funzionante (che purtroppo è lunga).

Tutte le segnalazioni di crash simile a questa (solo gli indirizzi leggermente variano tra i dispositivi):

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 

ho scoperto che il art::TypeLookupTable è la modifica di Samsung di ART e non ci sono fonti disponibili.

Sia questa che le ultime versioni di lavoro sono costruite con lo stesso SDK e NDK di Android (target è Android-19), non ci sono cambiamenti nel codice Java, ci sono molte modifiche nel codice nativo e nei dati. Ho iniziato a utilizzare LTO durante la creazione di codice nativo. Ho iniziato a utilizzare il parametro -z (Zopfli) di zipalign.

La mia applicazione utilizza JNI, quindi questo è probabilmente il primo sospetto. Tuttavia, CheckJNI non segnala alcun problema. Lo stesso codice funziona chiaramente senza arresti anomali su altri dispositivi Android, su IOS e su Linux. Non mostra alcun errore in valgrind. Quindi penso che qualche corruzione della memoria casuale sia improbabile.

Penso che il mio codice Java è ok, ma anche se avesse errori, non dovrebbe causare segfault in runtime Java ...

Gli utenti stanno segnalando che l'applicazione si blocca durante l'avvio, prima ancora di mostrare nulla.

---

Ho chiesto sul forum degli sviluppatori Samsung, finora senza alcuna risposta.

---

Ho due domande:

• Il backtrace inizia in boot.oat e continua a libart.so. Cosa sta succedendo in boot.oat? È possibile che si blocchi anche prima di raggiungere il mio codice? (Ciò indicherebbe bug nell'ARTE di Samsung)

• Qualunque idea di cosa potrebbe essere sbagliato, cosa potrei provare?

Answer 1

Insieme ad un altro sviluppatore, che stava diventando lo stesso incidente nella sua domanda, abbiamo scoperto che è innescato dal parametro -z di zipalign strumento. (Ricomprimi con Zopfli)

Lo stesso APK si arresta in modo anomalo quando allineato e ricompresso con Zopfli e non si arresta in modo anomalo se allineato senza ricompressione.

Posso solo supporre che Samsung abbia apportato alcune modifiche a Android 5 e introdotto alcuni bug strani nel codice che legge l'APK. Fino a quando non viene risolto o ho una spiegazione migliore, non utilizzare lo -z in zipalign risolve il problema.