[Feature Request] Include no_backup / full app data and allow data-only restore without the backup APK

Please check before submitting an issue

• I am using the latest version of App Manager
• I have searched the issues and haven't found anything relevant
• I have read the docs
• I know that generating a report, in whole part or in part, using AI/LLM is prohibited

Describe the new feature

App Manager already has one of the most capable backup engines on Android (APK + CE/DE internal data + external data + extras + encryption + rules). Two gaps still force users onto Swift Backup, Titanium Backup, or Neo Backup for everyday “I just want my app state back” work.

1. Incomplete data coverage — no_backup (and similar dirs) are treated as disposable cache

BackupManager currently groups no_backup with cache:

static final String[] CACHE_DIRS = new String[]{"cache/.", "code_cache/.", "no_backup/.*"};

The docs also state that when cache is excluded, AM ignores no_backup directories.

That is correct for Android Auto Backup (apps put files in Context.getNoBackupFilesDir() so Google Backup will skip them). It is not correct for a root/ADB local backup.

A lot of real user state lives there on purpose so it will not go to the cloud:

• Gboard (com.google.android.inputmethod.latin): personal dictionary, learned typing, language packs, clipboard history
• WorkManager / Jetpack apps: persisted job DBs under no_backup/
• Messengers, keyboards, launchers, offline maps: local indexes, models, session files marked “do not cloud-backup”

Result: a “successful” AM backup of Gboard (and similar apps) restores a half-empty profile. The APK comes back. The data the user actually cared about does not.

Device-protected storage (/data/user_de/) is already listed under Internal data. If any of those trees, or other app-private trees, are still skipped or only partially restored for system/privileged keyboards, that belongs in the same fix.

1. Data cannot be restored independently of the backup’s APK

Peer tools let you:

• keep the APK already on the device (Play / F-Droid / Aurora / a newer build)
• restore only internal + external + DE data (+ extras) onto that install

AM’s restore path is still coupled to the backup APK / source:

• Restore fails if APK files is checked but the archive has no APK, or if the app is not installed
• Restoring a backup taken of version N often wants to reinstall that exact APK instead of overlaying data onto the installed package
• Signature / version-code checks then block the “data-only onto current install” case that Swift documents explicitly (e.g. “install Chrome from Play, restore data only”)

That coupling is reasonable as a default (integrity, split APKs, first-time install). It is the wrong only option.

Typical flows this breaks:

1. App is already installed (same package, possibly a different build). User wants dictionaries / settings / chats back. They should not have to downgrade or re-flash the backup APK.
2. User installed the APK from a store after a ROM flash and only needs data.
3. System / privileged apps (Gboard, Phone, Messages) where replacing the APK is undesirable or impossible, but data overlay is exactly what Titanium / Neo / Swift do.

AM already has Skip signature checks. What is missing is a first-class Data only restore that:

• requires the package to be installed
• does not touch /data/app
• still restores CE + DE + external + extras
• optionally still applies permissions / SSAID / battery / netpolicy

Users can keep a second backup app for these two cases. They should not have to. App Manager already does the hard parts (privileged access, encryption, extras, batch ops). These two options close the last gap that makes people install extra apps for a job AM is already 90% done with.

Describe the solution you'd like

A. Split “cache” from “no_backup” (and make coverage explicit)

In Backup Options, replace the single implicit CACHE_DIRS filter with independent flags, defaulting to today’s safe behaviour:

• Exclude cache/ and code_cache/ (default: on)
• Include no_backup/ (default: off, but visible and documented)
• Internal data already covers /data/user/ and /data/user_de/ — keep that, and surface it as CE data / Device-protected (DE) data so users can see what will be packed.

Optional later: a per-app directory picker (shared_prefs, databases, files, no_backup, DE twins, external, obb, media).

During backup, log which trees were included and their sizes so a Gboard backup that silently dropped tens of MB of no_backup is obvious.

B. First-class data-only restore

In the restore dialog:

• APK / source
• Data (CE)
• Data (DE)
• External / OBB / media
• Extras (permissions, SSAID, battery, netpolicy, rules)

Rules:

1. If the package is installed and APK is unchecked → overlay data only. Do not uninstall, do not pm install the backup APK, do not write the source dir.
2. If the package is not installed and APK is unchecked → fail with a clear message: “Package not installed. Restore the APK first, or enable APK in this dialog.”
3. Keep current APK+data behaviour as the default for uninstalled packages and for 1-Click “Restore not installed apps”.
4. Reuse Skip signature checks when the installed signing cert ≠ backup cert (user-initiated, already exists).
5. After a data-only restore: force-stop the target, restore files with correct UID/GID/SELinux context, optionally restore extras, then leave the existing APK alone.

C. Docs + UI copy

One paragraph in the Backup/Restore docs is enough:

“no_backup/ is excluded together with cache because Android Auto Backup skips it. Local privileged backups can include it; enable Include no_backup for keyboards and apps that keep real state there. Data only restore overlays data onto the APK already on the device and does not reinstall the backup APK.”

A one-line warning when backing up Gboard / other known no_backup-heavy packages if the flag is off would prevent the current “backup succeeded, nothing useful came back” surprise.

Suggested implementation sketch:

1. Remove "no_backup/.*" from CACHE_DIRS. Add a dedicated flag, e.g. BACKUP_NO_BACKUP_DIR.
2. When the new flag is off, exclude no_backup/ from every data root (CE, DE, external if present).
3. When the flag is on, pack those dirs like any other data and record them in metadata / checksums.
4. Restore dialog: if APK flag is off and ApplicationInfo exists for that user, jump to restoreData() + extras and skip restoreApkFiles() / uninstall-reinstall.
5. If APK flag is off and the package is missing → BackupException with the message above.

Acceptance criteria:

• Gboard (and any app that stores real state in no_backup/) can be backed up with that tree when the user enables the option
• Exclude-cache no longer silently drops no_backup
• Restoring data only onto an already-installed package succeeds without installing the backup APK
• Restoring data only of an uninstalled package fails with a clear error, not a generic “unknown error”
• Default flags stay conservative (cache excluded, no_backup excluded) so backup size does not explode for users who never opt in
• Docs mention both options in the Backup Options list

Describe alternatives you've considered

• Uncheck Cache and hope no_backup is packed no_backup is hard-wired into CACHE_DIRS. Even if toggling cache changes this, it is undocumented and mixes two different things (throw-away cache vs intentional local state).

• Restore APK + data together, then update the app from the store Works sometimes. For Gboard / privileged apps it is the wrong direction, and it can fight signatures, split APKs, and Play Protect.

• Disable signature checks and force the backup APK Destroys the install the user already wants to keep.

• Use Swift Backup / Neo Backup / Titanium Backup only for these apps This is what people do today. It works. It also means maintaining two backup formats, two encryption keys, two schedules, and a second privileged app. AM already has batch ops, profiles, encryption (OpenPGP / RSA / AES), extras, and ADB+root. Duplicating that stack is avoidable.

• Manual copy of /data/user/0/com.google.android.inputmethod.latin/no_backup with a root file manager Fragile UID/context, easy to miss DE, not batchable, not encrypted.

No existing issue I found requests this pairing specifically. Related but different:

• #30 — original backup design (APK-first restore is by design there)
• #617 — apps that cannot be fully restored (KeyStore, etc.)
• #1550 — cross-device restore documentation
• #1182 — APK extract failures; comment notes data-only can work if the app is already installed, which is exactly the path that should be a supported, obvious option

Additional context

Why this is worth doing in AM rather than “just use Swift”:

App Manager is already the tool people open for permissions, trackers, 1-click ops, freeze, installer, and backups. Backup is not a side feature here; it is one of the reasons the app exists. The two missing flags are small compared to the engine that is already written:

• trees are already walked and tar’d per data-dir index
• CE and DE paths are already in the metadata
• restore already has a flag word (BACKUP_DATA, BACKUP_EXT_DATA, BACKUP_NO_CACHE, BACKUP_APK_FILES, BACKUP_SKIP_SIGNATURE_CHECK, extras)
• RestoreOp already has a data path separate from restoreApkFiles()

What is needed is to stop treating no_backup as cache, and to allow RestoreOp to skip the APK/source branch when the package is present. That is a contained change, not a new backup format.

This would let App Manager be the single backup tool for the cases it already almost handles, instead of the “use AM for management, use Swift/Neo/Titanium for the actual restore” split that users keep ending up with.