Obsolete
Status Update
No update yet.
Comments
ra...@google.com
I see same issue and have been debugging it.
NOTE: It DOES NOT happen if not using support package, but use android level 14/15 library. I believe Honeycomb works well too.
My current workaround is to provide my own DialogFragment.show() method, like below:
public int show(FragmentTransaction transaction, String tag) {
return show(transaction, tag, false);
}
public int show(FragmentTransaction transaction, String tag, boolean allowStateLoss) {
transaction.add(this, tag);
mRemoved = false;
mBackStackId = allowStateLoss ? transaction.commitAllowingStateLoss() : transaction.commit();
return mBackStackId;
}
NOTE: It DOES NOT happen if not using support package, but use android level 14/15 library. I believe Honeycomb works well too.
My current workaround is to provide my own DialogFragment.show() method, like below:
public int show(FragmentTransaction transaction, String tag) {
return show(transaction, tag, false);
}
public int show(FragmentTransaction transaction, String tag, boolean allowStateLoss) {
transaction.add(this, tag);
mRemoved = false;
mBackStackId = allowStateLoss ? transaction.commitAllowingStateLoss() : transaction.commit();
return mBackStackId;
}
ar...@gmail.com
[Comment deleted]
ms...@microsoft.com
But Google pls fix this issue, as the expected behaviors must be consistent with ICS DialogFragment + FragmentManager and support package DialogFragment + FragmentManager.
It happens with both Support Package v4 r6 and v13 r6.
It happens with both Support Package v4 r6 and v13 r6.
jc...@xone.es
I have this problem too.
As a workaround I use a boolean in the onActivityResult to mark the desired dialog and show the dialog in the onResume.
As a workaround I use a boolean in the onActivityResult to mark the desired dialog and show the dialog in the onResume.
ng...@google.com
This is definitely not a bug. There are times when onActivityResult() can be called before the Activity has restored its saved state... committing fragment transactions in these situations will simply not be remembered as a result (see this blog post: http://www.androiddesignpatterns.com/2013/08/fragment-transaction-commit-state-loss.html ).
Try moving your commits into "onPostResume()" instead as described here:http://stackoverflow.com/questions/16265733/failure-delivering-result-onactivityforresult/18345899#18345899
Try moving your commits into "onPostResume()" instead as described here:
re...@gmail.com
Adding a "super.onActivityResult(requestCode, resultCode, data)" call at the beginning of the method seems to fix the problem. I'm surprised than almost nobody came up with such a simple solution.
ng...@google.com
Dear alockw...@google.com,
Let's say we have an application where we need to select a picture from gallery, and then when we come back to onActivityResult(), we need to show a DialogFragment asking the user if he really wants to send the file.
How do you propose we can implement this with the current API?
Thank you,
Sabin
Let's say we have an application where we need to select a picture from gallery, and then when we come back to onActivityResult(), we need to show a DialogFragment asking the user if he really wants to send the file.
How do you propose we can implement this with the current API?
Thank you,
Sabin
re...@gmail.com
Please also consider how to deal with "Avoid performing transactions inside asynchronous callback methods." problem which is stated in http://www.androiddesignpatterns.com/2013/08/fragment-transaction-commit-state-loss.html#more
dismissAllowingStateLoss() is the least resort for dismiss() dialog in onPostExecute(), but there is no solution for DialogFragment#show() in onPreExecute() callback.
dismissAllowingStateLoss() is the least resort for dismiss() dialog in onPostExecute(), but there is no solution for DialogFragment#show() in onPreExecute() callback.
ng...@google.com
I have a similar problem, but I show the DialogFragment (not the one of the support library) on the onStart method call.
How could it be? And, how can I solve this?
How could it be? And, how can I solve this?
ms...@microsoft.com
Comment has been deleted.
ba...@gmail.com
public void showAllowingStateLoss(FragmentManager manager, String tag) {
FragmentTransaction ft = manager.beginTransaction();
ft.add(this, tag);
ft.commitAllowingStateLoss();
}
I looked up the source code and got this method. I'm wondering why Google add a @hide annotation to this great API?
FragmentTransaction ft = manager.beginTransaction();
ft.add(this, tag);
ft.commitAllowingStateLoss();
}
I looked up the source code and got this method. I'm wondering why Google add a @hide annotation to this great API?
ms...@microsoft.com
Agree #14.
ms...@gmail.com
Just looked up source code and this method was introduced since API 23. So maybe here's another alternative:
getFragmentManager().beginTransaction()
.add(fragment, tag)
.commitAllowingStateLoss();
getFragmentManager().beginTransaction()
.add(fragment, tag)
.commitAllowingStateLoss();
ng...@google.com
Oh my god..
This error happened to my app users..
Please refer to below logs.
Samsung Galaxy Note10+ 5G (d2x), Android 9
java.lang.IllegalStateException:
at androidx.fragment.app.FragmentManager.checkStateLoss (FragmentManager.java:1997)
at androidx.fragment.app.FragmentManager.enqueueAction (FragmentManager.java:2029)
at androidx.fragment.app.BackStackRecord.commitInternal (BackStackRecord.java:321)
at androidx.fragment.app.BackStackRecord.commit (BackStackRecord.java:286)
at androidx.fragment.app.DialogFragment.show (DialogFragment.java:156)
at com.xxx.yyyyy.ZZZActivity$8$1.run (ZZZActivity.java:585)
at android.os.Handler.handleCallback (Handler.java:873)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loop (Looper.java:216)
at android.app.ActivityThread.main (ActivityThread.java:7263)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:494)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:975)
This error happened to my app users..
Please refer to below logs.
Samsung Galaxy Note10+ 5G (d2x), Android 9
java.lang.IllegalStateException:
at androidx.fragment.app.FragmentManager.checkStateLoss (FragmentManager.java:1997)
at androidx.fragment.app.FragmentManager.enqueueAction (FragmentManager.java:2029)
at androidx.fragment.app.BackStackRecord.commitInternal (BackStackRecord.java:321)
at androidx.fragment.app.BackStackRecord.commit (BackStackRecord.java:286)
at androidx.fragment.app.DialogFragment.show (DialogFragment.java:156)
at com.xxx.yyyyy.ZZZActivity$8$1.run (ZZZActivity.java:585)
at android.os.Handler.handleCallback (Handler.java:873)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loop (Looper.java:216)
at android.app.ActivityThread.main (ActivityThread.java:7263)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:494)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:975)
l_...@hotmail.com
Thanks for the potential fixes, can you provide exact date for the fixes in the January update?
je...@gmail.com
Thanks for the potential fixes. Could you please specify the component and clarify how end users will receive these updates?
ms...@microsoft.com
We also have some questions about these tentative fixes:
Will these come in an Android update, or a Play System update? We see reports on Android 13 and 14, would the fix target both?
Any build/kernel version we should be watching for?
What's the difference between what is being delivered in January vs. in March? Are these the same fixes flighted across different releases? Or is the one in March a riskier fix?
Will these come in an Android update, or a Play System update? We see reports on Android 13 and 14, would the fix target both?
Any build/kernel version we should be watching for?
What's the difference between what is being delivered in January vs. in March? Are these the same fixes flighted across different releases? Or is the one in March a riskier fix?
ng...@google.com
Thanks for the potential fixes, can you provide exact date for the fixes in the January update?
The fixes are rolling out supposedly next week to a small canary, and should be at a 100% by the end of the month.
Thanks for the potential fixes. Could you please specify the component and clarify how end users will receive these updates?
The issue seems to be in the Android runtime. The fixes will go to all Android 12/13/14 devices through a mainline update.
Will these come in an Android update, or a Play System update? We see reports on Android 13 and 14, would the fix target both?
A Play system update. The fix would target all of Android 12/13/14.
Any build/kernel version we should be watching for?
Only the Google Play system update version which should say January.
What's the difference between what is being delivered in January vs. in March? Are these the same fixes flighted across different releases? Or is the one in March a riskier fix?
The January fixes were made a couple of months ago. The March potential fix got found late December, and so could only be included in the March train.
vs...@gmail.com
Hi.
We are getting similar issue in our app.
Stack Trace looks somewhat different, but 18 calls right before crash look to be exactly the same. (see attaches crash report please)
Behavior looks very similar too. Different users have it working for a different amount of time. Some users are not impacted, as fas as we know. We can confirm it happening on Andoird 13 and 14 phones. Samsungs and Nokias. Temporary fix is the same - it is enough to clear cache and app will work for a while after that. Sadly, we can't get it to happen on our dev devices. We are working on to get more data from device that experiences crashes: tombstone files and logs from Samsung KNOX
Additional note there is that it is Intune Wrapped app.
My questions here are:
Do you think this is the same issue?
Any workaround that we can get implemented waiting for the fix? We consider clearing cache programatically and looks like no problem to clear app's cache directory, but I'm worried that this won't delete cache which is related to the issue.
Do you need any more info to help with this?
Thanks!
We are getting similar issue in our app.
Stack Trace looks somewhat different, but 18 calls right before crash look to be exactly the same. (see attaches crash report please)
Behavior looks very similar too. Different users have it working for a different amount of time. Some users are not impacted, as fas as we know. We can confirm it happening on Andoird 13 and 14 phones. Samsungs and Nokias. Temporary fix is the same - it is enough to clear cache and app will work for a while after that. Sadly, we can't get it to happen on our dev devices. We are working on to get more data from device that experiences crashes: tombstone files and logs from Samsung KNOX
Additional note there is that it is Intune Wrapped app.
My questions here are:
Do you think this is the same issue?
Any workaround that we can get implemented waiting for the fix? We consider clearing cache programatically and looks like no problem to clear app's cache directory, but I'm worried that this won't delete cache which is related to the issue.
Do you need any more info to help with this?
Thanks!
re...@gmail.com
Hi,
As I shared earlier, my app has been facing similar issue with a very similar crash log.
To add on more info:
My app is also an intune wrapped app.
We tried to clear cache but still unable to resolve the issue
Some users can get the crash resolved after they re-installed the Intune company portal and the app.
And some users got the crash resolved by itself after some days.
We have some confusion here, is this issue has anything related to Intune SDK?
Thanks!
As I shared earlier, my app has been facing similar issue with a very similar crash log.
To add on more info:
My app is also an intune wrapped app.
We tried to clear cache but still unable to resolve the issue
Some users can get the crash resolved after they re-installed the Intune company portal and the app.
And some users got the crash resolved by itself after some days.
We have some confusion here, is this issue has anything related to Intune SDK?
Thanks!
ng...@google.com
You can clear the cache programmatically, use Context.getCacheDir().
vs...@gmail.com
My phone (Samsung S20 Ultra 5G) just got an update (January 1, 2024 Security Patch). And I'm getting the same/very similar error now. I could not get it on my phone earlier. Stack Trace seams to go a bit further than before and it is not exactly the same as on other phones (some new and missing lines), but general course is the same. Probably, some optimizations? Or Android 13/Android 14 difference. Another possibility is that it is unrelated to the updated and it was a restart of my phone (triggered by the update), which caused this issue. Looks like our customers having similar behavior. At the same time, I've spent few days restarting my phone periodically and got no issue untill this update.
Part of a new stack trace:
#00 pc 0000000000051ce8 /apex/com.android.runtime/lib64/bionic/libc.so (abort+164) (BuildId: 173441c90e5afc5b5229a361bc9d8d2d)
#01 pc 0000000000771b00 /apex/com.android.art/lib64/libart.so (art::Runtime::Abort(char const*)+904) (BuildId: 735f12f804f88d62a2cb437261076ff7)
#02 pc 00000000000357d0 /apex/com.google.mainline.primary.libs@341177000/lib64/libbase.so/75d3253827fcfd7a8d7b02ad45991611ec4ca424c0278e13e8acfad4d14e597a3ecff6c0caa2b785c73838528ee6e9c2b313240ff895f50ee39b1d7bc10f390a/libbase.so (android::base::SetAborter(std::__1::function<void (char const*)>&&)::$_0::__invoke(char const*)+80) (BuildId: 6f67f69ff36b970d0b831cfdab3b578d)
#03 pc 0000000000034d58 /apex/com.google.mainline.primary.libs@341177000/lib64/libbase.so/75d3253827fcfd7a8d7b02ad45991611ec4ca424c0278e13e8acfad4d14e597a3ecff6c0caa2b785c73838528ee6e9c2b313240ff895f50ee39b1d7bc10f390a/libbase.so (android::base::LogMessage::~LogMessage()+352) (BuildId: 6f67f69ff36b970d0b831cfdab3b578d)
#04 pc 000000000022e1e4 /apex/com.android.art/lib64/libart.so (void art::mirror::Object::VisitReferences<false, (art::VerifyObjectFlags)0, (art::ReadBarrierOption)1, art::gc::space::ImageSpace::Loader::FixupObjectVisitor<art::gc::space::ImageSpace::Loader::ForwardAddress<art::gc::space::RelocationRange, art::gc::space::RelocationRange, art::gc::space::ImageSpace::Loader::EmptyRange> >, art::gc::space::ImageSpace::Loader::FixupObjectVisitor<art::gc::space::ImageSpace::Loader::ForwardAddress<art::gc::space::RelocationRange, art::gc::space::RelocationRange, art::gc::space::ImageSpace::Loader::EmptyRange> > >(art::gc::space::ImageSpace::Loader::FixupObjectVisitor<art::gc::space::ImageSpace::Loader::ForwardAddress<art::gc::space::RelocationRange, art::gc::space::RelocationRange, art::gc::space::ImageSpace::Loader::EmptyRange> > const&, art::gc::space::ImageSpace::Loader::FixupObjectVisitor<art::gc::space::ImageSpace::Loader::ForwardAddress<art::gc::space::RelocationRange, art::gc::space::RelocationRange, art::gc::space::ImageSpace::Loader::EmptyRange> > const&)+1004) (BuildId: 735f12f804f88d62a2cb437261076ff7)
#05 pc 000000000022ec80 /apex/com.android.art/lib64/libart.so (art::gc::space::ImageSpace::Loader::FixupObjectVisitor<art::gc::space::ImageSpace::Loader::ForwardAddress<art::gc::space::RelocationRange, art::gc::space::RelocationRange, art::gc::space::ImageSpace::Loader::EmptyRange> >::operator()(art::mirror::Object*) const+96) (BuildId: 735f12f804f88d62a2cb437261076ff7)
#06 pc 000000000022dc60 /apex/com.android.art/lib64/libart.so (void art::gc::accounting::SpaceBitmap<8ul>::VisitMarkedRange<false, art::gc::space::ImageSpace::Loader::FixupObjectVisitor<art::gc::space::ImageSpace::Loader::ForwardAddress<art::gc::space::RelocationRange, art::gc::space::RelocationRange, art::gc::space::ImageSpace::Loader::EmptyRange> >&>(unsigned long, unsigned long, art::gc::space::ImageSpace::Loader::FixupObjectVisitor<art::gc::space::ImageSpace::Loader::ForwardAddress<art::gc::space::RelocationRange, art::gc::space::RelocationRange, art::gc::space::ImageSpace::Loader::EmptyRange> >&) const+152) (BuildId: 735f12f804f88d62a2cb437261076ff7)
////below is the line where it would fail before:
#07 pc 0000000000228024 /apex/com.android.art/lib64/libart.so (bool art::gc::space::ImageSpace::Loader::RelocateInPlace<(art::PointerSize)8>(unsigned int, unsigned char*, art::gc::accounting::SpaceBitmap<8ul>*, art::OatFile const*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*)+5412) (BuildId: 735f12f804f88d62a2cb437261076ff7)
#08 pc 0000000000220d04 /apex/com.android.art/lib64/libart.so (art::gc::space::ImageSpace::Loader::InitAppImage(char const*, char const*, art::OatFile const*, art::ArrayRef<art::gc::space::ImageSpace* const>, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*)+500) (BuildId: 735f12f804f88d62a2cb437261076ff7)
#09 pc 00000000004015ac /apex/com.android.art/lib64/libart.so (art::OatFileManager::OpenDexFilesFromOat(char const*, _jobject*, _jobjectArray*, art::OatFile const**, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >*)+3972) (BuildId: 735f12f804f88d62a2cb437261076ff7)
#10 pc 00000000003ff2c4 /apex/com.android.art/lib64/libart.so (art::DexFile_openDexFileNative(_JNIEnv*, _jclass*, _jstring*, _jstring*, int, _jobject*, _jobjectArray*) (.__uniq.325793859780145791435928139633802341359)+192) (BuildId: 735f12f804f88d62a2cb437261076ff7)
#11 pc 0000000000336f3c /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (art_jni_trampoline+172)
#12 pc 00000000005d0658 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (dalvik.system.DexFile.openDexFile+616)
#13 pc 00000000005d31d8 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (dalvik.system.DexPathList.makeDexElements+856)
#14 pc 00000000005d2294 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (dalvik.system.DexPathList.<init>+692)
#15 pc 00000000005cdd88 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (dalvik.system.BaseDexClassLoader.<init>+584)
ar...@gmail.com
Hello
Please share the status of the fix release which is mentioned in above comments dated 11th Jan. We are approaching end of month and would like to know fix release timelines.
Thanks.
Please share the status of the fix release which is mentioned in above comments dated 11th Jan. We are approaching end of month and would like to know fix release timelines.
Thanks.
nk...@gmail.com
I dispute that anyone can clear the cache programmatically.
This issue is not about programmatic cache handling.
This is because for apps that use the WebView cache, the cache must be deleted when a problem occurs, so the cache cannot be cleared programmatically.
Please also refer to this.
This issue is not about programmatic cache handling.
This is because for apps that use the WebView cache, the cache must be deleted when a problem occurs, so the cache cannot be cleared programmatically.
Please also refer to this.
nk...@gmail.com
I think that if the crash is handled (try catch), there may be an opportunity to do something different.
ms...@microsoft.com
Has anyone seen decrease in the crashes after the January release?
vs...@gmail.com
Can't say about all devices, but I have evidence of the same error on one of our Samsung devices which is on 1 January 2024 release. So, must be that fix does not work or it is not complete.
nk...@gmail.com
The crash also occurs in Android System WebView 121.0.6167.178 release date 2024-02-14 and later versions.
pl...@gmail.com
Jumping on the train here....
I only see this crash with a variant of my React Native app that uses the Intune SDK + MSAL for Android.
I have another variant that doesn't use the Intune SDK and users have had no issues.
Updating or disabling Android System WebView works for some time, but then an Android update will get the device back on a bad version of WebView.
I only see this crash with a variant of my React Native app that uses the Intune SDK + MSAL for Android.
I have another variant that doesn't use the Intune SDK and users have had no issues.
Updating or disabling Android System WebView works for some time, but then an Android update will get the device back on a bad version of WebView.
je...@intune.corp-partner.google.com
Customer is still reporting this to be an issue after the release in January. Can you please advise if it is still being worked on and when we can expect a fix.
Let me know if you require any information from the customer.
Many thanks
Jenna
Let me know if you require any information from the customer.
Many thanks
Jenna
ng...@google.com
#32: which customer, do you have bugreports? If will be really helpful if one can reproduce the issue.
pe...@gmail.com
Hi all, has this issue finally solved in January release or are you going to release a new fix? Kind regards
ng...@google.com
#34: We don't know yet if it's solved. Have you been able to reproduce?
ms...@microsoft.com
We are still seeing reports of this issue in our Play Store analytics
pe...@gmail.com
We are still checking with some users... As you are still seeing reports of this issue, are you going to create a new fix this month?
ng...@google.com
We've seen a reduced amount of crashes. There's another tentative fix coming in March.
pe...@gmail.com
Do you know when exactly the fix will be deployed? Many thanks!
ms...@microsoft.com
We're still seeing many crashes for many users. This is our main crash these days and many users are affected.
Are there any news about a solution??
Are there any news about a solution??
fe...@zoom.us
Comment has been deleted.
di...@gmail.com
#23 you mention to delete the cache directory, (Context.getCacheDir()), can you specify which files? As we use the folder to store our application cache as well.
mo...@gmail.com
Good morning!
Some march fixes have been installed in our Android devices. Is the issue supposed to be fixed?
Kind regards.
Some march fixes have been installed in our Android devices. Is the issue supposed to be fixed?
Kind regards.
mi...@servicenow.com
We have some tentative fixes, but without being able to reproduce, these are tries in the dark. Those fixes will come in a January update, and another one in a March update.
Could you provide the play services version where the March fixes are be included? We have affected customers and would like to see if they are on a version with the fixes.
In case it helps reproduce:
- They are using a version of our app that integrates the intune sdk (no reports on the non-intune version of the app)
- Users reproduce by using our app, then backgrounding while doing other tasks. The app crashes repeatedly when they attempt to return to the app
- They report multiple users with the device "Samsung S23 OneUI 6.0 / Android 14" are impacted.
da...@gmail.com Restricted
Restricted
Comment has been deleted.
Description
For our application, we see roughly 6000 occurrences of this error in the last 28 days. A partner application seeing an identical call stack in their Analytics shows 70k occurrences in this time frame.
This GitHub report describes a similar crash in Flutter:
From our data the crash only occurs on Android 13 and Android 14. Samsung devices make up the significant majority of cases (>90%). We do see a handful of cases occurring across Google and OnePlus devices as well.
The crash in Play Console:
[libart.so] bool art::gc::space::ImageSpace::Loader::RelocateInPlace<(art::PointerSize)8>(unsigned int, unsigned char*, art::gc::accounting::SpaceBitmap<8ul>*, art::OatFile const*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*)
pid: 0, tid: 28732 >>> com.microsoft.crm.crmphone.fieldServices <<<
Another report from a user who was able to attach logcat:
Build fingerprint: 'samsung/a52xqnaeea/a52xq:13/TP1A.220624.014/A526BXXS5EWJ5:user/release-keys'
Revision: '5'
ABI: 'arm64'
Processor: '7'
Timestamp: 2023-12-07 17:56:02.368617005+0100
Process uptime: 5s
Cmdline: com.microsoft.crm.crmphone.fieldServices
pid: 22542, tid: 23221, name:
uid: 1010019
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x000000000000000c
Cause: null pointer dereference
x0 0000000000000000 x1 00000075b772d5b0 x2 00000075aca2f54c x3 0000000000000010
x4 0000000000000000 x5 000000009ec5c000 x6 00000000004d4cc8 x7 0000000000000000
x8 0000000000000000 x9 0000000000000000 x10 0000000000010000 x11 0000000000000001
x12 000000000c0003e0 x13 000000395ae5ba35 x14 0018fc64c1e741b8 x15 0000000034155555
x16 000000758c328868 x17 00000075ac9bd110 x18 00000070a470c000 x19 00000000702df000
x20 0000000072c5c000 x21 000000009ec5c000 x22 00000000702df000 x23 00000075b7af2fa0
x24 00000072fb216000 x25 b4000073bc00a078 x26 000000009ec5c000 x27 0000000000000008
x28 00000070a57fc000 x29 00000070a57f9840
lr 00000072fa82b824 sp 00000070a57f94f0 pc 00000072fa82b844 pst 0000000060001000
backtrace:
#00 pc 000000000022b844 /apex/com.android.art/lib64/libart.so (bool art::gc::space::ImageSpace::Loader::RelocateInPlace<(art::PointerSize)8>(unsigned int, unsigned char*, art::gc::accounting::SpaceBitmap<8ul>*, art::OatFile const*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*)+508) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#01 pc 000000000022584c /apex/com.android.art/lib64/libart.so (art::gc::space::ImageSpace::Loader::InitAppImage(char const*, char const*, art::OatFile const*, art::ArrayRef<art::gc::space::ImageSpace* const>, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*)+500) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#02 pc 000000000041cdf4 /apex/com.android.art/lib64/libart.so (art::OatFileManager::OpenDexFilesFromOat(char const*, _jobject*, _jobjectArray*, art::OatFile const**, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >*)+3972) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#03 pc 000000000041ab0c /apex/com.android.art/lib64/libart.so (art::DexFile_openDexFileNative(_JNIEnv*, _jclass*, _jstring*, _jstring*, int, _jobject*, _jobjectArray*) (.__uniq.325793859780145791435928139633802341359)+192) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#04 pc 0000000000335f3c /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (art_jni_trampoline+172)
#05 pc 00000000005cf728 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (dalvik.system.DexFile.openDexFile+616)
#06 pc 00000000005d22a8 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (dalvik.system.DexPathList.makeDexElements+856)
#07 pc 00000000005d1364 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (dalvik.system.DexPathList.<init>+692)
#08 pc 00000000005cce58 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (dalvik.system.BaseDexClassLoader.<init>+584)
#09 pc 00000000009a7970 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (com.android.internal.os.ClassLoaderFactory.createClassLoader+960)
#10 pc 00000000009a7a34 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (com.android.internal.os.ClassLoaderFactory.createClassLoader+100)
#11 pc 000000000067f178 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.app.ApplicationLoaders.getClassLoader+472)
#12 pc 000000000067fa10 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.app.ApplicationLoaders.getClassLoaderWithSharedLibraries+96)
#13 pc 000000000068ee1c /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.app.LoadedApk.createOrUpdateClassLoaderLocked+6028)
#14 pc 00000000007ae8b8 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.app.LoadedApk$SplitDependencyLoaderImpl.constructSplit+216)
#15 pc 00000000006d15b8 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.content.pm.split.SplitDependencyLoader.loadDependenciesForSplit+232)
#16 pc 00000000007ae778 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.app.LoadedApk$SplitDependencyLoaderImpl.ensureSplitLoaded+536)
#17 pc 00000000007af7a8 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.app.LoadedApk$SplitDependencyLoaderImpl.getSplitPathsForSplit+56)
#18 pc 00000000006968f0 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.app.LoadedApk.getSplitPaths+80)
#19 pc 00000000005bd4d8 /apex/com.android.art/lib64/libart.so (nterp_helper+5848) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#20 pc 00000000001ef21c /system/framework/framework.jar (android.app.ContextImpl.createResources+0)
#21 pc 00000000005bc5e4 /apex/com.android.art/lib64/libart.so (nterp_helper+2020) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#22 pc 00000000001ef200 /system/framework/framework.jar (android.app.ContextImpl.createResources+20)
#23 pc 000000000079d140 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.app.ContextImpl.createApplicationContext+608)
#24 pc 00000000007f914c /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.content.ContextWrapper.createApplicationContext+60)
#25 pc 00000000007f914c /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.content.ContextWrapper.createApplicationContext+60)
#26 pc 0000000000bff418 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.webkit.WebViewFactory.getWebViewContextAndSetProvider+1720)
#27 pc 0000000000bfe0a8 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.webkit.WebViewFactory.getProviderClass+200)
#28 pc 0000000000bfd9ec /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.webkit.WebViewFactory.getProvider+604)
#29 pc 0000000000bfbee0 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.webkit.CookieManager.getInstance+32)
#30 pc 00000000005bbe98 /apex/com.android.art/lib64/libart.so (nterp_helper+152) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#31 pc 000000000044cfb4 /data/app/~~rlcSCsDNOA0sjen7x0d-RA==/com.microsoft.crm.crmphone.fieldServices-uVUgl2pBvDECk-_fHHRcuA==/oat/arm64/base.vdex (com.facebook.react.modules.network.ForwardingCookieHandler.getCookieManager+20)
#32 pc 00000000005bcd54 /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#33 pc 000000000044d090 /data/app/~~rlcSCsDNOA0sjen7x0d-RA==/com.microsoft.crm.crmphone.fieldServices-uVUgl2pBvDECk-_fHHRcuA==/oat/arm64/base.vdex (com.facebook.react.modules.network.ForwardingCookieHandler.get+0)
#34 pc 00000000005bcd54 /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#35 pc 0000000001dd96f6 /data/app/~~rlcSCsDNOA0sjen7x0d-RA==/com.microsoft.crm.crmphone.fieldServices-uVUgl2pBvDECk-_fHHRcuA==/oat/arm64/base.vdex (okhttp3.JavaNetCookieJar.loadForRequest+30)
#36 pc 00000000005bdb74 /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#37 pc 000000000044ec54 /data/app/~~rlcSCsDNOA0sjen7x0d-RA==/com.microsoft.crm.crmphone.fieldServices-uVUgl2pBvDECk-_fHHRcuA==/oat/arm64/base.vdex (com.facebook.react.modules.network.ReactCookieJarContainer.loadForRequest+8)
#38 pc 00000000005bdb74 /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#39 pc 0000000001ded4f4 /data/app/~~rlcSCsDNOA0sjen7x0d-RA==/com.microsoft.crm.crmphone.fieldServices-uVUgl2pBvDECk-_fHHRcuA==/oat/arm64/base.vdex (okhttp3.internal.http.BridgeInterceptor.intercept+260)
#40 pc 00000000005bdb74 /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#41 pc 0000000001dee6ba /data/app/~~rlcSCsDNOA0sjen7x0d-RA==/com.microsoft.crm.crmphone.fieldServices-uVUgl2pBvDECk-_fHHRcuA==/oat/arm64/base.vdex (okhttp3.internal.http.RealInterceptorChain.proceed+330)
#42 pc 00000000005bcd54 /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#43 pc 0000000001def04c /data/app/~~rlcSCsDNOA0sjen7x0d-RA==/com.microsoft.crm.crmphone.fieldServices-uVUgl2pBvDECk-_fHHRcuA==/oat/arm64/base.vdex (okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept+68)
#44 pc 00000000005bdb74 /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#45 pc 0000000001dee6ba /data/app/~~rlcSCsDNOA0sjen7x0d-RA==/com.microsoft.crm.crmphone.fieldServices-uVUgl2pBvDECk-_fHHRcuA==/oat/arm64/base.vdex (okhttp3.internal.http.RealInterceptorChain.proceed+330)
#46 pc 00000000005bdc20 /apex/com.android.art/lib64/libart.so (nterp_helper+7712) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#47 pc 000000000146bee0 /data/app/~~rlcSCsDNOA0sjen7x0d-RA==/com.microsoft.crm.crmphone.fieldServices-uVUgl2pBvDECk-_fHHRcuA==/oat/arm64/base.vdex (com.microsoft.msapps.network.BrotliInterceptor.intercept+120)
#48 pc 00000000005bdb74 /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#49 pc 0000000001dee6ba /data/app/~~rlcSCsDNOA0sjen7x0d-RA==/com.microsoft.crm.crmphone.fieldServices-uVUgl2pBvDECk-_fHHRcuA==/oat/arm64/base.vdex (okhttp3.internal.http.RealInterceptorChain.proceed+330)
#50 pc 00000000005bcd54 /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#51 pc 0000000001dea2b2 /data/app/~~rlcSCsDNOA0sjen7x0d-RA==/com.microsoft.crm.crmphone.fieldServices-uVUgl2pBvDECk-_fHHRcuA==/oat/arm64/base.vdex (okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp+246)
#52 pc 00000000005bcd54 /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#53 pc 0000000001de9886 /data/app/~~rlcSCsDNOA0sjen7x0d-RA==/com.microsoft.crm.crmphone.fieldServices-uVUgl2pBvDECk-_fHHRcuA==/oat/arm64/base.vdex (okhttp3.internal.connection.RealCall$AsyncCall.run+66)
#54 pc 000000000056e33c /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor.runWorker+796)
#55 pc 000000000056b460 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor$Worker.run+64)
#56 pc 0000000000419e08 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (java.lang.Thread.run+72)
#57 pc 0000000000333fa4 /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+612) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#58 pc 000000000023e4d4 /apex/com.android.art/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+144) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#59 pc 0000000000539a3c /apex/com.android.art/lib64/libart.so (art::Thread::CreateCallback(void*)+1600) (BuildId: 4cfdaa9e5146c43e20ae36ee1caf9b7f)
#60 pc 00000000000ba5a8 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+208) (BuildId: ef11d8d2511bfd3cab1588a6cb2014bb)
#61 pc 0000000000053e9c /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+68) (BuildId: ef11d8d2511bfd3cab1588a6cb2014bb)
Users are reporting that once in the state, the app crashing consistently when attempting to open.
While the stack above crashes within android.webkit.CookieManager.getInstance(), we see other reports of this same crash happening through other entry points. For example, android.webkit.WebSettings.getDefaultUserAgent
We do not have repro steps defined, as it isn't clear what is necessary to get into this state. Users report being able to use the app fine for a period, and then suddenly getting into this crashing state (they have started uninstalling and reinstalling the app as a workaround).
Our app details:
Dynamics 365 Field Service
com.microsoft.crm.crmphone.fieldServices