Chrome 79 Update On Android Kills Local Data

‘Unfortunately local storage was missed off the list of files migrated’

Faulty migration code means some Android applications appear to lose their data

Updated A change to the location of profile data in Chrome 79 on Android, the new version rolling out now, means that applications using the WebView component lose data stored locally.

“This is a catastrophe; our users’ data are being deleted as they receive the update,” complained one developer.

“I heard from a company that uses local storage for offline no-connection available that had local record[s] of animals getting vaccination. The update ‘erased’ all the data. They don’t know which animals got [a] vaccine and can’t repeat on all of them. Serious stuff,” said another user.

Google said it has halted the rollout, which is estimated at 50 per cent of devices.

The problem appears to stem from a change to the location of profile data in Chromium, the open source project on which Google Chrome is based. Some applications, such as those built with Apache Cordova, use the WebView component extensively, and in these cases the location of local data is determined by this component.

The upgrade to Chrome 79 should migrate this data to the new location, but a Chromium engineer remarked that “unfortunately local storage was missed off the list of files migrated.”

Another dev noted: “I have the same problem. I use LocalStorage straight away in my Cordova app. Now I got review-bombed with 1-star ratings because all people lose the app data after the latest Android WebView update.”

It gets worse. “There are several more missed migrations. ‘databases’ contains the websql dbs ‘QuotaManager’, and ‘QuotaManager-journal’ tracks site storage quotas,” said another engineer.

Reproducing the bug is not difficult. “To reproduce the problem, just create a Cordova app that uses localstorage or websql, write something in storage having webview or chrome 78 in Android, then update to webview/chrome 79 and reopen the app… The data is lost,” explained a developer.

A further complication is that the problem will not be easy to fix, for those who have upgraded. “Should we remove the data *after* 79 rollout and go back to 78? Should we remove the data before 78 and move on? Either way it will be a very destructive change,” said another member of the team. Merging the data is not considered realistic.

A glimmer of good news is that the update does not really delete the previous data, but only makes it invisible. It can therefore be recovered by a developer or with debug tools, but this is not easy for the user.

The plan now seems to be to revert the storage location back to what it was. This means that if there is new data that the user has created since the update, that will now be hidden, but the old data will reappear.

This looks like a severe bug and raises questions about how well Chrome updates are tested before rollout. It may also cause developers to question the reliability of this approach. Frequent synchronization of data with a cloud service protects not only against bad updates, but also lost or failed devices. Of course this may not be possible in the field, without a reliable internet connection.

We have asked Google how the problem made it into production and will report back with any further information. ®

Updated at 1036 UTC, 18 December, to add

Google has issued the following statement: “The M79 update to Chrome and WebView on Android devices was suspended after detecting an issue in WebView where some users’ app data was not visible within those apps. This app data was not lost and will be made visible in apps when we deliver an update this week. We apologize for any inconvenience.”

There is also a blog post with brief reference to the bug here.

We understand that despite the “50 per cent rollout”, less than 15 per cent of devices were actually updated with the faulty version. This still represents a large number of users, and even when the fixed version arrives, the snag is that any new data entered since Chrome 79 was installed will now be invisible. For example, as this user noted: “Our app collects financial/transactional data (invoices, credits, etc) and absolutely cannot revert to the old data. Our users have assumed their unprocessed data has been lost and have already re-keyed in transactions that they collected while offline. There’s now been 5 days’ worth of new transactions.”

As this Chromium engineer notes, “We’re deeply sorry that this happened and that there is no realistic way to proceed from this point without additional data loss in some cases, but this hopefully represents the best compromise.”

Sponsored: How to get more from MicroStrategy by optimising your data stack