Google’s latest Chrome update is causing a headache for users and developers of some Android apps. Chrome 79, which is rolling out across desktop and mobile OSes, has been causing data loss for some other seemingly unrelated Android apps. Thanks to this bug, specifically on Android, updating your browser can now do something like wipe out the data in your Finance app.
The connection between Chrome and Android app data might not be obvious, but Chrome on Android isn’t always just the browser that starts up when you press on the Chrome icon. For some versions of Android, the Chrome app can also provide the built-in HTML render for the entire OS. Apps can call on the system render to display in-app Web content (the API is called “WebView”), and, in this case, an instance of Chrome would seamlessly start up and draw HTML content inside your app. Whether you want to call them “HTML apps” or “Web wrappers,” it’s not uncommon for apps to basically be only a WebView. These apps just turn on and load a webpage, and the Web wrapper provides native Android features like an app drawer icon, full-screen interface, and Play Store distribution. These apps look and work mostly like native apps from a user’s perspective, and it’s hard for even technical users to tell the difference. Cross-platform development is a lot easier when you use HTML, though, since HTML code works everywhere.
The data loss happened because Google changed where Chrome 79 stores profile data without entirely migrating the old data. WebView-based apps can store data through APIs like localstorage, WebSQL, and indexedDB, and apps that use these APIs will suddenly stop finding their data after the user upgrades to Chrome 79. The data isn’t deleted, it’s just misplaced. But to a user, there’s no difference. Their favorite HTML-based app will reset itself to a freshly installed state, and their data won’t be visible. By default, app updates on Android happen automatically and without user interaction, so for most users, their app will just wipe itself out and they won’t know why.
If you want to get technical (and, of course, we do), only Android versions 7, 8, and 9 use the “Chrome” app for the system HTML render. Google has long supported the reasonable stance of updating the Android system HTML-renderer through the Play Store, but it has flip-flopped back and forth on whether using the user-facing Chrome app for system HTML duties is a good idea. Android 5 and 6 used a separate package called “Android System WebView” for Web content, which is very close to Chrome, as it’s based on the Chromium codebase. After three versions of using Chrome, Google went back to the purpose-built Android System WebView app for the latest version, Android 10, saying that the Android System WebView should have “fewer weird special cases and bugs.” In this case it wouldn’t have helped, since both Chrome 79 and Android System WebView 79 have this data-loss bug. The point is that the offending system Web renderer app will change depending on your Android version.
Developers are not happy about their app data suddenly disappearing. One developer said the bug was “definitely a failure of the QA. A disaster really. I don’t know how many clients will be affected, could be millions and millions.” Another said, “This is a catastrophe, our users’ data are being deleted as they receive the update.” “Please roll [this change] back ASAP,” begged another developer. “We have years of history data lost.”
The Chrome team has a serious mess on its hands now, since across the ecosystem, users on Chrome 78 have apps that use storage location #1 and users on Chrome 79 have lost all their data and started over using storage location #2. How do you go about fixing this? Chrome Tech Lead Manager Changwan Ryu warned in the bug comments that a fix would be “a very destructive change” since Chrome 79 had “already been rolled out [to] 50% [of users], and data cannot be merged.” Google halted the rollout, but as of Friday, Ryu said a fix would take “at the minimum… 5-7 days.” So the two options available to Google are to roll back to the Chrome 78 behavior and delete the last week-plus of user data, or keep the Chrome 79 behavior and delete potentially years of data.
One Chrome developer, Tobias Sargeant, asked the crowd of developers: “Are you aware that you can test with beta versions of webview? This change was made in beta 6 weeks ago, and had the issue been picked up at that point we would have been able to address it before it significantly impacted users.” Both Chrome and the Android System WebView have “stable,” “beta,” and “dev” versions freely available in the Play Store, and apparently no one caught this change in time.
As for an actual fix, another Chrome developer, Richard Coles, told the group the team will migrate the old Chrome 78 data to the new Chrome 79 location and rename the past week of Chrome 79 data allowing for possible data recovery later. “This means that users who have used the current version and lost access to their old data will get their old data back at the cost of losing access to data newly created since the original M79 update,” Coles said.
Not all developers are happy with losing the last week of data, with one saying, “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.” Coles replied to the developer by saying, “We’re sorry that this is going to cause an issue for you, but different apps are in different positions here and no choice is going to be ideal for all of them.” He added that the Chrome update wouldn’t delete anything, and the developer could create some kind of merging function for their app data.
For now it seems like the fix has hit Chrome Canary, and it should start moving up the Dev, Beta, and Stable channels.