Check the release artifact

Android uses app settings and data extraction rules to decide what may be backed up. The merged manifest in the release build is the source to inspect because libraries and build variants can change it. List shared preferences, local databases, files, and WebView storage. Mark each item as public cache, customer data, credential, or secret. Then compare the list with the backup rules.

Run a restore with a synthetic account. After restore, search files for the fake account name, transaction details, access token, refresh token, and private key material. Then start the app without signing in and try an authenticated API call. A server rejection proves more than a file rule alone. If a restored UI still shows cached private data, record that as a separate exposure even when server tokens are invalid.

Use a fake-value inventory

Before backup, place unique fake markers in preferences, local database, cached statement, and test session. Inspect the merged release manifest and data extraction rules. Restore to phone B by cloud backup and direct transfer, then search each marker in files and UI. Try a token refresh from B. A denied refresh does not clear a restored private statement; both outcomes need separate checks. Record OS version and restore path because Android applies rules differently across modes.

Test cases and proof

Use test accounts and test data
CaseExpected resultProof to keep
Restore tokens on device BRequire fresh session or device proofAuth result
Restore cached account detailsFollow data policyRestored file inventory
Cloud and device transfer differTest both rulesBackup results

Restore a backup into a clean test device

Put fake statement A-101 and a fake refresh token in the app, then run the supported Android backup path. Restore onto a clean device and inspect app state before sign-in. The statement and token must follow the app’s documented exclusion and encryption rules; verify real restored data rather than reading only the XML rules. Test a device transfer path as well as cloud backup where supported. Save OS version, manifest rules, backup mode, restored file inventory, and token outcome. Android supports separate cloud and device-transfer rules on newer versions, so check both. (Android Auto Backup).

State the restore policy before judging tokens

For this test, set a clear policy: statement cache and session credentials are excluded from backup, and a restored app needs fresh sign-in. A marker restored in either store fails that policy. A token that works on phone B fails the stated session rule; token portability by itself does not establish a flaw in every product. Keep the intended rule beside the outcome. Android documents that on some Android 12 and later devices, allowBackup=false disables cloud backup but does not disable device transfer. Inspect dataExtractionRules and test both supported paths. Also test a restored encrypted file whose key is absent: the app must recover without exposing data or crashing.

Related reading

Source