Crash when drawing the editor on devices running Android 8

[jkmassel]

It appears we're getting a crash specific to Android devices with Android 8.x, prevalently Huawei devices.

The relevant bits of the stack trace:

Fatal Exception: java.lang.ArrayIndexOutOfBoundsException: length=79; index=-19
       at android.text.DynamicLayout.getBlockIndex(DynamicLayout.java:646)
       at android.widget.Editor.drawHardwareAccelerated(Editor.java:1744)
       at android.widget.Editor.onDraw(Editor.java:1713)
       at android.widget.TextView.onDraw(TextView.java:7034)
       at android.view.View.draw(View.java:19314)
       at android.view.View.updateDisplayListIfDirty(View.java:18250)
       at android.view.View.draw(View.java:19042)
       at android.view.ViewGroup.drawChild(ViewGroup.java:4271)
       at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4054)
       at android.view.View.updateDisplayListIfDirty(View.java:18241)
       at android.view.View.draw(View.java:19042)
       at android.view.ViewGroup.drawChild(ViewGroup.java:4271)
       at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4054)
       at android.view.View.updateDisplayListIfDirty(View.java:18241)
       at android.view.View.draw(View.java:19042)
       at android.view.ViewGroup.drawChild(ViewGroup.java:4271)
       at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4054)
       at android.view.View.draw(View.java:19317)
       at android.widget.ScrollView.draw(ScrollView.java:1777)
       at android.view.View.updateDisplayListIfDirty(View.java:18250)
       at android.view.View.draw(View.java:19042)
       at android.view.ViewGroup.drawChild(ViewGroup.java:4271)
       at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4054)
       at android.view.View.draw(View.java:19317)
       at android.view.View.updateDisplayListIfDirty(View.java:18250)
       at android.view.View.draw(View.java:19042)
       at android.view.ViewGroup.drawChild(ViewGroup.java:4271)
       at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4054)
       at android.view.View.draw(View.java:19317)
       at android.support.v4.view.ViewPager.draw(ViewPager.java:2420)
       at android.view.View.updateDisplayListIfDirty(View.java:18250)
       at android.view.View.draw(View.java:19042)
       at android.view.ViewGroup.drawChild(ViewGroup.java:4271)
       at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4054)
       at android.view.View.updateDisplayListIfDirty(View.java:18241)
       at android.view.View.draw(View.java:19042)
       at android.view.ViewGroup.drawChild(ViewGroup.java:4271)
       at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4054)
       at android.view.View.updateDisplayListIfDirty(View.java:18241)
       at android.view.View.draw(View.java:19042)
       at android.view.ViewGroup.drawChild(ViewGroup.java:4271)
       at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4054)
       at android.view.View.updateDisplayListIfDirty(View.java:18241)
       at android.view.View.draw(View.java:19042)
       at android.view.ViewGroup.drawChild(ViewGroup.java:4271)
       at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4054)
       at android.view.View.updateDisplayListIfDirty(View.java:18241)
       at android.view.View.draw(View.java:19042)
       at android.view.ViewGroup.drawChild(ViewGroup.java:4271)
       at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4054)
       at android.view.View.updateDisplayListIfDirty(View.java:18241)
       at android.view.View.draw(View.java:19042)
       at android.view.ViewGroup.drawChild(ViewGroup.java:4271)
       at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4054)
       at android.view.View.draw(View.java:19317)
       at com.android.internal.policy.DecorView.draw(DecorView.java:915)
       at android.view.View.updateDisplayListIfDirty(View.java:18250)
       at android.view.ThreadedRenderer.updateViewTreeDisplayList(ThreadedRenderer.java:684)
       at android.view.ThreadedRenderer.updateRootDisplayList(ThreadedRenderer.java:690)
       at android.view.ThreadedRenderer.draw(ThreadedRenderer.java:804)
       at android.view.ViewRootImpl.draw(ViewRootImpl.java:3199)
       at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:2997)
       at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2526)
       at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1515)
       at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:7266)
       at android.view.Choreographer$CallbackRecord.run(Choreographer.java:981)
       at android.view.Choreographer.doCallbacks(Choreographer.java:790)
       at android.view.Choreographer.doFrame(Choreographer.java:721)
       at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:967)
       at android.os.Handler.handleCallback(Handler.java:808)
       at android.os.Handler.dispatchMessage(Handler.java:101)
       at android.os.Looper.loop(Looper.java:166)
       at android.app.ActivityThread.main(ActivityThread.java:7529)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:245)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:921)

It seems likely that this is related to #8827 – both are platform-specific Android 8 issues.

reference: 5a76a4fa8cb3c2fa634286c6-fabric
reference: 5af4233111e9fa0aa513dfa0-fabric
marked as high priority as it's happening ~35 times/day and affecting ~800 users

[jkmassel]

Possibly related to wordpress-mobile/AztecEditor-Android#729 and wordpress-mobile/AztecEditor-Android#516

[SiobhyB]

There's a report in 1812801-zen that seems to match up with this crash report in Fabric.

The user's device is a Samsung SM-J400M and it's running on Android 8.0.

The app crashes when they attempt to use voice dictation after uploading more than three photos at a time.

@jkmassel: Is there any extra info from the user that'd be useful for troubleshooting this further?

[charliescheer]

Another potential report in 1861204-zen. We had the user update to the most recent version and the problem persists.

Android device name: HUAWEI GRACE
"Almost always when I want to open my blog posts, the app crashes."

[designsimply]

reference: 5a76a4fa8cb3c2fa634286c6-fabric reference: 5af4233111e9fa0aa513dfa0-fabric marked as high priority as it's happening ~35 times/day and affecting ~800 users

Combining stats for the last 30 days for 5a76a4fa8cb3c2fa634286c6-fabric and 5af4233111e9fa0aa513dfa0-fabric:

Crashed ~90 times a day or 2844 times for 809 users in the past 30 days Feb 14 - Mar 14, 2019.

Crashes are trending up for 11.9 in 5af4233111e9fa0aa513dfa0-fabric.

[malinajirka]

I can confirm it's related to
wordpress-mobile/AztecEditor-Android#729 and wordpress-mobile/AztecEditor-Android#516

Unfortunately, it's a bug in the OS which was introduced in Android 8.0 and was fixed in Android 9.0 (https://android-review.googlesource.com/c/platform/frameworks/base/+/634929).

wordpress-mobile/AztecEditor-Android#516 contains steps how to reproduce the issue.

All these crashes seems related - it also seems the crash is not specific to Huawei phones. It's specific to Android 8.0 and 8.1.
5a86f7f48cb3c2fa632d5149-fabric
5af4233111e9fa0aa513dfa0-fabric
5a76a4fa8cb3c2fa634286c6-fabric
5a04a91461b02d480d160132-fabric
5ac6aba236c7b23527a48419-fabric
5b9ef56df8b88c2963244ca6-fabric
5ae8d77a638393737aeae584-fabric
5ae6655f638393737ab63fe7-fabric

If we sum up all these crashes, it's definitely our #1. I can think of 3 options we have, but none of them is great.

• Disable hardware acceleration for the EditText. However, imho we can't do that for Aztec as it'd have huge performance impact for all our users.
• Copy-paste Editor.java and TextView.java from google sources for Android 8.1 -> fix the bug in the Editor.java. Create a CustomTextView in Aztec repo which would use the copy-pasted files on Android 8.0 and 8.1. This solution is hacky and it might bite us.
• Don't do anything at all as the bug is fixed in Android 9 -> Do we know whether the bug occurs with Gutenberg?

Wdyt @daniloercoli ?

[rfaile313]

from 1861204-zen

"It's not when trying to open a specific post, but instead when trying to view the list of posts"

[daniloercoli]

It seems the issue is not only happening when opening the editor @malinajirka. Also when accessing the posts lists, accordingly to the report ^ above.

[jkmassel]

Are we able to detect the current Android version in code, and use a different path for that?

I think either of those two solutions could be applied judiciously, perhaps as a setting? I'd imagine we could detect if a user crashed in the editor on Android 8, and prompt them on next launch to enable "compatibility mode" or whatever we want to call it that fixes the issue in v8. Then, if they later upgrade to v9, we silently disable it?

Typically for a simple bug we might not go to all this trouble, but it seems quite widespread.

WDYT @malinajirka / @daniloercoli ?

[malinajirka]

"It's not when trying to open a specific post, but instead when trying to view the list of posts"
It seems the issue is not only happening when opening the editor @malinajirka. Also when accessing the posts lists, accordingly to the report ^ above.

I've checked the ticket and I haven't found any indication it's the same crash. I might be missing something. cc @daniloercoli

Are we able to detect the current Android version in code, and use a different path for that?

Yes.

I think either of those two solutions could be applied judiciously, perhaps as a setting? I'd imagine we could detect if a user crashed in the editor on Android 8, and prompt them on next launch to enable "compatibility mode" or whatever we want to call it that fixes the issue in v8. Then, if they later upgrade to v9, we silently disable it?

I'll try to measure the performance impact if we turn off the hardware acceleration - it's definitely the easiest and the only not-so-hacky solution.

The option 2 should be considered as a last resort solution which might not be even worth it. Especially since we don't have feature flags and we won't be able to disable the "fix" if something goes wrong - which can easily happen on custom roms. We'll definitely need to consult it with other Android devs to consider the risks.

I'm not sure we can somehow detect the app crashed.

• If we could wrap it in try/catch block, we could also try to recover from the exception. However, since the crash doesn't happen in our code, I'm not sure we can do that.
• We could register our own UncaughtExceptionHandler, but I'm a bit worried we'd override Fabric's handler. I'd need to look into this - we might be able to call the Fabric's handler within our handler.

However, we know it'll crash under certain circumstances on Android 8. So if we come up with a solution, we can just enable it by default on Android 8.

[daniloercoli]

We could register our own UncaughtExceptionHandler, but I'm a bit worried we'd override Fabric's handler. I'd need to look into this - we might be able to call the Fabric's handler within our handler.

Yes I think this is a good idea. Take a look at AztecExceptionHandler since we're already doing "things" on crashes on Aztec 😬

I'll try to measure the performance impact if we turn off the hardware acceleration - it's definitely the easiest and the only not-so-hacky solution.

I guess we can turn off the hardware acceleration when we detect the crash happened on Android 8. Just store a property, and disable the HW acceleration at next startup when the prop is true and Android == 8. I'm not sure about prompt the user about it, since it will be hard to explain where to go to enable the Compatibility mode, and why it's required. Maybe we can show a prompt "Compatibility mode enabled", explain why in the message, and give some info about how to turn it off in App settings. Where we should add a toggle for it.