adebar-cli requires at least one parameter, which will be used to
- detect a matching (device-specific) configuration file (see Configuration)
- define the desired output-directory (residing below the configured
You can pass it an optional second parameter, which will then be appended to the output directory name. This might be especially useful if you want to keep scripts from a specific run, and not have them overwriting your „default set“.
(Note that for always keeping „historical sets“, there's an easier way: see the
TIMESTAMPED_SUBDIRS parameter in the Configuration.)
As this might be easier to understand with an example: Let's say you've got two devices, one Motorola and one HTC. For each of them, you wish different settings to be applied. So for a „shortcut“, you name the first „moto“ and the second „htc“. For easier handling, you could do the following:
- create the
configdirectory below the directory
- adjust the two files to your needs
./adebar-cli mototo create the scripts in
./adebar-cli htc _20141101to create them in
adebar-cli without specifying a parameter will cause it to tell you
its syntax – and list available configuration files you have created in the
There are two exceptions to the above mentioned syntax:
--helpas first parameter will show the syntax
--autowill try to automatically match connected device(s) with corresponding config files. For this to work, each device must have its own config file in place with the corresponding serial configured (no trailing comments on that line). Beware if you have multiple devices using the same serial (often
0123456789ABCDEF): it's always the first matching config that will be used!
- 1: Syntax error (missing or wrong arguments when calling the script)
- 2: No device found
- 3: Multiple devices found, but no SERIAL specified in config
- 4: SERIAL specified, but no matching device connected
- 5: target directory doesn't exist, and neither can be created
- 6: Bash is not present or its version is lower than 4 (Adebar requires Bash 4+)
How to use the generated scripts
For an overview of which scripts are generated, please see the Files page.
There are multiple backup scripts generated:
userbackup: these scripts facilitate the
adb backupcommand. As simply creating one full backup containing all your data would result in the fact you could only do a full restore with ADB (so it's an „all or nothing“, unless you use third-party-tools), Adebar splits this up into multiple pieces: a separate backup archive for each app, so you can do a selective restore.
Check the script, comment out what you don't want to be backed up („shared storage“, i.e. your SD cards, is already wrapped asking you at runtime whether you want to run that or not). Once you're done, make sure your device is connected (and the screen unlocked), then start the script. Approve each backup call on the device (unless you're using
AUTO_CONFIRM=1; from the second call onwards, only do so after the previous call is finished, or ADB might choke). When the script is finished, you will find your
.abbackup files in the corresponding directories.
partBackup: this scipt creates images of all your device's partitions. As with the ADB backups, check the script and see if you need them all; I've tried my best to give the images „speaking names“ – but the reality will only be as good as your device's system permits.
As with the backup, we again have multiple scripts here:
userrestore: counterpart to the corresponding backup scripts. Deal with them the same way: comment out what you don't want to restore, then run the script.
disable: disable the apps which have been disabled (frozen) at the time the backup was created
deadReceivers.sh: similar, but for app components. Use this with care.
conf/*: I'm not sure whether those files should be restored directly. You certainly can do so with the
wpa_supplicant.conffile (to have all your configured WiFi APs back), same with the
gps.conffiles. But you for sure should not do so with the
build.prop, which are more intended for reference.
You might have noticed there's no counterpart for the partition backup. That's intentional. If you don't know what to do with those, better read on it first. Which image belongs to which partition you can check in the corresponding backup script.
The files in the
doc/ directory are your device's documentation, using HTML
format (before Adebar 2.0.0, they were using Markdown). Please see the linked
Wikipedia page for details. You can simply use your web browser to view them.
Ideally, you had the
uf_postrun() function enabled that assembled a complete
HTML file for you in a location of your choice, to make viewing more convenient.