Android DEvice Backup And Report, using Bash and ADB.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Izzy 137aaad4ae
use cache for user apps as well as e.g. Samsung now installs many apps this way (S20 FE)
1 week ago
.github/ISSUE_TEMPLATE Add issue templates 3 years ago
doc DeviceInfo: add DeviceAdmins (off by default to avoid shocking Samsung users) 1 year ago
lib use cache for user apps as well as e.g. Samsung now installs many apps this way (S20 FE) 1 week ago
templates/default fix generated HTML to be proper HTML5 7 months ago
tools safer way(s) to obtain PKGUID; abort if not found as it’s needed for ownership 8 months ago
.gitignore hiding all test* stuff from git 1 year ago
LICENSE Initial commit 7 years ago Changed parts for restoreapks and getapk tools 11 months ago
adebar-cli rewrite partition info gathering to work with dummy devices 1 year ago


Adebar stands for Android Device Backup and Report. It is mainly based on Bash and Adb. It reportedly works on Linux, Mac and Windows (Cygwin).

Note: As this is a collection of Shell scripts, you won't find any „binaries“ attached to releases – there are none for Adebar and no „compilation“ is required. Please take a look at the wiki for further details and instructions.

What makes Adebar specific?

There are plenty of backup solutions available for Android, including such intended as front-end for ADB. So what is specific for Adebar that I wrote it, knowing of those other solutions?

The task I wrote Adebar for is to be able to quickly backup a device, and restore the backup again – e.g. when I need to factory-reset a device. That includes the case where I have to send a device to be serviced, and need to use a different device meanwhile – which would rule out a "complete restore" due to the side-effects system-apps might cause, especially when the second device is from a completely different manufacturer, and/or runs a different version of Android or even a completely different ROM. That's one of the reasons why the scripts generated by Adebar create one backup file per app (instead of one huge backup.ab holding them all) – while the other is to be able to select what to restore in general.

As a side-effect, Adebar generates a „report“ (or „short documentation“) on the device – including general device information (like model, Android version, device features, device status, configured accounts) as well as some details on installed apps (install source/date, last update, version, etc.).

What kind of backup does Adebar create?

Adebar itself does not create any backups. But it generates multiple files, including

  • a shell script to create separate ADB backups for the apps you've installed yourself ("user-apps"), including their .apk files and their data
  • a shell script to create ADB backups of system apps, only containing their data, plus shared storage
  • a shell script to create disk images of your device's partitions (for rooted devices)
  • a shell script to download contents of your internal/external SDCards and Backups via Titanium Backup's built-in web server (for rooted devices)
  • a shell script to disable (freeze) all apps you had disabled/frozen on your device
  • it pulls the wpa_supplicant.conf from your device, which holds information on all WiFi APs you've configured (root required) – and also some more configuration files.
  • it pulls the packages.xml from your device, which holds all information about apps installed on your device (with Android 4.1 and above, this again requires root)
  • a shell script to disable all broadcast receivers (aka "auto-starts") which were disabled on the given device
  • a HTML file listing all user-installed apps with their sources you've installed them from (e.g. Google Play, F-Droid, Aptoide), date of first install/last update, installed version, and more – plus the same for the (pre-installed) system apps.
  • a HTML file with some general device documentation.

Those three HTML files still have a .md file extension for historical reasons (before v2.0.0, they were created using Markdown). They are not complete HTML documents (no header, no footer); the example configuration in doc/ has a user-function uf_postrun() taking care to assemble the pieces into one file which then will be a valid HTML document and thus have an .html file extension. Some examples of such "assembled device documentation pages" can be found here.

Adebar-created files

Optionally, if you have the PHP CLI available on your computer, you can parse the packages.xml with provided PHP scripts, located in the tools/ directory. This directory also includes a few additional scripts:

  • ab2tar: shell script to convert ADB backup files into .tar.gz archives (requires openssl or zlib-flate and currently can only handle backups which were not password-protected)
  • abrestore: to help you if you have issues restoring ADB backups on Android 7 or higher (if your device is affected by the ADB restore bug, only restoring backups of apps already installed on the device)
  • getapk: grab the APK(s) for a given (group of) app(s) via ADB
  • restoreapks: restore all the APK's you have in a folder via ADB (as retrieved by getapk)
  • mkdummy: to create a "dummy device" from your real one (mainly intended for debug purposes: if you need assistance, you could zip/tar that after having it sanitized and attach it to an issue, or send it by other means)
  • ssnap: to create a series of screenshots from your device

As I cannot test Adebar on all existing devices/ROMs, there might be some errors/bugs here and there (specific to a given device, ROM or newer Android version); if you encounter one, please file an issue at the project's Codeberg presence. General feedback is also more than welcome if you're successfully using Adebar with your device, see List of tested devices.


Most of them should already be obvious from above description. Nevertheless, all of them here in short:

  • ADB installed (and configured for your device) on your computer. This can either be the complete Android SDK, or a minimal installation of ADB.
  • Bash (version 4 or higher). As this is a very common shell environment, it's available by default on most Linux distributions. If you're a Windows user: sorry, the only windows I have are for light and fresh air – but I've received reports that Adebar ran successfully with Cygwin.
  • Android 4.0+: As the adb backup and adb restore commands have not been present before Android 4.0, Adebar will not be of much use with devices running older versions – except for creating a „device documentation“ as outlined above, which indeed works even with Android 2.1.
  • some features require root on the Android device


To get started without too much hazzle, please see doc/quickstart_config.sample. Basically, you just copy that file to config/ (giving it a name of your choice), adjust 4 to 6 settings to reflect your device plus directory structure (as indicated by comments in the file), and you're ready-to-go (i.e. starting adebar-cli with the name of your config as only parameter, e.g. ./adebar-cli myandy).

More details

A documentation describing steps for installation, configuration, usage, and more can be found in the project wiki. Examples of device documentation created by Adebar are available here.


You like Adebar and want to contribute?

  • Pull Requests are welcome!
  • Report back your device that works with Adebar so it can be added to the wiki!
  • Motivate me e.g. by sending me some mBTC to 1FsfvUGUpoPkLvJboKAnuBXHZ1zN3hbBL1 :)


errm… I mean, Credits and thanks:

(Adebar Logo in Mondstern's Gallery of Codeberg projects)