Some apps simply don't want to be backed up via ADB (41 byte files)
In my tests I've encountered several apps which seem to simply refuse being
backed up via ADB. In those cases, backups result in a 41 byte file (which is
just the backup file header). So watch out for those, and see to have them
backed up by other means; as Adebar here is no more than a "front-end" to the
adb backup command, I don't see what it could fix here. As the example of
DavDroid shows, this is rather to be
fixed on the corresponding Android app's end.
You should be able to identify any affected app in your created
its „flags“: it will have no
ALLOW_BACKUP and no
ALLOWBACKUP flag reported.
Apps which I found having this issue include the following:
- installed as system apps:
- installed as user apps:
- AppMonster Pro
- DavDroid (pre-0.6.4; fixed on DavDroid's end)
Starting with Adebar 1.9.0, backing up apps which explicitly disallow being
backed up is no longer even attempted; instead, the backup script will hold a
comment on each such app pointing out we can't back it up via
adb backup. I
decided for this step as even the
Backup All Apps stopped
working (seems no longer effective with Android 6+). If you know about other
means, please open an issue telling me and I'll look into it.
ADB Backup not working for any app (0/41 byte files)
Again no issue of Adebar – but an incompatibility on the ADB backend: the version running on the device doesn't want to play with the version running on your PC.
If you're in the trouble having multiple devices and each requires its own ADB
version (rare case), a work-around (so each one gets its correct
is to add a line to the corresponding config file:
to point to the corresponding binary for each device.
Backup of each app has to be confirmed separately
Yes. That's a security measure so no stranger could simply connect an USB cable
to your device and steal your data. But there's a way to work around this
restriction using „key events“. If you want to go this way, add
AUTO_CONFIRM=1 to your configuration file. Note you will still have to
unlock your device; the „key events“ won't register while the lock screen is
Backup passwords containing spaces causing issues
Yes they will. For details, please see this pull request. As working around that issue is tricky at best, it's rather recommended to not use spaces in passwords at all.
packages.xml (and/or other files) not retrievable
On some devices (all 4.1+ devices with the ADB daemon running in non-root mode?),
packages.xml can not be pulled. Hence Adebar obtains related information via
dumpsys instead – which is a bit slower, but worked on all devices tested so far.
This applies to some other files as well, especially those with sensitive details
wpa_supplicant.conf). If you want to pull them, you'll have to root your
device (a must) and make sure either the ADB daemon runs in root-mode (which can
e.g. be achieved using chainfire's adbd Insecure)
or you've set
ROOT_COMPAT=1 in your config.
disable script not working?
It seems many (all?)
adb pm disable commands are not performed when
running in non-root mode, at least when run against pre-installed apps (aka
„bloatware“; confirmations/dementis welcome, as the list of devices at my
disposal is pretty limited, so I can not say whether that's a general rule).
Nothing we can do about that.
Apps are always listed by their package names
doc/userApps.md, which is a documentation file, apps are only listed
with their package names (e.g.
eu.chainfire.adbd for chainfire's adbd Insecure).
I wish there were means to list the „human readable app name“ along – but apart
from pulling the entire
.apk file and dissecting it via
aapt, or trying to
look up the package in the app stores' web pages, I know of no simple way to get
hold on it (if your device has
aapt installed, as some CyanogenMod based ROMs
with Android 4.4+ seem to have it, that's used by Adebar automatically; if not,
you can install it manually from here if your device is rooted).
To work around that, you can manually create the corresponding cache files, as
described in Configuration. For apps available at Google Play, you can
also try the example
uf_getAppname() user function defined in the example
config file, enabling it by setting
APPNAME_CMD="uf_getAppname" in your config.
This will, whenever an app name was not found in the cache, retrieve it from the
HTML TITLE attribute of the app's Playstore web page.
Alternative suggestions welcome.
Difficulties dealing with multiple devices having the same serial
This mostly goes with custom ROMs or with „cheap devices“, and is nothing to
blame upon Adebar: I've encountered multiple devices/ROMs from different
vendors using the serial
0123456789ABCDEF, which is obviously some „dummy“.
Not a big deal if you call the Adebar script with the right config for the
connected device – but it might become tricky if you want to make use of the
--auto feature, where Adebar checks for connected devices using the
adb devices command, and tries to figure the correct config file by the serials
Nothing we can do about that on the end of Adebar – but if your device is
rooted, you may be able to fix its serial yourself: The serial is usually taken
/sys/class/android_usb/android0/iSerial. If you can manage to have a
unique value written there automatically at boot, that would fix it.
echo -n MyUniqueSerial > /sys/class/android_usb/android0/iSerial
would do the job – you just need to find out how to set that automatically. Examples of possibilities are:
- integrating it into
/system/etc/install-recovery.shif that file exists (works on some devices – but not on all, even if the file exists)
- integrate it into an init script if your device and kernel support it
(those devices usually have a
/system/etc/init.ddirectory); also see: How can I run a script on boot? and How to run a script on boot (the latter is about how to add
init.dsupport to your device if it's not there)
- according to this SO post it might
work to simply issue a
setprop persist.usb.serialno MyUniqueSerialas root, and then reboot the device.
- run a script at boot time by other means, e.g. utilizing Script Manager or Tasker
All my partitions are listed with a size of 0 MiB
This is the case for non-rooted devices which do not allow to access certain partitioning details without root, as e.g. the Sony Xperia XZ1 Compact running Android 9. Fear not, nothing broken with your device – it's just that Adebar cannot find out the size. As the remaining information can still be considered useful (so you can see what a partition is used for), it's shown that way.
App details have no/incomplete storage information
Details on apps' storage use have been added to
dumpsys diskstats somewhere
after Android 6 – so you won't see those details for devices running Android 6
or lower. Android 7 seems to have added them for APK and cache sizes only, so
(unknown) for app data sizes of those devices (same seems to be the
case for Android Go up to 8.1 at least). Full details hence are not available
before Android 8 (Oreo) – again not the fault of Adebar.