Clearing cache on Android device is ineffective.

[noozoo]

@macdonst As mentioned privately. Nexus 6 with Android 7.0. If I first clean the cache and data of my app, then uninstall the app, and then reinstall it, I see the old javascript running when I inspect in Chrome://inspect.

Any workaround you know of would be helpful.

[noozoo]

Update. After clearing the cache and data, uninstalling, and then restarting my phone, the new code is in there.

[aramando]

It's almost certainly caused by Auto Backup for Apps. When reinstalling an app, its data is restored from a backup associated with your Google account. I started seeing this issue when I upgraded from a Nexus 5 running Android 6.0.1 to a OnePlus 3 on the same OS version, and still do with Android 7.0.

The solution is simply to clear the app data after you install the new version of the APK. You don't need to uninstall the existing version beforehand or restart the phone at any point.

You can prevent the behaviour by disabling Automatic restore in the system Backup & reset settings, or by putting the phone into flight mode so that it can't access the backup - but then you still have to either clear the app data or uninstall the existing APK to achieve the same result before installing and running the updated APK, so it achieves little and has obvious drawbacks.

[noozoo]

When you clear the cache or uninstall there ought to be an option to remove the backups, too. Something Google is working on, hopefully.

[macdonst]

@noozoo @aramando What do you guys think about changing the sync directory to the one returned by getNoBackupFilesDir? This lines up with iOS as it stores the sync data in a location that is not backed up to iCloud.

[aramando]

@macdonst I can't think of a reason not to.

[noozoo]

That will prevent that backup from happening for the app?

[aramando]

Presumably it would only prevent the backup of files copied from the app binary or downloaded from the remote content source (e.g. the AEM server), which I don't imagine would ever be required to be backed up (since they can just be re-copied/downloaded).

I suppose it could be made into a plugin config option, defaulting to storing files in no-backup location, but with the option to change that.

[macdonst]

@noozoo can you try the issue167 branch?

[macdonst]

@noozoo did you get a chance to test the issue167 branch?

[noozoo]

No it did not, sorry. A lot has happened, and as you know, we've been moved to other things.

[macdonst]

@noozoo is the ticket getting passed on to someone else to resolve?

[noozoo]

@macdonst I don't think we have a Jira ticket for this.

If you like I could create one and assign it to Rofe, but I don't know when it'll get looked at...

[macdonst]

@noozoo please do

[noozoo]

@macdonst Done: https://jira.corp.adobe.com/browse/CQ-4205539

[noka03]

It looks like changing this location puts the sync'd files in a location that is very slow to read from when using the cordova-file-plugin rather than the read write location provided by cordova.file.dataDirectory which is reasonably fast.