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
.apkfiles 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.conffrom your device, which holds information on all WiFi APs you've configured (root required) – and also some more configuration files.
- it pulls the
packages.xmlfrom 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.
Note: as the question came up: no, Adebar does not rely on
packages.xml to generate the device documentation – it works quite fine without root powers.
Optionally, if you have the PHP CLI available on your computer, you can parse the
packages.xml (provided you were able to pull it: root required for that) 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
zlib-flateand 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
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)
root_apprestore.sh: if you have root powers, these might help you backing up / restoring any app and its data. Use with care!
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 restorecommands 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.
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
errm… I mean, Credits and thanks:
- Adebar Logo design by Mathis Brüchert and Acrylic by Mondstern
- Code submitted by many contributors
- suggestions, problems pointed out, ideas given by even more great people via issues, by mail, at Mastodon…