13 Files
Izzy edited this page 2 years ago

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 restore issues 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.xml file. This was originally called from adebar-cli to 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

Adebar-created files

  • scripts
    • 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 sysbackup
    • 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
  • documentation
    • 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)
    • uninstApps.md, disApps.md: uninstalled/disabled apps
  • configuration files pulled from your device(s) if possible (placed into the conf/ sub-directory)
    • build.prop
    • gps.conf
    • hosts
    • packages.xml
    • 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.xml of 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.
  • tibu is only generated when the variable DEVICE_IP was set to an IP/hostname in the config (by default, it's not/empty), and MK_TIBU was set to 1 (default is 0).
  • wpa_supplicant.conf can 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 as wpa_supplicant.conf

What to do with the generated files?

Some of them are just intended for reference (the files in the doc/ and conf/ directories). The shell scripts (usually made executable by Adebar) are for you to run, after an optional modification:

  • userbackup/sysbackup: you can comment out apps you don't want to backup, then run the scripts to do the job. While being run, sysbackup will 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.
  • userrestore/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“ named uf_postrun which, with the help of files in the template/ directory, 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.