Bash and ADB: Adebar helps you backup, document, and restore your device
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
runadb 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
runadb 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 frombuild.prop
andpm 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