After an Android AB backup is decrypted and decompressed when necessary, the inner TAR does not look like a normal copy of /data/data. Android uses a synthetic path hierarchy that tells the restore system which package and storage domain each file belongs to.
Understanding those paths makes archive browsing and selective recovery far easier. It also explains why copying extracted directories directly back to a phone is not equivalent to Android restore.
The `apps/` Prefix
Private application backup data is grouped below apps/. The next path component is the Android package identifier, for example apps/com.example.app/.
The package name is the primary organizational key. It is more reliable than a marketing name because Android's package manager uses it to identify the application.
A multi app AB can therefore contain many package roots under apps/.
The Package Manifest
For each package, Android writes a _manifest entry containing metadata used by restore logic. Historical source comments describe the manifest as the first entry associated with a package stream.
The manifest is not a user file from the app's normal files directory. It belongs to the backup protocol.
Preserve it when analyzing or repacking archives. Removing it because it looks artificial can damage restore compatibility.
The APK Domain: `a`
When the original backup includes APK content, Android stores the application package under the a domain.
An APK can help identify the exact application version or resources associated with the backup. However, presence depends on how the backup was created; APKs are not guaranteed.
Do not install recovered APKs automatically. Treat them as untrusted executable packages until verified.
The OBB Domain
Large application expansion files historically used OBB containers. These can appear in the obb domain for the owning package.
OBB data can be large and is usually asset content rather than private account state. It may still matter for games or applications that depended on expansion packages.
Modern application delivery has evolved, so OBB based layouts are more characteristic of older ecosystems.
The Files Domain: `f`
The f domain represents content rooted at the application's files directory. Apps use this area for private persistent files that are not databases or shared preferences.
You may find JSON documents, custom binary formats, exports, cached models, downloaded content, or user generated files here.
The exact meaning is application specific. Preserve paths and inspect signatures rather than assuming a filename tells the whole story.
The Database Domain: `db`
The db domain corresponds to the app's database path area. SQLite is common, so .db, WAL, SHM, and journal files may appear together.
For recovery, extract related database files as a set. A WAL can contain recent committed changes that are not yet merged into the main database.
An app can also use non SQLite files in its database directory, so treat domain as storage origin, not a guaranteed file format.
The Shared Preferences Domain: `sp`
The sp domain represents files from the shared preferences directory. These are commonly XML files containing small key value settings.
Preferences can reveal feature configuration, account identifiers, timestamps, migration flags, or other state. They may be sensitive even when they look simple.
App developers should exclude secrets from backup where appropriate, but old archives may still contain values worth protecting.
The Root Relative Domain: `r`
The r domain contains files stored relative to the broader root of the app's private file tree. It catches data that does not fit the more specific categories.
This area can include application support structures and custom files needed for state reconstruction.
Do not confuse the Android backup r token with the root directory of your desktop operating system. It is a semantic backup domain.
Cache Domain Behavior
Android source documents a cache domain token but notes that cache content is not stored in the normal full backup flow. Cache is designed to be recreatable and is usually excluded from backup.
If a user expects every cached image or network response to appear in the AB, that expectation is incorrect. Backup focuses on persistent eligible data rather than transient cache.
This is another reason missing files do not automatically indicate corruption.
Device Protected Storage
Later AB format evolution added support for device encrypted or device protected storage locations. These are storage areas accessible before the user fully unlocks credential protected storage after boot.
The exact domain tokens and handling depend on Android version and backup format version.
A viewer should label these domains carefully and preserve raw paths for technical users.
The `_meta` Entry
Android backup format version history describes version 3 as introducing _meta metadata. This supports backup system information beyond ordinary package files.
Like _manifest, _meta should be treated as protocol metadata. It is useful for analysis and should not be edited casually.
A generic archive cleaner that deletes underscore prefixed files can therefore break Android semantics.
Shared Storage
Shared storage, when included in the original backup, appears under a synthetic shared/ hierarchy rather than under an app's private package directory.
This can contain media, documents, exports, and other user accessible files. Its size can dwarf private app data.
Because multiple apps can interact with shared storage, assigning every shared file to one package is not always possible from the TAR path alone.
Entry Order and Restore
Android restore processes the TAR stream sequentially. Package metadata and domain entries are expected in a coherent order. PAX extended headers can carry long path or size information.
For inspection, archive order is mostly a technical detail. For repacking, it can become critical. Rebuilding the same folder tree with a generic TAR utility can produce different ordering and metadata even when the file contents are identical.
Keep the original TAR whenever restore compatibility matters.
A Sample Mental Model
Think of apps/com.example.app/db/main.db as a statement: this file belongs to package com.example.app, and Android backed it up from the application's database domain under the relative name main.db.
apps/com.example.app/sp/settings.xml similarly identifies a shared preference file. shared/DCIM/photo.jpg represents content from shared storage rather than private package data.
This semantic model is more useful than treating the TAR as an arbitrary directory tree.
What Is Not Represented
An AB is not a raw disk image. It does not capture every Android filesystem inode, kernel file, protected system secret, or application directory automatically.
Only data selected by the backup mechanism and application policy enters the stream. Modern restrictions narrow that further.
Forensics and recovery work should therefore describe the archive as a backup dataset, not a complete physical image of the device.
Conclusion
Android AB stores application data inside a TAR using package roots and semantic domain paths. APKs, OBB files, app files, databases, shared preferences, root relative data, device protected storage, manifests, metadata, and shared storage all have distinct roles.
Understanding this structure makes browsing, extraction, and troubleshooting much more precise. It also shows why Android backup TARs deserve preservation beyond their visible file contents: path semantics, metadata, and ordering are part of the restore story.
FAQs
Does `apps/<package>/db/` always contain SQLite files?
No. It identifies the application's database storage area, but an app can place different file formats there.
Why is shared storage not grouped beneath each package?
Shared storage is a broader device storage area and can contain files accessible outside one private app sandbox, so Android represents it separately.
Are cache files normally included in an AB backup?
Generally no. Cache directories are intended to be recreatable and are excluded from normal backup behavior.