Bash and ADB: Adebar helps you backup, document, and restore your device

Android green figure; © Dsimic (CC-BY)
Source: Wikipedia

Now it had happened: I needed to send one of my devices to the service center. Of course, this means factory-resetting it before packaging – which implies having a good backup. While I’m using different variants of backups already (e.g. a regular, automated backup with Titanium Backup), does that really cover all? And will restoring be a breeze? Maybe I could use that chance for some cleanup as well? Oh, and how do I remember which „Crap & Bloatware“ I had frozen, which „auto-starts“ disabled? How much manual work would that leave to me when the device returns?

Those were the thoughts I had when deciding to write Adebar. So let’s see what were the results.

What is Adebar?

So in a few words: What is Adebar, and what does it do? Basically, it uses Bash scripting and utilizes ADB to retrieve data from your device, and then creates multiple files:

scripts you can run to backup/restore your apps+data as well as system-app data from/to your device
scripts to „re-freeze“ your „frozen“ apps after a factory-reset plus full restore
a copy of several configuration files you might have altered (mainly for root users)
some device documentation

A sample „output directory“ of generated files could look like this:

├── conf
│   ├── gps.conf
│   ├── hosts
│   └── wpa_supplicant.conf
├── docs
│   ├── build.prop
│   ├── deadreceivers
│   ├── deadReceivers.md
│   ├── deviceInfo.md
│   ├── packages.xml
│   └── userApps.md
├── deadReceivers.sh
├── defaultInstallLoc
├── disable
├── sysbackup
├── sysrestore
├── userbackup
└── userrestore

As you can see, a run of Adebar produces three sets of files:

some backed-up config files in the conf/ sub-directory
some device documentation in the docs/ sub-directory
several scripts in the „main directory“

Most of the latter are, for your convenience, already made „executable“.

One thing to point out at this place: not all of the files are created in all circumstances. Retrieving some of them requires the ADB daemon to run in root-mode (which is the case on many custom ROMs, and can be achieved on others using chainfire’s adbd Insecure – but in both cases, requires a rooted device), others additionally require the PHP CLI packages to be available (parsing of the packages.xml is done that way).

What do the generated scripts achieve?

First off: you might wish to check their contents, and comment out things you dont want. This could e.g. be apps you’ve installed long ago and don’t need anymore, so no reason to back them up.

deadReceivers.sh would disable some „app starters”. This is the only script not made executable, and having a „file extention“ as you might have noticed. Reason is: this might be dangerous to use. Better leave it alone if you’re not sure what that is.
defaultInstallLoc: once upon in your device’s history, you might have changed the „default install location“ (that is, where your apps shall be installed to by default). Just run this script to restore it to that value – or simply ignore it if it’s setting that to „0” (which is the default with a fresh system usually).
running disable will freeze all apps which have been frozen at the time this script was created. Very useful to automatically get rid of all that „bloatware” without walking the list of apps manually
sysbackup / sysrestore run adb backup resp. adb restore for your system apps‘ data, for each app separately, which allows for a selective backup/restore. Moreover, this also includes backing up / restoring „shared storage” (i.e. SD card contents), which they will prompt for: this step might take quite long and result in a huge file, depending on how much storage you’re having in use here.
userbackup / userrestore run adb backup resp. adb restore for your user apps (including their data), for each app separately. This allows for a selective backup and restore.

What are those files in `docs/` for?

Well, some „device documentation” can be expected here. This includes some files simply pulled from your device (build.prop, packages.xml), but also some Markdown files derived from those:

deviceInfo.md gives some general information on your device, basically parsed from build.prop and pm list features. This usually includes a.o. Manufacturer and device name, Android version, language/DNS settings, and some more. Content might vary between devices, as it depends on what the two mentioned sources reveal.
userApps.md lists the apps you have installed on the device, grouped by their sources (i.e. where youve installed them from).
deadReceivers.md is the pendant to afore-mentioned script, putting the „disabled components“ into (hopefully) user-readable format.

Where can I get more information?

Adebar is open-source, hosted at Github – so naturally you can go there: whether you want the sources, have issues, miss a feature, or want to participate (hint: testers and feedback welcome as well as someone to write a GUI ). The dev (me) is also available via IRC at Freenode in the #izzysoft channel.

Conclusion

While definitely not being a „one-click solution”, Adebar can give you a „better peace of mind“ about your backups and what they cover. As a side-effect, it provides you with a „minimal device documentation“. It might come in especially handy when you’ve got to factory-reset your device, or plan on „duplicating“ its configuration to another one. It’s not thoroughly tested yet, so feedback (be it problems or success notices) are highly welcome: I can’t declare it „production-ready“ without knowing it is

review

2014-11-02

IzzyOnDroid