I am using BottomsheetDialogFragment and recently getting crash reports on crashlytics, the stacktrace is -
Fatal Exception: java.lang.IllegalStateException: Can not perform this
action after onSaveInstanceState
at android.support.v4.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:2044)
at android.support.v4.app.FragmentManagerImpl.enqueueAction(FragmentManager.java:2067)
at android.support.v4.app.BackStackRecord.commitInternal(BackStackRecord.java:680)
at android.support.v4.app.BackStackRecord.commit(BackStackRecord.java:634)
at android.support.v4.app.DialogFragment.dismissInternal(DialogFragment.java:205)
at android.support.v4.app.DialogFragment.dismiss(DialogFragment.java:171)
at com.khaalijeb.inkdrops.ListBanks.onSuccessResponse(ListBanks.java:322)
at com.khaalijeb.inkdrops.App.onSuccessResponse(App.java:800)
at com.olive.upi.OliveUpiManager.onSuccessResponse(Unknown Source:970)
at com.olive.upi.transport.d$33.onResponse(Unknown Source:16)
at retrofit2.ExecutorCallAdapterFactory$ExecutorCallbackCall$1$1.run(ExecutorCallAdapterFactory.java:68)
at android.os.Handler.handleCallback(Handler.java:789)
at android.os.Handler.dispatchMessage(Handler.java:98)
at android.os.Looper.loop(Looper.java:169)
at android.app.ActivityThread.main(ActivityThread.java:6595)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:767)
I don't know what caused this error since it is not happening in some device and not all of them. Did anyone face this problem earlier and how to overcome it?
I have tested this particular code 1000 times but never got one but in the production world, I am getting this error in around 2 3 devices.
How to call commitAllowingStateLoss();? will this fixed the problem?
There is BottomsheetDialogFragment#dismissAllowingStateLoss method in the material library that will allow you to fix this problem
I'm getting a "removeView(View) is not supported in AdapterView" exception when running my app in Android version 8.1 and 9.0. In previous versions it runs fine. Although the error is consistent it doesn't happen 100% of the time (which makes me suspect it's a threading issue) nor is it specific to a particular adapter or list view. For instance, I access the same code from multiple actives and it works fine for some and always fails for others. I should also point out that I'm not calling removeView in any of the situations where I get the error. Below is the LogCat output for the exception:
java.lang.UnsupportedOperationException: removeView(View) is not supported in AdapterView
at android.widget.AdapterView.removeView(AdapterView.java:531)
at android.view.ViewOverlay$OverlayViewGroup.add(ViewOverlay.java:195)
at android.view.ViewGroupOverlay.add(ViewGroupOverlay.java:72)
at android.transition.TransitionUtils.createViewBitmap(TransitionUtils.java:170)
at android.transition.TransitionUtils.copyViewImage(TransitionUtils.java:104)
at android.transition.Visibility.onDisappear(Visibility.java:380)
at android.transition.Visibility.createAnimator(Visibility.java:249)
at android.transition.Transition.createAnimators(Transition.java:732)
at android.transition.TransitionSet.createAnimators(TransitionSet.java:396)
at android.transition.Transition.playTransition(Transition.java:1779)
at android.transition.TransitionManager$MultiListener.onPreDraw(TransitionManager.java:315)
at android.view.ViewTreeObserver.dispatchOnPreDraw(ViewTreeObserver.java:977)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2349)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1392)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:6752)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:911)
at android.view.Choreographer.doCallbacks(Choreographer.java:723)
at android.view.Choreographer.doFrame(Choreographer.java:658)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:897)
at android.os.Handler.handleCallback(Handler.java:790)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6494)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
Can anyone point me towards a solution?
I ended up subclassing ListView and overrode removeView and addView with empty methods. I doubt this is the correct way to fix this problem but it worked.
Application was in production for about a 2 month and suddenly (without any application updates) I started receiving very weird crash-reports. I'm use Fabric to collect crash-reports. Screenshot:
After a lot of research and googling (my code does nothing special with measuring) I don't know what can cause such crashes.
As I said above: exactly same apk was in production for 2 month without weird crashes.
Crashes happens on different devices, different manufactures, different android versions.
Some of them blows my mind with exception message like next:
Fatal Exception: java.lang.IndexOutOfBoundsException: Index: 4, Size: 6
at java.util.ArrayList.get(ArrayList.java:411)
at android.view.ViewGroup.getAndVerifyPreorderedView(ViewGroup.java:3288)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2462)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2865)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2492)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2865)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2492)
...
And yes, I don't mess with touch events as well.
Another stack-trace:
java.lang.IllegalStateException: View with id 2131296529: android.support.v4.widget.DrawerLayout#onMeasure() did not set the measured dimension by calling setMeasuredDimension()
at android.view.View.measure(View.java:22014)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:6580)
at android.widget.FrameLayout.onMeasure(FrameLayout.java:185)
at android.view.View.measure(View.java:22002)
at android.widget.LinearLayout.measureVertical(LinearLayout.java:958)
at android.widget.LinearLayout.onMeasure(LinearLayout.java:685)
Anyone experienced such things? Ideas?
It may be a red herring, but my app is full of UI-less task fragments to perform most network operations and work around the activity lifecycle. An example of this type of architecture is described here. https://stackoverflow.com/a/12303649/2662474
On new Google Pixel and Nexus phones running Oreo 8.0, the app has started crashing on resume of many different activities in a way that is very difficult to debug and seems like a low level Android bug that was introduced. It is not happening on any previous OS versions.
Fatal Exception: java.lang.RuntimeException: Unable to resume activity {com.mycompany.shop/com.mycompany.shop.activity.MainNavActivity}: java.lang.IndexOutOfBoundsException: Index: 3, Size: 3
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:3645)
at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3685)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1643)
at android.os.Handler.dispatchMessage(Handler.java:105)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6541)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:767)
Caused by java.lang.IndexOutOfBoundsException: Index: 3, Size: 3
at java.util.ArrayList.get(ArrayList.java:437)
at android.app.FragmentManagerImpl.moveToState(FragmentManager.java:1610)
at android.app.FragmentManagerImpl.dispatchMoveToState(FragmentManager.java:3035)
at android.app.FragmentManagerImpl.dispatchResume(FragmentManager.java:3001)
at android.app.FragmentController.dispatchResume(FragmentController.java:200)
at android.app.Activity.performResume(Activity.java:7100)
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:3620)
at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3685)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1643)
at android.os.Handler.dispatchMessage(Handler.java:105)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6541)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:767)
Please help!
Your error is occurring in the method moveToState() of the nested class FragmentManagerImpl in FragmentManager. The specific code that is causing the erorr is Fragment f = mAdded.get(i) in the following lines:
final int numAdded = mAdded.size();
for (int i = 0; i < numAdded; i++) {
Fragment f = mAdded.get(i); // [causing the error]
moveFragmentToExpectedState(f);
if (f.mLoaderManager != null) {
loadersRunning |= f.mLoaderManager.hasRunningLoaders();
}
}
mAdded is a list of added fragment and is defined as:
ArrayList<Fragment> mAdded;
When the error occurs, i == 3 and the size of the mAdded Arraylist is something less than that. (Error line: "java.lang.IndexOutOfBoundsException: Index: 3, Size: 3") For this to occur, a fragment must have been removed from mAdded somewhere within this for-loop, specifically somewhere in the call chain starting with moveFragmentToExpectedState().
You mention that your app is "work[ing] around the activity lifecycle." Maybe you are getting a fragment into an unexpected state according the Oreo 8.0. I suggest that you put your app into the debugger and set a breakpoint in this for loop. You can then try to track down where the Arraylist mAdded is being changed. That should at least point you in the right direction for the solution.
btw, the source code for API 26 has been released. It can help you in debugging.
Update: From looking at the source, that area of FragmentManger in API 26 has received substantial work from the version in API 25. You may want to take azizbekian's suggestion and move to android.support.v4.app.Fragment. The support version seems to be more in line with API 25 than API 26. This could be a stop-gap measure until you can figure out the root cause.
Regarding your current implementation, I would look for anything that would remove or detach a fragment during the onResume() processing, especially if it is done off the UI thread and maybe in a non thread-safe manner. Look for anything that invoke, directly or indirectly, removeFragment() or detachFragment() of FragmentManager since these seem to be the only places where fragments are removed from mAdded.
Did you try this?: Nesting fragments inside a viewpager fragment throws IndexOutOfBoundsException
You may using getSupportFragmentManager() to call remove().
So, change getSupportFragmentManager() to YourFragment.this.getFragmentManager()
Linked answer said:
Change
getActivity().getSupportFragmentManager().beginTransaction().remove(instance).commit();
to
ThisFragment.this.getFragmentManager().beginTransaction().remove(instance).commit();
I've got a hybrid Cordova Android app, and the app crashes when user tap on a drop-down box in my WebView running on Android OS 8. I've created a simple page with a <select> tag and the issue is reproducible. I've got a workaround which is to do my own pop up alert to select, but just wondering if this is happening to anyone else and whether this is an OS8 WebView bug.
Below is a simple page with <select> tag
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_select
Below is my crash log
11:04:58.643 3208-3208/com.****.****E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.****.****, PID: 3208 android.content.res.Resources$NotFoundException: Resource ID #0x0
at android.content.res.ResourcesImpl.getValue(ResourcesImpl.java:195)
at android.content.res.Resources.loadXmlResourceParser(Resources.java:2133)
at android.content.res.Resources.getLayout(Resources.java:1142)
at android.view.LayoutInflater.inflate(LayoutInflater.java:421)
at android.widget.ArrayAdapter.createViewFromResource(ArrayAdapter.java:416)
at android.widget.ArrayAdapter.getView(ArrayAdapter.java:407)
at org.chromium.content.browser.input.SelectPopupAdapter.getView(SelectPopupAdapter.java:53)
at android.widget.AbsListView.obtainView(AbsListView.java:2372)
at android.widget.ListView.measureHeightOfChildren(ListView.java:1408)
at android.widget.ListView.onMeasure(ListView.java:1315)
at android.view.View.measure(View.java:21998)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:6580)
at android.widget.FrameLayout.onMeasure(FrameLayout.java:185)
at android.view.View.measure(View.java:21998)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:6580)
at android.widget.FrameLayout.onMeasure(FrameLayout.java:185)
at android.view.View.measure(View.java:21998)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:6580)
at android.widget.LinearLayout.measureChildBeforeLayout(LinearLayout.java:1514)
at android.widget.LinearLayout.measureVertical(LinearLayout.java:806)
at android.widget.LinearLayout.onMeasure(LinearLayout.java:685)
at android.view.View.measure(View.java:21998)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:6580)
at android.widget.FrameLayout.onMeasure(FrameLayout.java:185)
at android.view.View.measure(View.java:21998)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:6580)
at android.widget.FrameLayout.onMeasure(FrameLayout.java:185)
at android.view.View.measure(View.java:21998)
at android.view.ViewGroup.measureChildWithMargins(ViewGroup.java:6580)
at android.widget.FrameLayout.onMeasure(FrameLayout.java:185)
at com.android.internal.policy.DecorView.onMeasure(DecorView.java:721)
at android.view.View.measure(View.java:21998)
at android.view.ViewRootImpl.performMeasure(ViewRootImpl.java:2410)
at android.view.ViewRootImpl.measureHierarchy(ViewRootImpl.java:1471)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1751)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1386)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:6733)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:911)
at android.view.Choreographer.doCallbacks(Choreographer.java:723)
at android.view.Choreographer.doFrame(Choreographer.java:658)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:897)
at android.os.Handler.handleCallback(Handler.java:789)
at android.os.Handler.dispatchMessage(Handler.java:98)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6541)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:767)
My issue is not the same as this
Trying to open SELECT tag in Android WebView crashes the application
UPDATE on 9th Jan 2018:
I haven't got a solution yet, my temporary workaround is remove the tag and just use an input. When user select this element, we pass the event to native code to pop up a dialog for selection and update the input once user made a selection.
UPDATE on 23rd March 2018:
After some more investigation, I noticed that it only crashes if the WebView is in a Fragment, but not in an Activity.
I found below comments from this post:
Trying to open SELECT tag in Android WebView crashes the application
"When a SELECT tag is clicked, Android internally displays its options using a native AlertDialog.
Webview must be created with an Activity context because AlertDialog instance needs an Activity context."
I believe this is a bug in Android, probably not handling Context properly for Fragment.
UPDATE 17th of April 2018:
As kenyee pointed out, from here https://issuetracker.google.com/issues/77246450, Google says
You mustn't subclass the resources object - this was never supported and was only possible by accident (which is why it's now marked deprecated). The framework needs to know about all the resources objects so that it can update them when webview is loaded (since webview adds additional paths to the asset manager).
Edit 29th November 2018
Seems this issue has bothered a lot of people.
The solution I've tried and tested to work is to not subclassing the Resource.
Updating compile sdk and supported library version worked for some people.
Adding a wrapper class to Resource may work, I've tried this approach during my initial investigation, it solved the Select crashing issue, still crashes when you click and hold on a text view to pop up the "COPY", "PASTE" options.
I have same issue on Android 8.0 .
finally i solve it.
Try to update your compileSdkVersion to 26,
and update your com.android.support:appcompat-v7 to 26.
If anyone is still having this issue, I found that it wasn't even my code that was subclassing the Resources class but rather the Google support library version that I was using. Updated the support library version and it worked like a charm!
In AndroidX land (limited to a minimum compileSDKVersion 28), I was also getting this issue on a Marshmallow emulator with a popup spinner. I don't go anywhere near Resources so this is still a platform issue with one of the support libs.
I managed to get it working - not by moving the webview to an Activity (although I did try that, it was unnecessary), - but by adding it programmatically with a wrapped context and a standard AppCompat theme:
val webView = WebView(ContextThemeWrapper(activity, R.style.Theme_AppCompat_Light))
binding.webViewContainer.addView(webView)
I don't understand wtf is going on here but right now it works. Good luck people!
EDIT
I have looked into this a lot more and found the dependency which is causing issues for me. A particular version of the material components library is actually inducing this in webviews (1.1.0-alpha06 to be precise). I have asked a question on it here, with a sample project.
Looks like this bug:
https://issuetracker.google.com/issues/77246450
Don't subclass resources...won't be fixed apparently.
Actually found a workaround for this a little while ago that allowed us to continue subclassing Resources and not crash our WebViews. The caveat is we can't let our WebView see or interact with our resources subclass AND we must create the WebView programmaticaly. The first step is exposing method in the Resources subclass to pull the original resources back out.
Lets say our resources subclass is called CustomResourcesWrapper and our ContextWrapper subclass is called CustomContextWrapper.
First we update the CustomResourcesWrapper so we can access the original Resources object
public class CustomResourcesWrapper {
public static Resources findOriginalResources(Context context) {
if (context.getResources() instanceof CustomResourcesWrapper) {
return ((CustomResourcesWrapper) context.getResources()).getOriginalResources();
}
if (context instanceof ContextWrapper) {
return findOriginalResources(((ContextWrapper) context).getBaseContext());
}
return context.getResources();
}
private Resources getOriginalResources() {
return originalResources;
}
}
We're also assuming the CustomContextWrapper looks something like this...
public class CustomContextWrapper extends ContextWrapper {
private final Resources wrappedResources;
public CustomContextWrapper(Context base, Resources resources) {
super(base);
this.wrappedResources = resources;
}
#Override
public Resources getResources() {
return wrappedResources;
}
}
Then we create a static helper method to "unwrap" our custom resources and hide them
// the method name is a bit of a misnomer,
// we're actually unwrapping, then re-wrapping
public static Context unwrapCustomContext(Context wrapped) {
Resources originalResources = CustomResourcesWrapper.findOriginalResources(wrapped);
Context customUnwrappedContext = new CustomContextWrapper(wrapped, originalResources);
return new ContextThemeWrapper(customUnwrappedContext, android.support.v7.appcompat.R.style.Theme_AppCompat_Light);
}
When it comes time to create a WebView, do it ensure the Context we pass to it runs through the above method i.e. WebView webView = new WebView(unwrapCustomContext(context)). I'm not 100% sure why, but the ContextThemeWrapper is a required part of this hack.
I digged into crash logs. Though this answer does not solve your problem, you might get some useful insights
Webiview uses this layout file select_dialog_singlechoice.xml for inflating Spinner item using ArrayAdaper
You are getting Resource not found Exception from here
It means that Your Webview is not able to locate this resource file when you click on select tag
I am not sure why it's happening on Android 8.0,i was not able to reproduce this on Android 8.0 emulator though
After some investigation, I've isolated the issue to WebView inside Fragment on OS8 only. My workaround is to use Activity instead of Fragment for that particular flow. It seems to me an Android defect in Fragment.
Maybe you use custom ContextWrapper in your Activity class. In my case, I override attachBaseContext method. Check this method and use super.attachBaseContext(newBase).
Its look like you are setting Integer value to the Textview. try using String.valueOf(value) to set value in Textview.