Inventory data before writing exclusions
List authentication tokens, private user content, cached server responses and device-bound state. Decide which data should survive device replacement and which must be regenerated or reauthenticated. Restoring unusable encrypted data can be a reliability problem even when the ciphertext is not directly readable.
The Android backup documentation distinguishes configuration behavior across Android versions and backup or device-transfer paths. Use the rule format appropriate for the API levels you support rather than assuming one manifest flag covers every transfer scenario.
Keep legacy and newer rules coherent
Apps may need both older fullBackupContent rules and newer dataExtractionRules, depending on supported devices and target behavior. Review cloud backup and device-to-device transfer separately.
An illustrative newer rule fragment excludes a sensitive preferences file from cloud backup:
<data-extraction-rules>
<cloud-backup>
<exclude domain="sharedpref" path="session.xml" />
</cloud-backup>
</data-extraction-rules>
This fragment is not a complete policy. Add the intended device-transfer rules and verify actual filenames and storage domains. A wrong path can make an exclusion ineffective.
Test restoration, not just XML
Create synthetic data, trigger the supported test workflow for your environment, and restore into a clean installation or test device. Confirm which data returns and whether the app handles missing credentials gracefully.
Do not assume Android Keystore keys will be restored alongside encrypted preferences. Design the app to recover safely when protected data exists but its device-bound key does not.
Avoid broad claims from one flag
allowBackup and related settings need to be interpreted with device version, target SDK and transfer behavior. Record the tested combinations. “Backups disabled” is too strong when only one path was inspected.
Inspect the packaged policy
APKLint's manifest and security review can help identify backup-related declarations. The decisive evidence is the packaged rule set plus a controlled restore test. Do not mark a data-handling review complete merely because the manifest contains a restrictive-looking attribute.
Separate a recoverable document from a device-bound session
Imagine an invoice app storing a display preference, downloaded invoices and a session credential. The preference may be useful after migration; the invoices may be recoverable from the account; the credential may require reauthentication. Assign each item an explicit restore policy before selecting XML paths. A single label such as app data hides these different recovery requirements.
The Auto Backup guide describes the storage domains and version-dependent rule formats. Confirm the actual filename and location of every excluded item. A preference name used in source code is not necessarily the complete filename expected by a backup rule, and moving storage during a refactor can invalidate an otherwise unchanged exclusion.
Use distinct markers to verify the restore boundary
In a controlled test build, create synthetic markers for the preference, cached document and credential record. Back up through the supported test workflow, restore into a clean environment and inspect which markers return. Keep the expected outcome per item beside the observed result. Testing with three identical strings makes an accidental copy or an unexpected source harder to distinguish.
Next, restore an encrypted record without its usable device-bound key. The app should recognize that it cannot open that record and follow its recovery design. It must not label corrupted or unreadable bytes as a valid signed-in session, repeatedly crash at startup or overwrite the only recoverable document without telling the user.
Repeat the relevant cloud-backup and device-transfer paths for supported platform combinations. Record the device software and target SDK with each observation. The platform guide describes differences between those paths, so a successful exclusion in a cloud test is insufficient evidence for a blanket statement that the same item never transfers by another mechanism.
Finally, test account changes after restore. A recovered display preference can remain useful while account-bound content must wait for the correct authenticated user. Ensure a restored local account identifier is treated as a hint to reconcile, not proof that the current user is entitled to every restored document.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
