The Android ADB backup format looks simple at first glance: a few lines of text followed by binary data. The complexity appears when you follow what those lines control. The payload can be compressed, encrypted, or both, and the TAR stream inside uses Android specific path conventions and metadata that matter to restoration.
Understanding these layers is useful for building converters, validating backups, troubleshooting corrupted archives, and deciding whether a TAR can be safely repacked.
The File Starts With a Magic Header
Android source code defines the backup magic as ANDROID BACKUP\n. A parser should read exactly that prefix before treating a file as an ADB backup. The next line is the external archive format version. Historical Android source documents versions 1 through 5.
Version 1 was the initial external format. Version 2 provided a version distinction useful for PBKDF2 compatibility handling. Version 3 introduced package metadata support through _meta. Version 4 added support for device encrypted storage locations, and version 5 added support for key value packages.
A safe parser accepts only versions it understands. Reading an unknown future version with old assumptions can misinterpret subsequent bytes.
The Compression Flag
After the version line comes a numeric compression flag. 1 indicates a compressed payload and 0 indicates no compression. Android source wraps compressed backup data in a deflater stream, producing a zlib compressed representation of the inner TAR.
During restore, Android selects an inflater stream when that flag is set. That pairing is why AB to TAR tools must read the flag rather than assume one fixed transformation.
Compression occurs on the TAR stream before the data reaches the encryption layer when encryption is enabled. Conceptually, the pipeline for creation is TAR, optional zlib compression, optional encryption, then the final file output after the text header has been written.
The Encryption Line
The next line names the encryption method. Android source historically recognizes none and AES-256. If the value is none, the binary payload begins immediately after that line. If encryption is enabled, the header continues with more text fields.
Those extra fields include the user's password salt, a checksum salt for the encryption key, a PBKDF2 round count, an initialization vector for the user derived key, and an encrypted key blob.
The key blob carries the information needed to decrypt the actual backup stream. Android verifies a checksum derived from the recovered key material so that an incorrect password can be detected before the system blindly consumes decrypted garbage.
PBKDF2 and AES 256
Android's historical AB encryption scheme derives a key from the user's password using PBKDF2 and salts stored in the header. Android source commonly shows a round count of 10,000 and 256 bit key sizes for this mechanism.
The payload encryption uses AES in CBC mode with padding in the established implementations derived from Android's backup code. The archive does not simply encrypt the user's data directly with the password. Instead, the password protects randomly generated key material, and that key material protects the backup stream.
This layered design is why encrypted AB support cannot be replaced by a generic “decrypt AES with password” function. The parser must reconstruct the exact Android procedure.
The TAR Payload
Once optional decryption and optional decompression have been handled, the result is a TAR stream. Android uses TAR because it supports streaming and preserves useful metadata, but Android overlays a semantic path structure on the archive.
Application content is grouped below apps/<package-name>/. Within that package, domain tokens indicate where data came from. Common tokens include a for APK content, obb for OBB containers, f for files, db for databases, sp for shared preferences, and r for files relative to the app data root. Android source also defines domains for device protected storage in newer format versions.
Shared storage uses the shared/ hierarchy when it is present.
Package Manifest and Metadata Entries
Android's restore process expects metadata about each application. Historically, the first entry for a package includes a _manifest file with package details relevant to restore decisions. Later format versions also introduced _meta information.
These entries are not ordinary user documents. They are part of the restore protocol. Removing them because they look unfamiliar can make a repacked archive less compatible.
For forensic inspection, the manifest and metadata are useful clues because they help establish which package produced the surrounding data and what Android expected during restoration.
TAR Ordering and PAX Extended Headers
Android source includes code for reading PAX extended TAR headers. PAX records let TAR represent metadata that does not fit neatly in traditional header fields, such as long paths or large values.
Order also matters. Established Android backup tools warn that recreating a TAR with a generic archiver can produce an archive that is valid by TAR standards but unsuitable for Android restore. Android restore processing is sequential and expects package metadata and file domains in a meaningful stream order.
For a converter, this creates two different validation levels. The first asks whether the output is a legal TAR. The second asks whether the TAR preserves Android backup semantics. The second level is much harder and should never be implied by a generic TAR parser result.
Reading the Format Safely
A parser should bound every header line. An attacker controlled file should not be able to supply an unbounded line and exhaust memory. Numeric fields should be parsed strictly. Hex values should be validated for expected characters and sensible sizes.
After decryption, zlib decompression needs output limits. TAR entry paths should be normalized. Entry counts and total uncompressed sizes should have safety ceilings. Symlinks and unusual TAR entity types require deliberate handling rather than automatic extraction.
Security is part of format correctness. A parser that understands the header but allows path traversal during extraction is not production ready.
What Format Version Tells You and What It Does Not
The AB version describes the external backup archive format, not the Android operating system version in a one to one way. Seeing version 5 does not tell you the exact phone model or Android release that created the file.
Likewise, a parser supporting versions 1 through 5 does not guarantee that every backup created by every OEM will behave identically. Vendor modifications, historical bugs, and unusual backup implementations can introduce edge cases.
A converter should report the detected version and then describe exactly which encryption and archive variants it has tested.
Round Trip Integrity
For a conversion library, round trip testing is one of the strongest checks. Start with known AB fixtures, unwrap them into TAR, wrap the TAR back into AB using supported options, then unwrap the result again. Compare archive contents and metadata where preservation is expected.
Encrypted fixtures should be tested with correct and incorrect passwords. Compressed and uncompressed fixtures should both be included. Corrupted headers, truncated streams, invalid zlib data, and malicious TAR paths should be negative tests.
Conclusion
The Android ADB backup format is a layered stream: a text header identifies format version, compression, and encryption, while the payload ultimately resolves to an Android structured TAR archive. Compression uses zlib, encryption uses the historical Android AES 256 scheme, and the TAR itself carries package paths and metadata expected by restore logic.
The format is simple enough to parse but strict enough that small assumptions can cause broken conversions. Good software validates every layer independently and is careful not to confuse a readable TAR with a guaranteed restorable Android backup.
FAQs
Why can an AB header be longer for one file than another?
Encrypted backups include additional text fields after the encryption line, so the binary payload begins later than it does for an unencrypted backup.
What do AB format versions 3, 4, and 5 add?
Android source history describes version 3 as adding _meta metadata, version 4 as supporting new device encrypted storage locations, and version 5 as adding key value packages.
Is the inner archive always gzip?
No. Android's AB compression is based on zlib deflate streams, not a normal standalone gzip file with a gzip header.