What the files are about and what to do with them
Files that ship with Adebar
adebar-cli: the main command-line script. Run this to generate your backup and restore scripts.
doc/config.sample: an example config file. If you do not need support for pulling stuff via the Titanium Backup built-in web server, and satisfied with how things work by default, you can ignore this file. Otherwise, copy or rename it to
config(in the main dir) or
config/<name>(with a name of your choice), and adjust it to your needs.
doc/quickstart_config.sample: an example config file for an easy and quick start, covering only the most essential things (like assembling the final HTML file of the generated documentation and giving your device a name).
doc/AdebarFiles.gv: Graphviz source of the image below (to visualize generated files)
LICENSE: Adebar license details (GPLv2)
README.md: general information on Adebar
tools/abrestore: shell script to work around
adb restoreissues with some Android 7+ devices
tools/ab2tar: tiny shell script to convert ADB Backups to
.tar.gz. Requires openssl and zlib.
tools/getapk: shell script to extract specific|all|user|system apps
tools/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)
tools/ssnap: to create a series of screenshots from your device
tools/getPkgData.php: a PHP script to parse and analyze the
packages.xmlfile. This was originally called from
adebar-clito create e.g. the
userApps.md. After rewriting that functionality to get rid of the PHP dependency, I've decided to keep those files in the distribution as they might be useful for other tasks.
tools/xml2array.php: helper to
getPkgData.php(converts XML to an PHP array)
Files generated by Adebar
deadReceivers.sh: script which (hopefully) disables those components again, e.g. after a factory-reset
defaultInstallLoc: 1-liner to set the default-install-location for apps
disable: shell script utilizing ADB to disable packages you have disabled at the time of generating your report and scripts. This will also hold the commands to uninstall any bloatware you had uninstalled at that time via
adb shell pm uninstall --user 0 <packageName>(Adebar > v2.0.0).
partBackup: script to backup all the partitions of your device
sysbackup: script to backup all data of your system apps, including shared storage (data from the SD cards)
sysrestore: script to restore the entire system data backed up with
tibu: script to pull data via the web server built in to Titanium Backup
userbackup: script to backup all your user apps and their data
userrestore: script to restore the very same
deviceInfo.md: information on the device, e.g. device-features and properties
userApps.md: List of installed apps, grouped by their source, with some details on them (e.g. date of first install / last update, installed version)
sysApps.md: Same for system apps
defaultApps.md: Default apps (WebViews, Standard apps)
disApps.md: uninstalled/disabled apps
- configuration files pulled from your device(s) if possible (placed into the
wpa_supplicant.conf: contains all your WiFi APs, their passwords, etc.
softap.conf: contains your WiFi hotspot SSID and password hash
xprivacy.xml.gz: export of XPrivacy settings
xprivacy_dbs.tar.gz: pull of XPrivacy databases
Note that not all of those files are generated in all cases. Some depend on conditions:
packages.xmlof course can only be there if Adebar was able to pull it. Starting with Android 4.1, this requires the ADB daemon to run in root mode.
tibuis only generated when the variable
DEVICE_IPwas set to an IP/hostname in the config (by default, it's not/empty), and
MK_TIBUwas set to
wpa_supplicant.confcan only be pulled if the ADB daemon on the device is running in root-mode
- some other config files might be „protected“ from being pulled in the same way
What to do with the generated files?
Some of them are just intended for reference (the files in the
conf/ directories). The shell scripts (usually made executable by Adebar)
are for you to run, after an optional modification:
sysbackup: you can comment out apps you don't want to backup, then run the scripts to do the job. While being run,
sysbackupwill ask you whether to pull „shared storage“ (i.e. contents from your device's SD cards), as that is a quite „resource consuming“ job which probably takes quite long (depending on how much data there is on the cards), so you can easily skip this even with an unmodified script.
sysrestore: that's the „counter-part“, and holds the restore commands for everything that was originally part of the corresponding backup script. Again, you will be prompted whether to restore „shared storage“.
tibu: after having started the Titanium Backup built-in web server, this script can be used to pull what that offers. Basically, „shared storage“ again (but external and internal cards separately), plus a ZIP containing all your TiBu backups.
disable: useful if you had to factory-reset your device, and previously had some apps „frozen“ (disabled). Run this script to automatically disable all apps you had disabled when Adebar created this script.
deadReceivers.sh: similar to the previous point, but for „disabled components“ (i.e. auto-starts and the likes). Note that this also contains components the apps might have disabled themselves based on their configurations (e.g. Business Calendar does this so you can disable widgets you do not intend to use, other apps might have done this if you e.g. disabled their „start on boot“ or other functions). While it should do no harm, I can give no guarantees: You better check and make sure the script only holds what you need.
doc/*: the files here are for reference, so you can read them :)
conf/*: again, for reference and study.
What format are the generated files in the
doc/ sub-directory using?
Originally, they were using Markdown, a plain text formatting syntax to produce well-formatted documents, while still being easy enough to read without being converted first. With Adebar version 2.0.0, they are „HTML fragments“, as HTML allows for more flexible formatting.
Both configuration examples in the
doc/ sub-directory come with a „user function“
uf_postrun which, with the help of files in the
assemble those HTML fragments to a complete HTML page at the end of each run, so
you can simply open them with the web browser of your choice. Some example
documentations can be found here.