Повреждение на базе Android

Мы не используем собственный код, а также наше приложение не имеет какой-либо собственной транзитивной зависимости.

После недавнего выпуска (мы обновили зависимости зависимостей и добавили новые) мы начали видеть такие сбои в Google Play:

native: pc 000000000006a548  /system/lib64/libc.so (tgkill+8)
  native: pc 0000000000067cd8  /system/lib64/libc.so (pthread_kill+68)
  native: pc 0000000000024b78  /system/lib64/libc.so (raise+28)
  native: pc 000000000001f318  /system/lib64/libc.so (abort+60)
  native: pc 000000000043471c  /system/lib64/libart.so (_ZN3art7Runtime5AbortEv+324)
  native: pc 0000000000137224  /system/lib64/libart.so (_ZN3art10LogMessageD2Ev+3136)
  native: pc 000000000030d988  /system/lib64/libart.so (_ZN3art9JavaVMExt8JniAbortEPKcS2_+2080)
  native: pc 000000000030df24  /system/lib64/libart.so (_ZN3art9JavaVMExt9JniAbortFEPKcS2_z+224)
  native: pc 000000000034ec64  /system/lib64/libart.so (_ZN3art3JNI15CallVoidMethodVEP7_JNIEnvP8_jobjectP10_jmethodIDSt9__va_list+616)
  native: pc 0000000000099094  /system/lib64/libandroid_runtime.so
  native: pc 0000000002a71ac4  /system/framework/arm64/boot.oat

Я думаю, что это просто сам Android, но что может быть причиной? Любая помощь приветствуется.

Есть ли информация о том, что означает этот вызов? Это виртуальная машина?

_ZN3art3JNI15CallVoidMethodVEP7_JNIEnvP8_jobjectP10_jmethodIDSt9__va_list

Ответ 1

Для начала я думаю, что проблема была в том, что главная причина заключалась в том, что Play Console не предоставляет полную трассировку стека, а трассировка стека также немного меняется в зависимости от версии устройства /Android. Я видел этот родной сбой tgkill со многими вариациями, такими как следующее, но я пришел к выводу, что все эти сбои могут быть отнесены к ошибке в библиотеке поддержки

_ZN3art3JNI15CallVoidMethodVEP7_JNIEnvP8_jobjectP10_jmethodIDSt9__va_list+440 _ZN3art3JNI15CallVoidMethodVEP7_JNIEnvP8_jobjectP10_jmethodIDSt9__va_list+616 art::JNI::CallVoidMethodV(_JNIEnv*, _jobject*, _jmethodID*, std::__va_list)+580 _ZN3art3JNI15CallVoidMethodVEP7_JNIEnvP8_jobjectP10_jmethodIDSt9__va_list+470 _ZN3art3JNI15CallVoidMethodVEP7_JNIEnvP8_jobjectP10_jmethodIDSt9__va_list+560

После долгих усилий я смог воссоздать это на устройстве 6.0 на экране в своем приложении, которое содержало AppBarLayout + CollapsingToolbarLayout + RecyclerView. В CollapsingToolbarLayout были следующие флажки прокрутки

app:layout_scrollFlags="scroll|exitUntilCollapsed|snap"

Прокручивая весь путь до дна, а затем быстро вернувшись к вершине, я смог восстановить авария большую часть времени, что дало следующий стек

04-18 14:06:53.814 27077-27077/com.PACKAGE.NAME.debug A/art: art/runtime/java_vm_ext.cc:410] JNI DETECTED ERROR IN APPLICATION: can't call void android.view.View.setElevation(float) on null object
art/runtime/java_vm_ext.cc:410]     in call to CallVoidMethodV
art/runtime/java_vm_ext.cc:410]     from void android.animation.PropertyValuesHolder.nCallFloatMethod(java.lang.Object, long, float)
art/runtime/java_vm_ext.cc:410] "main" prio=5 tid=1 Runnable
art/runtime/java_vm_ext.cc:410]   | group="main" sCount=0 dsCount=0 obj=0x740f26e8 self=0x558c24bf70
art/runtime/java_vm_ext.cc:410]   | sysTid=27077 nice=-6 cgrp=default sched=0/0 handle=0x7f8f6e8fc8
art/runtime/java_vm_ext.cc:410]   | state=R schedstat=( 76543056125 12869243427 123563 ) utm=6830 stm=824 core=2 HZ=100
art/runtime/java_vm_ext.cc:410]   | stack=0x7fef761000-0x7fef763000 stackSize=8MB
art/runtime/java_vm_ext.cc:410]   | held mutexes= "mutator lock"(shared held)
art/runtime/java_vm_ext.cc:410]   native: #00 pc 00000000004903d8  /system/lib64/libart.so (_ZN3art15DumpNativeStackERNSt3__113basic_ostreamIcNS0_11char_traitsIcEEEEiPKcPNS_9ArtMethodEPv+236)
art/runtime/java_vm_ext.cc:410]   native: #01 pc 000000000045f598  /system/lib64/libart.so (_ZNK3art6Thread4DumpERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE+220)
art/runtime/java_vm_ext.cc:410]   native: #02 pc 0000000000312970  /system/lib64/libart.so (_ZN3art9JavaVMExt8JniAbortEPKcS2_+1000)
art/runtime/java_vm_ext.cc:410]   native: #03 pc 0000000000313228  /system/lib64/libart.so (_ZN3art9JavaVMExt9JniAbortVEPKcS2_St9__va_list+116)
art/runtime/java_vm_ext.cc:410]   native: #04 pc 000000000014501c  /system/lib64/libart.so (_ZN3art11ScopedCheck6AbortFEPKcz+144)
art/runtime/java_vm_ext.cc:410]   native: #05 pc 000000000014557c  /system/lib64/libart.so (_ZN3art11ScopedCheck17CheckMethodAndSigERNS_18ScopedObjectAccessEP8_jobjectP7_jclassP10_jmethodIDNS_9Primitive4TypeENS_10InvokeTypeE+1084)
art/runtime/java_vm_ext.cc:410]   native: #06 pc 000000000015eaf8  /system/lib64/libart.so (_ZN3art8CheckJNI11CallMethodVEPKcP7_JNIEnvP8_jobjectP7_jclassP10_jmethodIDSt9__va_listNS_9Primitive4TypeENS_10InvokeTypeE+724)
art/runtime/java_vm_ext.cc:410]   native: #07 pc 0000000000160d98  /system/lib64/libart.so (_ZN3art8CheckJNI15CallVoidMethodVEP7_JNIEnvP8_jobjectP10_jmethodIDSt9__va_list+68)
art/runtime/java_vm_ext.cc:410]   native: #08 pc 0000000000098fe0  /system/lib64/libandroid_runtime.so (???)
art/runtime/java_vm_ext.cc:410]   native: #09 pc 0000000000ad2cc4  /system/framework/arm64/boot.oat (Java_android_animation_PropertyValuesHolder_nCallFloatMethod__Ljava_lang_Object_2JF+168)
art/runtime/java_vm_ext.cc:410]   at android.animation.PropertyValuesHolder.nCallFloatMethod(Native method)
art/runtime/java_vm_ext.cc:410]   at android.animation.PropertyValuesHolder.access$400(PropertyValuesHolder.java:37)
art/runtime/java_vm_ext.cc:410]   at android.animation.PropertyValuesHolder$FloatPropertyValuesHolder.setAnimatedValue(PropertyValuesHolder.java:1296)
art/runtime/java_vm_ext.cc:410]   at android.animation.ObjectAnimator.animateValue(ObjectAnimator.java:981)
art/runtime/java_vm_ext.cc:410]   at android.animation.ValueAnimator.animationFrame(ValueAnimator.java:1384)
art/runtime/java_vm_ext.cc:410]   at android.animation.ValueAnimator.doAnimationFrame(ValueAnimator.java:1427)
art/runtime/java_vm_ext.cc:410]   at android.animation.ValueAnimator$AnimationHandler.doAnimationFrame(ValueAnimator.java:759)
art/runtime/java_vm_ext.cc:410]   at android.animation.ValueAnimator$AnimationHandler$1.run(ValueAnimator.java:801)
art/runtime/java_vm_ext.cc:410]   at android.view.Choreographer$CallbackRecord.run(Choreographer.java:858)
art/runtime/java_vm_ext.cc:410]   at android.view.Choreographer.doCallbacks(Choreographer.java:670)
art/runtime/java_vm_ext.cc:410]   at android.view.Choreographer.doFrame(Choreographer.java:603)
art/runtime/java_vm_ext.cc:410]   at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:844)
art/runtime/java_vm_ext.cc:410]   at android.os.Handler.handleCallback(Handler.java:743)
art/runtime/java_vm_ext.cc:410]   at android.os.Handler.dispatchMessage(Handler.java:95)
art/runtime/java_vm_ext.cc:410]   at android.os.Looper.loop(Looper.java:171)
art/runtime/java_vm_ext.cc:410]   at android.app.ActivityThread.main(ActivityThread.java:5417)
art/runtime/java_vm_ext.cc:410]   at java.lang.reflect.Method.invoke!(Native method)
art/runtime/java_vm_ext.cc:410]   at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
art/runtime/java_vm_ext.cc:410]   at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
art/runtime/java_vm_ext.cc:410] 

Основная причина этого, похоже, связана с ошибкой библиотеки поддержки, подробно описанной здесь и здесь.

РЕШЕНИЕ

В моем случае все, что я должен был сделать удалить snap флаг прокрутки и Свиток это изменение. С этим изменением я больше не вижу никаких подобных сбоев в Play Console.

В других случаях, если вы используете StateListAnimator в AppBarLayout, вы можете попробовать это

Ответ 2

Я был настолько скептически относился к некоторым ошибкам зависимостей как возможная причина аварии.

Тем не менее, мы обновили следующий в последней версии, и авария исчезла:

  • Инструменты для сборки 26.0.3 → 27.0.3
  • Android Gradle Plugin to 3.0.1 → 3.1.0-rc01 (это также приводит к новым привязкам привязки данных под капотом)
  • DexGuard 8.0.23 → 8.1.10
  • Котлин 1.2.21 → 1.2.30
  • RxJava 2.1.0 → 2.1.10
  • RxAndroid 2.0.1 → 2.0.2
  • Настроить 4.12.1 → 4.12.2
  • Поддержка Multidex 1.0.2 → 1.0.3

Анализ CHANGELOGS довольно тяжелый и громоздкий. Я потратил полчаса, это не указывает на одну очевидную проблему.

После просмотра снова и снова я думаю, что это может быть ошибка зависимости. Но я не могу сказать точно, так как мы также сделали немало изменений за эти две недели.