Develop Reference

art::ConditionVariable::WaitHoldingLocks(art::Thread*)

Our mobile app is published in the Google play store. The Crashes and ANR report is generated in Firebase Crashlytics. There is an ANR shown as below.
0
libc.so
(syscall+28)
1
libart.so
(art::ConditionVariable::WaitHoldingLocks(art::Thread*)+140)
2
libart.so
(art::ThreadList::WaitForOtherNonDaemonThreadsToExit(bool)+336)
3
libart.so
(art::JII::DestroyJavaVM(_JavaVM*)+32)
4
libandroid_runtime.so
(android::AndroidRuntime::start(char const*, android::Vectorandroid::String8 const&, bool)+1032)
5
app_process64
(main+1368)
6
libc.so
(__libc_init+96)
What does this ANR mean?
Thank you in advance.

I believe it has a connection with some routine added in mobile app which is preventing screen from sleep. For example:
If your mobile app used the following code to prevent the screen from sleep
"getWindow().addFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);"
This issue is not device specific, I also experience this on Samsung Galaxy active tab with Android 11 running on it.
You should give it a try by removing any screen prevention code.
Thank you.

How to troubleshoot Crash in App Running Android 11 (SDK 30)

I've never seen a stack trace like that and have no idea how to troubleshoot. It didn't happen in Android 10 (SDK 29) or earlier. The app is built with androidx support library and SDK 30.
The phone where it has happened:
Samsung Note 10+ 5G running on SDK 30
Any pointers are appreciated.
That's all I could get from PlayStore:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> app-package-name <<<
backtrace:
#00 pc 00000000038621f0 /data/app/~~dDiCj_8810kb6DPfFJq1VA==/com.google.android.trichromelibrary_438909034-1CcX13lT2sfyKsCGVu4mkA==/base.apk!libmonochrome_64.so (offset 0x646000)

Google announced an incident for their own Gmail App. Users cannot launch the App. And it's related to the Android System WebView, which is more like a component for Android system but can be updated via Google Play.
The issue was reported at 3/23/21, 7:05 AM
But this issue is more than Google thought. Not only Gmail app will crash, many other Apps will crash too. Reddit thread for this.
Unluckily, our App is one of them, we saw live crash number going up and then going down. And we have many users complain about this. They just cannot open our App.
Luckily, Google fixed their bug and everything will be good if users update their Android System WebView app in Google Play.
We didn't catch this crash in Firebase Crashlytics, but we can see it in Google Play Console. And actually, I have no idea about this crash log. I have to Google it to see if it's only me or for everyone. Thanks for posting this issue here so I know I'm not alone.

As #Morrison Chang and #Tink have indicated in comments, the crashes have been related to Android System WebView that can be found at the following location in Play Store:
https://play.google.com/store/apps/details?id=com.google.android.webview
In my case the problem has been fixed after I've updated the above app with the release that Google has pushed to Play Store on 03/22.
Even though my application doesn't use WebView directly there are probably dependencies in the Android and Samsung libraries that my application relies on.

Strange Crash in CronetDynamite.apk (offset 0x1000) Android

My application had a crash report on Feb 1, 2021.
Crash
LGE LG Premier Pro
Android 9 (SDK 28)
Playstore console crash have reported 40 times this report in CronetDynamite.apk
backtrace:
#00 pc 000000000018fb36
/data/user_de/0/com.google.android.gms/app_chimera/m/000001d4/CronetDynamite.apk (offset 0x1000)
Firebase Crashlytic does not show this crash... But Play console got this log
I didn't get what causes this crash, any help appreciated

I don't know the cause of the crash, however cronet is provided by Google, who describe it as:
Cronet is the Chromium network stack made available to Android apps as a library. Cronet takes advantage of multiple technologies that reduce the latency and increase the throughput of the network requests that your app needs to work.
https://developer.android.com/guide/topics/connectivity/cronet
My guess is they've got some unusual crash related to their library which is being used in your app somehow (perhaps even in the Firebase Crash Reporting SDK implementation?).
As you reported this crash 6 months ago I hope you've found a workaround or fix. Please do add an update here.
If you're still suffering from the issue, try raising a bug report with Google. The same web page says:
You can send feedback about the Cronet Library using the Chromium Issue Tracker. Check the list of bugs in the issue tracker to make sure that your issue hasn't already been reported. If your issue hasn't been reported, file a bug with the word Cronet in the summary line.
All the best

Google Play crash logs not symbolicated with Android App Bundle

We have recently updated our apps to use Android App Bundles (aab) and to also include arm64 native libs.
Since doing so, our crash logs in native code in the 'Google Play Console'->'Android Vitals'->'ANRs & Crashes' are not symbolicating correctly (java callstacks symbolicate fine).
A snippet from a typical callstack looks like this:
#21 pc 000000000015addc /data/app/com.mycompany.mygame-2/split_config.arm64_v8a.apk
#22 pc 0000000000293768 /data/app/com.mycompany.mygame-2/split_config.arm64_v8a.apk
#23 pc 0000000000294cf0 /data/app/com.mycompany.mygame-2/split_config.arm64_v8a.apk
The issue affects crashes from both armv7 and arm64. Occasionally a bug will have a properly symbolicated callstack, approximately 10% are symbolicated properly now. Prior to the use of AAB and arm64, we were seeing almost all callstacks symbolicated correctly.
To work around this, we investigated using Crashlytics, but had trouble getting a properly symbolicated callstack that way also. As we haven't used Crashlytics before it is difficult for us to know whether it suffers from the same issue or whether we simply setup Crashlytics incorrectly. However, this post indicates that other users may be having trouble with AABs and Crashlytics.
Is anyone else experiencing similar difficulties?
Are there any known workarounds?
Has anyone updated to use AABs and is not seeing any problem with crash report symbolication in the Google Play console?

Edit: The NDK 21 RC1 should fix this issue.
This seems related to the fact that native libraries are kept uncompressed in the APK.
By adding the following option in your gradle.properties, you can disable it:
android.bundle.enableUncompressedNativeLibs=false
You'll need to release a new App Bundle built with this option.

Why does turning debuggable off in android manifest cause data alignment error?

I have been running and testing my android native app for weeks now in debug mode without issues. Today, I decided to test it in release mode by selecting "debuggable" as "false" in the android manifest and using ant release install to build.
However, when I attempt to run my app, I get an error message like:
I/DEBUG ( 264): signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 5c27f389
which I assume is a data alignment error (according to google). But as soon as I turn debuggable on, the app no longer crashes.
What could've caused this error? I'm not even sure where to start to look because the crash only occurs when I turn debuggable off.

SIGBUS is similar to SIGSEGV in that it is caused by an illegal memory access. When debugging is on, bigger blocks of memory are used making these problems less apparent. It does not mean the bug does not exist in the debug version, it just means it has not caused a crash. You might get a nasty memory corruption instead.
You are getting a crash so you are getting a crash dump. In the crash dump you will get a call-stack of addresses and .so files.
you can find the function that the addresses are using by calling addr2line with the address and the module. If you want a full dissassembly objdump can be used. You will either have to install the arm versions of these programs or use the ones that come in the android NDK.