android-backup-extractor (abe): unpack and repack adb backup files

What abe does that adb backup does not

adb backup produces a single .ab file that is compressed and optionally encrypted. It is not a tar archive you can list, and it is not a zip. The README describes abe as a utility to extract and repack Android backups created with adb backup on ICS and later, largely based on BackupManagerService.java from AOSP. That lineage matters: the tool is not guessing at the container format, it follows the same service code that wrote the file.

The audience is narrow and practical. Someone has an .ab file on a laptop and wants to see what is inside it, or wants to change something and push it back. abe gives you a tar in one direction and an .ab in the other. It does not talk to the device. Everything happens on the host machine against a file you already have.

The mechanism: a container around a tar stream

The tool reads the .ab container, decrypts it if a password applies, and writes the inner payload out as a tar archive. Going the other way, it takes a tar and wraps it back into the .ab container, choosing the backup version to match the target Android release. The README lists three subcommands: unpack, pack, and pack-kk, where pack-kk creates version 2 backups compatible with Android 4.4.3.

The important constraint is not the container, it is the tar inside it. The README states that Android is very particular about the order of files in the tar archive, links to the format description, and warns that incompatible tar archives lead to errors or even system crashes. So the hard part of repacking is producing a tar whose entry order matches what BackupManagerService expects, not running the pack command.

Two more behaviours are documented. Apps with the allowBackup flag set to false are not backed up nor restored, with the README suggesting adb push and adb shell as a manual route. And errors during restore are only printed to logcat, so you look for BackupManagerService entries there rather than expecting a clear message from the tool.

Installing abe and unpacking your first .ab file

The README requires Java 11 and notes that handling encrypted backups needs the JCE unlimited strength jurisdiction policy, which it says is not needed on current Java 9 releases. Pre-built runnable jar files are published under Releases, and the README says those are built with Travis CI from the master branch and come with the caveat that you use them at your own risk, with no warranty or support.

Building from source is a one-liner with Maven, which the README says needs at least JDK 11 and produces a self-executable all-in-one jar:

mvn clean package

After that, the invocation form given in the README is java -jar target/abe.jar with a subcommand. To turn a backup into a tar you run unpack with the .ab as input and the tar as output:

java -jar target/abe.jar unpack backup.ab backup.tar

If the backup was encrypted, the password goes on as a third argument, or you can set the ABE_PASSWD environment variable instead. With no password, the README says the archive is not encrypted but only compressed. A dash as the filename means read from standard input or write to standard output, which is what makes piping possible.

Gradle and Ant builds are also documented. The Gradle path produces build/libs/abe-all.jar, and the Ant script needs the Bouncy Castle jar placed in lib/ with the bcprov.jar property adjusted accordingly.

Repacking safely: copy the file list, do not invent it

This is the part where a casual attempt goes wrong. The README's own advice is to take the file list from the original archive rather than construct a tar from scratch. It gives this command to pull one package's entries out of the extracted tar:

tar tf backup.tar | grep -F "com.package.name" > package.list

Then, from inside the extracted backup directory, you rebuild the tar using that list so the ordering is preserved:

tar cf restore.tar -T package.list

Only then do you pack and attempt a restore with adb restore restore.ab. The README does not document rollback. If the restore misbehaves, the guidance is to watch logcat for BackupManagerService, and for allowBackup=false apps to fall back to adb push and adb shell. There is no dry-run mode described, no verification step built into the tool, and no undo. Treat the first restore after a repack as a test, not as a routine operation.

Where abe is the wrong tool

If you want a graphical interface, abe is not it. The README documents a command-line utility only, and the repository is a Java project with build files for Maven, Gradle and Ant; nothing in the repository documentation describes a window, a file picker or a progress bar.

If you want something that runs on the phone, abe is also the wrong shape. It is a host-side tool that consumes a file you already produced with adb backup. It does not create the backup, it does not connect to a device, and it does not restore anything itself; adb restore does that.

Finally, if your backup is intact and you just want the data back on a working phone, going through abe adds a conversion step with a known failure mode in tar ordering. The README's own fallback for stubborn cases, adb push and adb shell, sidesteps the repack entirely. abe earns its place when you need to inspect contents, extract specific packages, or rebuild a modified archive, not when a plain restore would do.

How abe differs from a general archive tool

A tool like tar or 7-Zip handles archives whose format is standardized and whose readers are forgiving about entry order. abe sits on the other side of that line. The .ab container is specific to Android backups, and the tar inside it is consumed by BackupManagerService, which the README describes as strict about ordering to the point that a mismatched archive can cause errors or system crashes.

That difference drives the workflow. With a general archiver you extract, edit, and re-archive without thinking about sequence. With abe the documented safe path is to derive the entry list from the original archive and rebuild the tar from that list, because the tool will faithfully pack whatever order you hand it. abe is not protecting you from a bad tar; it is giving you the container conversion and leaving the ordering discipline to you.

Licence, maintenance and what to check before relying on it

The repository carries a LICENSE file, but the licence is reported as NOASSERTION, meaning GitHub could not map it to a known identifier. Read the LICENSE file itself before you redistribute the jar or embed it in something you ship. The README adds its own disclaimer for the published binaries: use them at your own risk, no warranty or support provided. That is a statement about support expectations, not a legal opinion, and it is worth taking literally.

The last push to the repository was on 2026-09-18, and the most recent release is dated 2026-07-21. The repository is not archived. The README also makes a scope limit explicit: report only bugs in the backup extractor itself, because the author cannot answer questions about unpacking or repacking backups or tar files. So the maintenance surface is the tool, not your archive.

Upgrade cost is low by construction. The build requires Java 11, and the README notes the JCE unlimited strength policy concern applies to older Java releases rather than current ones. If you build from source you pull the Bouncy Castle provider jar yourself for the Eclipse and Ant paths. Before depending on it in a pipeline, check that your JDK version matches the Java 11 requirement and that you have a way to reproduce the original tar ordering, since that is the step the tool does not automate.

Editorial conclusion

Use abe if you have an .ab file produced by adb backup and need to look inside it or rebuild it, and you are comfortable at a shell with a JDK 11 or newer installed. Do not reach for it if you want a GUI, a phone-side app, or a general Android file manager; the README offers no GUI and points at adb push and adb shell for manual restores. Before trusting a repack, verify the file order in your tar against the original backup.tar listing and confirm the run finishes without BackupManagerService errors in logcat, because a wrong tar order is the failure the README warns about most directly.

Frequently asked questions

Official sources

1. Issues
2. nelenkov/android-backup-extractor on GitHub
3. README
4. Releases