Cht-core: Investigate the possibility of dropping Crosswalk

[garethbowen]

Chrome 55 introduced the persistent storage API which means offline storage should not be cleared unless the user manually clears it.

When storage on the local machine is running tight (“under storage pressure”), user agents automatically clear storage to make more available space. Of course, for offline apps, this may be unfortunate, as they may not have synced their data to the server yet, or they may be apps that the user expects to just work offline (like a music player); so the Storage spec defines two different modes for storage for a given domain - “best effort” and “persistent”. The default mode, of course, is “best effort”. Storage for a domain that is “best effort” (aka “not persistent”) can be cleared automatically, without interrupting or asking the user. However, “persistent” data will not be automatically cleared. (If the system is still under storage pressure after clearing all non-persistent data, the user will need to manually clear any remaining persistent storage.)

https://developers.google.com/web/updates/2016/06/persistent-storage

This is the main reason why we need Crosswalk.

1. Test the feature works as expected allowing us to use 100% of the available disk space without ever deleting data.
2. Investigate replacing Crosswalk with native android webview and ensure there aren't any other Crosswalk features we rely on.
3. Ensure we can increase our minimum Android version to 5.0.0 (required so the webview can be updated separately to Android) and our minimum Chrome version to at least 55 (so we can use the persistent storage feature).
4. Add code to request persistent storage for the domain.

[kennsippell]

Based on https://github.com/medic/medic/issues/5540, XWalk has a 150MB memory overhead. This exceeds the target per-app memory allocation for many Android devices. As part of this investigation, how does the webview memory footprint compare? (PSS from running adb shell dumpsys meminfo org.medicmobile.webapp.mobile)

[garethbowen]

Related: #5551

[garethbowen]

I spent some time testing this and it appears that modern webviews can use much more space on the device before hitting a quota limit. On my Tecno Y4 with the default android browser it errored out at around 10% of available space, but with the latest Chrome it got to over 25% with no error.

One concern is in Chrome there is no way to force it to prompt for persistent storage - the browser decides whether or not your site qualifies based on how much its used. I'm sure our app will qualify eventually but there will be a window of time where the data is in temporary storage. Due to the increased quota this shouldn't be an issue until the phone actually starts to run out of space, and because most of our users should _only_ be using our app this should be acceptable.

I'm sure we can raise the minimum Android and Chrome versions in the next major as both were obsolete years ago. This will be a blocker for some projects but I hope it will encourage them to start upgrading their devices to ones made more recently.

I still need to test that our app doesn't depend on any other crosswalk features and check the memory usage.

[garethbowen]

I met with a Google rep who is currently rewriting the docs on storage quotas. According to him an app with persistent storage granted can access 60% of total storage on the device. This may be enough for us. He also recommended using Trusted Web Activity instead of a webview to get full Chrome features.

@abbyad also pointed me to this plugin for cordova some of which could be useful for migrating data from Crosswalk to TWA without having to do an initial replication again.

[ngaruko]

@garethbowen , @abbyad . Maybe time to look at this and get it done before we update target SDK version to 29 (issue medic-android/106). Apparently crosswalk is not supported in latest version of android...and the above issue if failing on android 10

[garethbowen]

The transition to Webview has been forced in order to get Android 10 compatibility. Closing.