Google Playでアプリケーションを最近更新した後、クラッシュレポートをたくさん受け取り始めました。それらはすべて、Android 5。下位AndroidバージョンのSamsungデバイスからのものです。 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
はSamsungによるARTの変更であり、利用可能なソースがないことがわかりました。
このバージョンと最後に動作するバージョンはどちらも同じAndroid SDKとNDK(ターゲットはAndroid-19))でビルドされており、Javaコード、そこに変更はありません。ネイティブコードとデータに多くの変更があります。ネイティブコードをビルドするときにLTOを使い始めました。zipalign
の-z
(Zopfli)パラメーターを使い始めました。
私のアプリケーションはJNIを使用しているので、おそらくそれが最初の容疑者です。ただし、CheckJNIは問題を報告しません。同じコードは、他のAndroidデバイス、IOS、およびLinuxで、クラッシュすることなく明確に実行されます。valgrindにエラーは表示されません。したがって、ランダムなメモリ破損はほとんどありません。
私のJavaコードは問題ないと思いますが、エラーが発生した場合でも、Javaランタイム...でセグメンテーション違反が発生することはありません。
ユーザーは、何も表示する前に、起動中にアプリケーションがクラッシュすることを報告しています。
私はSamsung開発者フォーラムで質問しましたが、これまでのところ何の応答もありません。
2つの質問があります:
バックトレースはboot.oatで始まり、libart.soで続きます。 boot.oatで何が起こっていますか?コードに到達する前でもクラッシュする可能性はありますか? (これは、SamsungのARTのバグを示しています。)
何が間違っている可能性があるのか、私は何を試すことができますか?
彼のアプリケーションで同じクラッシュが発生していた他の1人の開発者と一緒に、それがzipalign
ツールの-z
パラメーターによってトリガーされることを発見しました。 (Zopfliを使用して再圧縮)
まったく同じAPKは、Zopfliで整列および再圧縮するとクラッシュし、再圧縮せずに整列するとクラッシュしません。
SamsungがAndroid 5にいくつかの変更を加え、APKを読み取るコードに奇妙なバグを導入したと推測できます。それが修正されるまで、または-z
を使用せずに、より適切な説明があります。 zipalign
で問題を解決します。