I'm facing a weird issue where I am occasionally getting a StackOverflowError on calling SharedPreferences.Editor.Commit(). Problem occurs only sometimes and on Emulator only. If I rerun the app and call commit for the same value - everything is fine.
Seems rather random, and not something I ever saw on a physical device with the same code base. Seeing this on Pixel 3 API 29 Emulator image. Wondering if its an emulator issue.
Would like to know the cause for this error coming up randomly and what should be done about it?
Exception stack trace:
E/AndroidRuntime: FATAL EXCEPTION: Thread-19
java.lang.StackOverflowError: stack size 1040KB
at java.lang.String.getChars(String.java:787)
at com.android.internal.util.FastXmlSerializer.append(FastXmlSerializer.java:115)
at com.android.internal.util.FastXmlSerializer.append(FastXmlSerializer.java:139)
at com.android.internal.util.FastXmlSerializer.escapeAndAppendString(FastXmlSerializer.java:163)
at com.android.internal.util.FastXmlSerializer.text(FastXmlSerializer.java:413)
at com.android.internal.util.XmlUtils.writeValueXml(XmlUtils.java:662)
at com.android.internal.util.XmlUtils.writeMapXml(XmlUtils.java:307)
at com.android.internal.util.XmlUtils.writeMapXml(XmlUtils.java:276)
at com.android.internal.util.XmlUtils.writeMapXml(XmlUtils.java:242)
at com.android.internal.util.XmlUtils.writeMapXml(XmlUtils.java:199)
at android.app.SharedPreferencesImpl.writeToFile(SharedPreferencesImpl.java:778)
at android.app.SharedPreferencesImpl.access$900(SharedPreferencesImpl.java:55)
at android.app.SharedPreferencesImpl$2.run(SharedPreferencesImpl.java:647)
at android.app.SharedPreferencesImpl.enqueueDiskWrite(SharedPreferencesImpl.java:666)
at android.app.SharedPreferencesImpl.access$100(SharedPreferencesImpl.java:55)
at android.app.SharedPreferencesImpl$EditorImpl.commit(SharedPreferencesImpl.java:585)
It's a very strange Xiaomi device's OS exception. Even if I do have logs available from Fabric, the stack trace doesn't refer any of my code.
A crash details are below as reported in crashalytics(Fabric),
21K crashes
All crashes on Xiaomi devices
Crashes on Android OS version 6, 7 and 8
Crash Log:
# OS Version: 8.1.0
# Device: Redmi Note 5 pro
# RAM Free: 30.1%
# Disk Free: 74.2%
#0. Crashed: main
at android.widget.Editor.touchPositionIsInSelection(Editor.java:1084)
at android.widget.Editor.performLongClick(Editor.java:1205)
at android.widget.TextView.performLongClick(TextView.java:10908)
at android.view.View.performLongClick(View.java:6360)
at android.view.View$CheckForLongPress.run(View.java:24768)
at android.os.Handler.handleCallback(Handler.java:790)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:171)
at android.app.ActivityThread.main(ActivityThread.java:6606)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:518)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:823)
--
Fatal Exception: java.lang.NullPointerException: Attempt to invoke virtual method 'int android.widget.Editor$SelectionModifierCursorController.getMinTouchOffset()' on a null object reference
at android.widget.Editor.touchPositionIsInSelection(Editor.java:1084)
at android.widget.Editor.performLongClick(Editor.java:1205)
at android.widget.TextView.performLongClick(TextView.java:10908)
at android.view.View.performLongClick(View.java:6360)
at android.view.View$CheckForLongPress.run(View.java:24768)
at android.os.Handler.handleCallback(Handler.java:790)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:171)
at android.app.ActivityThread.main(ActivityThread.java:6606)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:518)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:823)
#0. Crashed: main
at android.widget.Editor.touchPositionIsInSelection(Editor.java:1084)
at android.widget.Editor.performLongClick(Editor.java:1205)
at android.widget.TextView.performLongClick(TextView.java:10908)
at android.view.View.performLongClick(View.java:6360)
at android.view.View$CheckForLongPress.run(View.java:24768)
at android.os.Handler.handleCallback(Handler.java:790)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:171)
at android.app.ActivityThread.main(ActivityThread.java:6606)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:518)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:823)
Similar Reference:
https://issuetracker.google.com/issues/37127697
java.lang.NullPointerException with Nougat
Also asked on Xiaomi official forum http://en.miui.com/forum.php?mod=viewthread&tid=4595164
Please do provide any working solution as soon as possible. As users must not be happy with these crashes.
Thanks in advance.
1) First of all, only if required, set one of these.
textView.setMovementMethod(LinkMovementMethod.getInstance());
or
setAutoLinkMask(Linkify.ALL);
or
Linkify.addLinks(textView, Linkify.PHONE_NUMBERS | Linkify.EMAIL_ADDRESSES | Linkify.MAP_ADDRESSES);
2) Secondly, set a long click listener for TextView and it must return true.
textView.setOnLongClickListener(new View.OnLongClickListener() {
#Override
public boolean onLongClick(View v) {
// do soemthing if needed
return true;
}
});
There is some internal crashing issue on Xiaomi devices. If you override setOnLongClickListener(reference) first and then follow the step one, it will use internal implementation and that will keep on crashing. So it is import to follow above steps in sequence.
I am open to other solutions, however by following this approach I don't see crash reports anymore.
Do you have a custom TextView in your app? Is it perhaps resizeable or has additional functionality?
Xiaomi's Android skin is likely interfering with that, and causing crashes. I suggest trying to long click all TextViews in your app.
It happen when user doing long click on all selected text.
Just define longClickListener:
edit_text.setOnLongClickListener {
doSomething()
true
}
and later you can remove it
edit_text.setOnLongClickListener(null)
For me this crash happened when TextView contained link and setAutoLinkMask(Linkify.ALL); was called for the view. In this case Android handles all clicks (including long clicks) by this view. On devices of other brands link was opened after long click, but on Xiaomi device crash happened. It seems, that they have a bit different logic of handling onTouchEvent inside the TextView. I've played a bit around and found, that setting android:textIsSelectable="false" for the TextView in layout file solves the problem.
I know, that it's not scalable solution, but for my case it was perfect, so I stopped investigating further. Maybe it will give a hint to someone else.
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.
we get in the Play Store some crash reports of this kind:
java.lang.StackOverflowError
at android.graphics.Paint.getTextRunAdvances(Paint.java:1753)
at android.graphics.Paint.getTextRunAdvances(Paint.java:1726)
at android.text.TextLine.handleText(TextLine.java:758)
at android.text.TextLine.handleRun(TextLine.java:981)
at android.text.TextLine.measureRun(TextLine.java:425)
at android.text.TextLine.measure(TextLine.java:299)
at android.text.TextLine.metrics(TextLine.java:273)
.
.
.
.
at android.view.View.draw(View.java:11069)
at android.widget.FrameLayout.draw(FrameLayout.java:450)
at com.android.internal.policy.impl.PhoneWindow$DecorView.draw(PhoneWindow.java:2203)
at android.view.View.getDisplayList(View.java:10505)
at android.view.HardwareRenderer$GlRenderer.draw(HardwareRenderer.java:876)
at android.view.ViewRootImpl.draw(ViewRootImpl.java:1916)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1640)
at android.view.ViewRootImpl.handleMessage(ViewRootImpl.java:2454)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4477)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:788)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:555)
at dalvik.system.NativeStart.main(Native Method)
We had such an exception on one of our test devices and it came out, that it was because of the maximum depth of the view hierarchy.
I know that the recommendation for the max depth is <10.
However, this value is quite ambitious if you have a reasonably complex app.
We use AppCompat v21 and a ViewPager on the Main-Acitivity with Fragments.
For this reason i think we have alot of "meaningless" views, which simply encapsulates one child.
Or What is the purpose of the following layouts:
-NoSaveStateFrameLayout
-NativeActionModeAwareLayout
-FitWindowsFrameLayout
Overall, we arrive a total depth of 23 including the PhoneWindowDecorView.
Our Viewtree looks like this:
Picture from Hierarchy View
The first Views from the RootView:
Picture from Hierarchy View
Nevertheless, our app works even on very old and poor Android 2.3 devices.
Why does the problem still occur in the real world.
In my Android app, I am constantly getting the following two errors in my logcat:
06-02 20:33:16.070: E/MoreInfoHPW_ViewGroup(13983): Parent view is not a TextView
06-02 20:33:12.010: E/ViewRootImpl(13983): sendUserActionEvent() mView == null
My app runs completely fine in spite of these two errors, and I've found no definitive answer as to whether or not they are harmful (or even fixable!) errors or if they can be safely ignored. Thus far I've been doing fine just ignoring them, but I wanted this to be asked since I'm sure I am not the only one confused as to what these two errors mean.
For reference, I am getting these errors while running the app via adb on a Samsung Galaxy S5.
EDIT: The Parent view is not a TextView error happens at many times, but notably it happens whenever I press the back button on the action bar and when I start a new activity by pressing a button. I'm using the support library, minSdk=8.
Yes you can ignore, it's a known issue with Samsung models. If it bothers you, maybe you can replace
context.startActivity(....);
with:
startActivity(new Intent(....));
and see if it works for you too, as indicated in this answer:
https://stackoverflow.com/a/24592235/3202370
I hope it helps.