lollipop - Accidente nativo de Android iniciando desde/system/framework/arm/boot.oat

descargar lollipop 5.1 para cualquier android

Question

Después de la actualización reciente de mi aplicación en Google Play, comencé a recibir muchos informes de fallos, todos son de dispositivos Samsung con Android 5. Las versiones inferiores de Android funcionan bien y los dispositivos de otros fabricantes con Android 5 también funcionan bien.

No tengo ningún dispositivo donde pueda reproducir el problema, así que no puedo bisectar. Intento deducir lo que podría estar mal del informe del bloqueo y de la lista de cambios desde mi última versión en funcionamiento (que lamentablemente es larga).

Todos los informes de fallos se ven así (solo las direcciones varían ligeramente entre dispositivos):

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

Descubrí que el art::TypeLookupTable es la modificación de ART de Samsung y no hay fuentes disponibles.

Tanto esta como la última versión de trabajo están compiladas con el mismo SDK y NDK de Android (el objetivo es android-19), no hay cambios en el código de Java, hay muchos cambios en el código nativo y en los datos. Empecé a usar LTO al crear código nativo. Empecé a usar el parámetro -z (Zopfli) de zipalign .

Mi aplicación utiliza JNI, por lo que es probable que sea el primer sospechoso. Sin embargo, CheckJNI no informa ningún problema. El mismo código se ejecuta claramente sin fallas en otros dispositivos Android, en IOS y en Linux. No muestra ningún error en valgrind. Así que creo que es improbable que haya corrupción aleatoria de memoria.

Creo que mi código Java está bien, pero incluso si tuviera errores, no debería causar segfault en Java runtime ...

Los usuarios informan que la aplicación falla durante el inicio, incluso antes de mostrar algo.

Pregunté en el foro de desarrolladores de Samsung, hasta ahora sin ninguna respuesta.

Tengo dos preguntas:

• El backtrace comienza en boot.oat y continúa en libart.so. ¿Qué está pasando en boot.oat? ¿Es posible que se bloquee incluso antes de llegar a cualquiera de mi código? (Eso indicaría un error en el ART de Samsung).

• Alguna idea de lo que podría estar mal, ¿qué podría intentar?

Answer 1

Junto con otro desarrollador, que estaba recibiendo el mismo bloqueo en su aplicación, descubrimos que se desencadena por el parámetro -z de la herramienta zipalign . (Recompress usando Zopfli)

La misma APK se bloquea cuando se alinea y vuelve a comprimir con Zopfli y no se cuelga cuando se alinea sin volver a comprimir.

Solo puedo adivinar que Samsung hizo algunas modificaciones al Android 5 e introdujo algún error extraño en el código que lee el APK. Hasta que eso no se solucione o tenga una explicación mejor, no usar el -z en zipalign resuelve el problema.