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.
Related
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
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.
So, I'm in google play console, and I'm seeing some crashes from this mysterious libusc.so file. Specifically, here's the details when I open up the crash
pid: 0, tid: 0 >>> com.myapp.blah <<<
backtrace:
#00 pc 000000000000be18 /vendor/lib/libusc.so
#01 pc 000000000005938b /vendor/lib/libusc.so
What does this mean? is this some 3rd party vendor firmware crash?
How do I get it to show up the line of the crash and the actual reason for the crash?
Is this even accurate on google play? Or are google play store crashes not accurate?
I made an app for android but needed to move to another pc due to hardware failure. Now, the question pops up from android studio that an app with the same package name is on the tablet, but a different signature, and ask to uninstall. Uninstall fails however because the app is device owner to implement kiosk mode ( pinned mode in android terms ).
So, I'm stuck. Why is the signature different while the project is exactly the same ?
Copy your keystore form your pc to other pc .
KeySotre path C:\Users\{username}\.android\debug.keystore
When you run your project in android studio it generates default hash for debug mode, and APK installed on your device is generated with a different hash so it prompts you.
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.