Hints
Adebar only creates the scripts, it doesn't backup stuff itself. There are two exceptions to this rule currently:
- it pulls the
packages.xml - it pulls the
wpa_supplicant.confand some other config files directly.
Both actions are relative fast. But once you run the scripts to create the real backups, things are different: especially pulling the "Shared Storage" (see below) might take quite a while, as your SD cards might hold gigabytes of data. At the same time, it puts quite a strain on your battery, as it needs to transfer all those data. So make sure to have a power source connected to your device during the backup process (you probably will have that, as ADB is mostly used via USB – but you could also use „ADB wireless“, and the TiBu stuff is using WiFi as well – so I'd thought to better point this out).
- as pointed out above: have a power source connected
- with the „ADB Backups“: always wait for the „complete“ toast before confirming the next backup (or ADB might choke, backup won't continue)
- if ADB „chokes“ (and the backup stalls): Check your backup directory for how far the process already went, adjust the script accordingly to start there, disconnect and reconnect your device, and re-start the modified script.
This term refers to your SD card(s). Adebar offers two ways to retrieve data from those:
-
com.android.sharedstoragebackup.ab(for abbreviation issues, I'll refer to this as SSB from now on) - Titanium Backup (abbreviated as TiBu here)
Scripts generated by Adebar cover both, so it's up to you which to use.
As you might have already guessed from the above, Shared Storage Backup (here
abbreviated as „SSB“) is offered via ADB without the need of additional apps. It
is simply triggered when backing up data from its package. These data include
everything from your device's SD cards – both internal (/0) and external
(/1). Timestamps of files and directories are kept, but most files seem to
come as 0775 (i.e. the execute flag is set for user and group) – a condition
you might have seen when accessing FAT formatted drives in general.
While I'd prefer this backup to the one TiBu creates, specifically for
the timestamps, on some devices it has a little draw-back: The LG Optimus 4X HD
e.g. mounts the external SD card inside the internal one (/sdcard/external_sd),
which results in its contents backed up twice: once as part of the internal SD
(in the /0 subdirectory), and another time as external SD in the /1
subdirectory. This not only makes the resulting backup file unnecessary huge,
but also takes much longer to backup. If you have the same issue, consider
removing the external SD card before pulling the SSB.
TiBu (Titanium Backup) offers an internal web server, which you can start manually via its options menu. If running, you can pull 3 kinds of backups via HTTP:
- contents of the internal SD card (
http://<DEVICE_IP>:8080/storage/INTERNAL/Storage-ALL.zip) - contents of the external SD card (
http://<DEVICE_IP>:8080/storage/SAMSUNG_EXT_SD_CARD/Storage-ALL.zip) - all your TiBu created backups (
http://<DEVICE_IP>:8080/TitaniumBackup-ALL.zip).
In case of the above mentioned LG Optimus 4X HD I just had to pull the contents of the internal card, and had them all: As noted, the external card is mounted inside – and of course the backups reside on one of the two.
Disadvantage here is that TiBu touches the timestamps of all files, so the original timestamps are lost: All files appear as if they would have been created at the time the backup was made.
Version 1.1.0 of Adebar added the functionality to create a script for
backing up your partitions block-wise, i.e. create partition images. Consider
this rather experimental: This script is a side-product of the partition info
in the device documentation. Such images can get rather big, and running the
script as-is might result in unnecessary „duplicates“ (to give you an example:
It might backup /dev/block/mmcblk1, which basically is the entire „drive“,
and additionally all its partitions separately: /dev/block/mmcblk1p*).
This is because there's no unified way of retrieving partition details. Other
than with „normal Linux systems“, Android installations don't come with
/etc/fstab by default (though you might find such with your custom ROM or
Busybox installation). So Adebar collects all details, and lets you decide.
Which also is the reason this generated script is not made executable (so you don't run it accidentally before having it investigated and adjusted to your needs).
The generated images could, similar to a Nandroid backup, be used to restore
the device. But be very careful with this approach: Never ever try writing a
partition which is in use (e.g. do not replace /system while your device is
running in „normal operation mode“). Make sure you know what you are doing
before you start doing it, or you might end up with a broken device.
Which is why I won't give instructions on how to restore those images. If you're knowing what you're doing, you also know how to do it. I take no responsibility for any results (but if they're positive, I'm open to donations).
Many devices support auto-confirmed backups – i.e. you don't have to approve each single app at backup/restore. But some devices seem to need specific keycode sequences. Some used by me or reported by other users are listed here. If your device is not named, try the codes until you find one that works. If none worked, but you figured out a new sequence, please report back!
| Device | MK_AUTOCONFIRM_SEQUENCE | .._SEQUENCE_2 | Comment |
|---|---|---|---|
| Default | (22 23) |
works on many devices | |
| LG H815 (LOS 14.1) | (61 61 66) |
||
| Xiaomi Mi8 | (61 61 61 66) |
(61 61 66) |
|
| KeePassDX | (22 4 20 22 23) |
AutoFill-Feature of KeePassDX |
Depending on the vendor and ROM of your device, it ships with several (hundreds) apps pre-installed: there's the stock Android system, and the Cyanogen „stock“ (CyanogenOS / CyanogenMod). Vendors like LG or Motorola add some of their specific apps – and vendors like Samsung tend to bloat your device with tons of their own apps as well as that of others (on a Galaxy S7 Edge, I've counted almost 5 times the amount of pre-installed apps found on e.g. the LG P880: far more than 200).
In order to not just see their package names in your system apps listings (many of those apps are not found on Google Play, so you'd have to do some research or make pretty good guesses), you can pre-fill Adebar's app-name-cache: Find the necessary „cache files“ in the Adebar-Appcache project (clone it or download it as ZIP file). Be welcome to contribute to it – the selection of devices I have is limited :)
 |
For information about Android, App lists, and more, visit IzzyOnDroid – where you also can find other ADB tools and apps. | |