We have found several cases for this kind of crashes reported by backend logging monitoring. It seems the crashes do not tie to particular UX failure. And from the reports,
While it is ugly and not good practice, the only thing I could get to reliably work is just catching the exception in dispatchDraw()
like below:
override fun dispatchDraw(canvas: Canvas?) {
/*
* We're doing this because of the below exception that is out of our control:
* java.lang.NullPointerException: Attempt to read from field
* 'int android.view.View.mViewFlags' on a null object reference at
* android.view.ViewGroup.dispatchDraw(ViewGroup.java:4111)
*/
try {
super.dispatchDraw(canvas)
} catch (e: NullPointerException) {
}
}
Just make sure your desired behavior is working correctly and you're not breaking something else by doing this. Again, not ideal, but it's the only thing I could get to work and I'm absolutely sure in my case it's not breaking anything else.
Peace to you :)
I was facing same problem. I resolved with Handler.
new Handler(Looper.getMainLooper()).post(new Runnable() {
@Override
public void run() {
// remove fragment from here
}
});
The problem is in the ViewGroup
's dispatchDraw()
method. This method tries to draw all the ViewGroup
's children. When a child is null
, you get an exception, which most likely comes from this line: if ((child.mViewFlags & VISIBILITY_MASK) == VISIBLE) {
(notice the mViewFlags
).
So the problem is that one of your views, somewhere, is not properly initialized. I'm afraid that's the best I can do.
Even though the exception is common, the causing source is uncommon and occurs when you have so many dynamic views. Sometimes scrolling in the Instagram page cause this exception. However, if you look deep into that, the hardware problem may come to be an issue. So just handle(catch) the issue.