Android 原生崩溃 [英] Android native crash
问题描述
我们没有使用任何原生代码，我们的应用也没有任何原生传递依赖.
We are not using any native code, as well our app doesn't have any native transitive dependency.
在最近发布后(我们更新了几个依赖项并添加了新的)，我们开始在 Google Play 中看到这样的崩溃:
After recent release (we updated couple fo dependencies and add new) we started seeing crashes like this in 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 本身，但可能是什么原因?任何帮助表示赞赏.
I think it just Android itself but what might be the reason? Any assistance is appreciated.
是否有关于此调用含义的信息?是虚拟机调用吗?
Is there info about what this call means? Is it virtual machine some invocation?
_ZN3art3JNI15CallVoidMethodVEP7_JNIEnvP8_jobjectP10_jmethodIDSt9__va_list
推荐答案
首先我认为麻烦的问题是找到根本原因，因为 Play 管理中心不提供完整的堆栈跟踪，堆栈跟踪也会根据具体情况略有变化设备/安卓版本.我已经看到这个 tgkill 原生崩溃有许多变体，如下所示，但我得出的结论是，所有这些崩溃都可以归因于 支持库中的错误
To start out I think the troublesome issue was finding the root cause as the Play Console does not provide the full stack trace and the stack trace also changes slightly depending on the device/android version. I have seen this tgkill native crash with many variations like the following but I've concluded that all of these crashes can be attributed to a bug in the Support Library
_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
经过努力，我能够在包含 AppBarLayout + CollapsingToolbarLayout + RecyclerView 的应用程序屏幕上的 6.0 设备上重新创建它.CollapsingToolbarLayout 具有以下滚动标志
After much effort I was able to recreate this on a 6.0 Device on a screen in my application that contained an AppBarLayout + CollapsingToolbarLayout + RecyclerView. The CollapsingToolbarLayout had the following scroll flags
app:layout_scrollFlags="scroll|exitUntilCollapsed|snap"
通过一直滚动到底部然后快速回到顶部，我能够在大多数情况下重新创建崩溃，从而产生以下堆栈跟踪
By scrolling all the way to the bottom and then quickly back to the top I was able to recreate the crash most of the time which yielded the following stacktrace
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]
The root cause of this seems to be related to a Support Library bug detailed here and here
解决方案
就我而言，我所要做的就是删除 snap 滚动标志并推出该更改.随着这一变化，我在 Play 管理中心中不再看到任何这些原生崩溃.
In my case all I had to do was remove the snap scroll flag and rollout that change. With that change I am not seeing any of these native crashes anymore in Play Console.
在其他情况下，如果您在 AppBarLayout 上使用 StateListAnimator，您可以尝试 这个
In other cases if you are using a StateListAnimator on the AppBarLayout you can try this
这篇关于Android 原生崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
