Após a atualização recente do meu aplicativo no Google Play, comecei a receber muitos relatórios de falhas, todos eles provenientes de dispositivos Samsung com Android 5. As versões mais baixas do Android funcionam bem e os dispositivos de outros fabricantes com o Android 5 também.

Não tenho nenhum dispositivo em que possa reproduzir o problema, por isso não posso me dividir. Estou tentando deduzir o que pode estar errado no relatório de falha e na lista de alterações desde a minha última versão de trabalho (que infelizmente é longa).

Todos os relatórios de falhas são assim (apenas os endereços variam ligeiramente entre os 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

Eu descobri que oart::TypeLookupTable é a modificação da ART da Samsung e não há fontes disponíveis.

Esta e as últimas versões de trabalho são construídas com o mesmo Android SDK e NDK (o destino é android-19), não há alterações no código Java, há muitas alterações no código nativo e nos dados. Comecei a usar o LTO ao criar código nativo. Eu comecei a usar-z (Zopfli) parâmetro dezipalign.

Meu aplicativo usa JNI, portanto esse é provavelmente o primeiro suspeito. No entanto, o CheckJNI não relata nenhum problema. O mesmo código é executado claramente, sem falhas em outros dispositivos Android, no IOS e no Linux. Não mostra nenhum erro no valgrind. Então, acho improvável alguma corrupção aleatória da memória.

Eu acho que meu código Java está ok, mas mesmo se houver erros, ele não deve causar segfault no tempo de execução do java ...

Os usuários estão relatando que o aplicativo falha durante o início, antes mesmo de mostrar qualquer coisa.

Eu perguntei no fórum de desenvolvedores da Samsung, até agora sem qualquer resposta.

Eu tenho duas perguntas:

O backtrace inicia no boot.oat e continua no libart.so. O que está acontecendo no boot.oat? É possível que ele trava antes mesmo de chegar ao código? (Isso indicaria um erro no ART da Samsung.)

Alguma idéia do que poderia estar errado, o que eu poderia tentar?