2

A few days ago our two Cordova/famo.us based mobile apps started rendering the NavBar and Scrollview with unexpected behaviors.

It took me sometime to get to the root of the issue, since this happened on different devices.

As of Android 5+ Android System WebView is a separate APK and gets updated quite frequently but silent.

On our S5 we got an Android upgrade to Android 5.0 and on S6 (Android 5.0.2) the webview updated to version 43.0.2357.121. And these upgrades/updates were responsible for our rendering issue.

Other frameworks, such us Sencha, have even reported app crashes.

If you have also weird issues with you cordova/famo.us app on Android it might be worth to wait for an update from Google instead of trying to fix your app with a workaround.

As a workaround while developing you can uninstall webview updates on your device by going to Applications -> Application Manager -> All -> Android System WebView.

Anyone else having similar issues?

bardu
  • 727
  • 2
  • 8
  • 24

4 Answers4

4

since past few days we have been experiencing the same issues with all of our sencha touch and cordova based app's. Many of our app users have been reporting this weird behavior and it was really hard to figure that the culprit was actually an update to android system webview.

Original issue's can be viewed here, as they have already been reported to google.

http://code.google.com/p/chromium/issues/detail?id=481380 https://code.google.com/p/chromium/issues/detail?id=479767

Though it's already fixed in WebView 42.0.2311.138 which is released to beta channel. Let's hope this will rolled out to stable soon.

For now the workaround mentioned by @bardu seems to be the only viable solution.

Meer
  • 238
  • 2
  • 7
  • We just got a new webview version 44.0.2403.90 on our devices, however, the issue with our app still persist. No error messages in Chrome remote debugging. – bardu Jul 28 '15 at 00:33
  • @bardu i was able to fix this issue by overriding the **PaintMonitor** and **SizeMoniter** classes in Ext.util. see details here [chrome 43 breaks sencha touch issue](http://www.ladysign-apps.com/developer/chrome-43-breaks-sencha-touch-modern-toolkit-and-how-to-fix-it/#.VbcpAYR7h5S), let me know if it helps. – Meer Jul 28 '15 at 07:07
  • @bardu if you are using **Ext.menu.Menu** class in your app. please check this as well [Override Ext.Menu.Menu](http://www.ladysign-apps.com/developer/chrome-43-breaks-ext-menu-menu-submenus-ext-js-4). – Meer Jul 28 '15 at 07:12
  • I don't use Sencha but Famo.us. There seem to be a couple of known bug (fixes) [421946](https://code.google.com/p/chromium/issues/detail?id=421946) and [456601](https://code.google.com/p/chromium/issues/detail?id=456601) but none to help with our issue – bardu Jul 28 '15 at 19:31
2

We are experiencing the same thing and it was a real bear to diagnose. Terrifying too, because this can mean a couple hundred thousand of our users suddenly completely broken. I'm just glad we did not ship a build of our app anytime close to when WebView 43.0 was released, so it is clear that we did not change anything.

It seems the best thing to do is inform our users of the workaround of uninstalling updates for Android System WebView, while simultaneously getting onto the Google forums and communicating with them about this issue. The trouble is that they are likely to ask us for specific code that is breaking so that they can point out that the new behavior is somehow standards compliant and tell us to change our code. This is difficult because our app is breaking in 50 different ways with this new build. It's just horribly bad. We can only hope that thousands of other Cordova/PhoneGap apps are also broken and that lots of developers contact Google and help them see this. But we have to get involved and start that ball rolling. So how about if we all do our best to voice our issue with Google in their forums?

user1684978
  • 8,569
  • 3
  • 13
  • 6
  • in case you guys have already opened a thread on Google forum can you provide the link? – bardu Jun 18 '15 at 16:54
1

You should checkout https://crosswalk-project.org/ which allows you to pack the chromium web engine together with your application inside your APK. Therefore you are not exposed to these kind of problems. You update the engine when you want and you can run proper QA before pushing it to users. Crosswalk is compatible with various tools like Famo.us, Cordova, PhoneGap and many more and you can deploy back to And4.0.

Alexis Menard
  • 71
  • 3
0

I had a similar problem as the one described in the OP's question above. So I will post what worked for me, to help anyone else experiencing rendering problems with a cordova app deployed to Android 10. The basic problem seems to be hardware acceleration not working well in the WebView which cordova is using. To fix the problem, I disabled hardware acceleration in AndroidManifest.xml. You can edit the file manually then rebuild and deploy the apk to your Android device/VM.

  • Find the AndroidManifest.xml file at ./platforms/android/app/src/main/AndroidManifest.xml
  • Find and replace all instances of android:hardwareAccelerated="true" with android:hardwareAccelerated="false"
  • Rebuild and reinstall the apk to your Android device or VM.

If the above fixes your problem, then great! You can add the fix to your build process by using the <edit-config> tag in your cordova project's config.xml file as follows:

<?xml version='1.0' encoding='utf-8'?>
<widget id="replace.with.your.app.id" version="replace.with.app.version" xmlns="http://www.w3.org/ns/widgets" xmlns:cdv="http://cordova.apache.org/ns/1.0" xmlns:android="http://schemas.android.com/apk/res/android">

    <!-- ... -->

    <!-- https://cordova.apache.org/docs/en/10.x/plugin_ref/spec.html#edit-config -->
    <edit-config file="AndroidManifest.xml" mode="merge" target="/manifest">
    <manifest android:hardwareAccelerated="false" />
    </edit-config>
    <edit-config file="AndroidManifest.xml" mode="merge" target="/manifest/application">
        <application android:hardwareAccelerated="false" />
    </edit-config>

    <!-- ... -->

</widget>

Note the xmlns:android="http://schemas.android.com/apk/res/android" attribute in the <widget> tag. That is needed so that gradle will understand the android:hardwareAccelerated attribute.

c.hill
  • 3,127
  • 25
  • 31