Android родной сбой

Question

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

После недавнего выпуска (мы обновили пару зависимостей и добавили новые), мы начали видеть такие сбои в 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

Answer 1

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

_ZN3art3JNI15CallVoidMethodVEP7_JNIEnvP8_jobjectP10_jmethodIDSt9__va_list+440_ZN3art3JNI15CallVoidMethodVEP7_JNIEnvP8_jobjectP10_jmethodIDSt9__va_list+616art::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, вы можете попробовать это

Answer 2

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

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

• Инструменты сборки 26.0.3 -> 27.0.3
• Android Gradle Plugin для 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 довольно сложно и громоздко. Я потратил на это полчаса, это не указывает на одну очевидную проблему.

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