Q impact on Swift Backup
This article will be updated as and when I discover new findings regarding any Android Q APIs impacting SB
With Android Q beta 4 release and the API changes now locked in, it is time to evaluate how the changes impact SB.
App backup/restore: No change
The recently released Q beta 4 removed the sandboxed app directories feature that was introduced in beta 3. This means that Ext. Data and Expansion directories of apps/games don’t change and SB should backup/restore apps as usual without any change. Sandboxing will most probably return in Android R.
SMS, Call Logs, Wallpapers backup/restore: No change
There is a bug regarding default SMS request prompt which SB needs to make when restoring SMS (Only the default SMS app can write to the SMS database). Currently, there is a delay and crash caused by the system. The bug is reported to Google.
WiFi Networks backup/restore: Broken
WiFi APIs have taken a hit and apps can no longer ‘get’ the saved WiFi networks or ‘add’ via official APIs.
I feel the best approach for WiFi backups from Android Q onward is to just save the WiFi passwords and then reveal it or copy to clipboard for a manual restore by user.
Why not use root access to manipulate the wifi_supplicant file within the app?
Its buggy, hacky, and doesn’t work on recent Android versions due to encrypted checksum verification of the file. So, not happening. Period.
A caveat on recent Samsung devices (Android Pie onward), the WiFi passwords are not saved in plain-text, but instead, as encrypted or encoded text. Don’t rely on SB to backup/restore WiFi networks on such devices. I won’t be surprised if this becomes a norm in AOSP in Android R.