Explore and document limitations using WebView version

[abbyad]

With the improvements from #134, the WebView version becomes an increasingly viable alternative to XWalk on older Android versions too (5-9). Given that the WebView APK size is <1MB vs 25MB, Android app upgrades are easier when connectivity is limited, and the app will generally be able to run on newer browser versions than with the XWalk version. To ensure that the WebView version will continue to work well on older devices in the long run we should further explore the limitations, especially around the following areas:

• Disk space usage, and how much storage can we realistically use on older (and smaller) devices
• Persistence of storage, and how/when is it lost (leading to accidental data loss if sync did not occur in time)
• Browser versions, and how do we handle devices where WebView has not actually been updated?

There may be other areas to explore and can be added as part of this investigation. We should document the limitations and can spawn off issues for any areas in the app that need improvements.

[abbyad]

Related to #169

[garethbowen]

We have some evidence that around 800 BRAC users are on v0.8.0 and using webview already (presumably Android 10+). Gathering more information about those users could help identify and issues.

[latin-panda]

During our site visit, the BRAC VHTs and CHWs that we spoked to are using Android 10

[jkuester]

Just wanted to note that our request for persistent storage seems to never be granted when running via the Webview version of cht-android. I have tested this both on Android 5.1 and 12 and both devices continued to deny persistent storage even after it was requested 10+ times.

At the same time, I did verify that when running in the device's browser (or as a PWA), then persistent storage was granted pretty much immediately.

[garethbowen]

@jkuester Persistent storage in the browser sometimes prompts the user for confirmation (I'm assuming you granted this in the browser/PWA?). What happens in the webview? Do you ever see a prompt, or is it silently ignored forever?

[jkuester]

@garethbowen I did not ever see a prompt in WebView. (I also did not see a prompt today with the browser/PWA, but it is possible that I accepted it previously...)

[garethbowen]

Now that I think about it it may be that the prompt is only on Firefox. Chrome has a complex set of conditions that must be met to get persisted storage, and it may be that you have to visit the site over multiple days.

[jkuester]

Ah, that's great. Well for the record, I did anecdotally test what happens with the webview version of cht-android when you do not have persisted storage and your phone runs out of storage.

• Disconnected the phone from the CHT server
• Created a report on the phone (that did not get synced to the server)
• Filled up the phones storage completely (all the warnings flashing, can't take pics/video or download anything else).
• Tried to open the app - it gave the storage warning and then failed to even load
• Deleted some files to get some space back
• Loaded up the app and the new report was still there

Seems rather certain (based on various things I have read) that this is not guaranteed with webview, but was nice to know that the app's data was not cannibalized instantly when the phone ran out of space...

[jkuester]

Attaching debug APK.

cht-android-SNAPSHOT-unbranded-arm64-v8a-debug.zip

[njogz]

Findings after testing and some research.

Disk space usage
According to this article Chrome allows the browser to use up to 80% of total disk space. An origin can use up to 60% of the total disk space. Using the code snippet provided the figures we got are very much in line with the 60%. In the devices we tested with you are much more likely to get to the limit of the avalible disk space before reaching the 60% limit of total disk space given other apps and usage of the phone.

Persistence of storage
I was able to replicate what @jkuester mentioned above in term persistent storage not being granted when using the webview version. I tested on Android versions 9 and 12. The fact that we are able to store gigabytes of data and have it still be available after multiple app restarts and crashes means we do have some sort persistent storage. The only exception to this is that I manged to lose all data synced on the Android 9 device after trying to sync more data when the phones storage was basically full. There is a separate issue created to address this. It is, however, worth mentioning that @tatilepizs carried out the same test on an Android 5 device and the data was intact after the app crashed due to lack of storage.

Browser versions
Apart from the different behaviour in terms of data recovery from a crash mentioned above there no other glaring differences in terms of how different versions of webview handled the app. The Android 5 device was on webview version 95 while the Android 9 device was on webview version 74 befire being upgraded to the latest version which is 101.

A big thank you to @jkuester and @tatilepizs for their help in the tests

[njogz]

Android 5 device screenshots
Before first login

Before app crash

Failure

After app crashed

Android 9 device failure screenshots

[latin-panda]

@garethbowen do we want to fix the data loss issue in a future release?

If yes, can we close this issue? I think the research is finished cc: @njogz

[garethbowen]

Yeah I think we can close this, thanks.

[latin-panda]

Thank you, I'm closing this issue