The problem:

Every time I run ADB backup, I get a message near the bottom of the home screen saying Backup starting..., followed by a message saying Backup finished a few seconds later despite the fact that I'm using 17 GB of device memory, and the resultant backup file is created with a size of 0 bytes. I receive no error messages, no feedback whatsoever indicating that anything is wrong, let alone what is wrong. It appears to work, but way too quickly, and the backup file is empty.

The process:

  1. I confirm that the device is recognized by ADB using the adb devices command, and receive the following output:

    List of devices attached
    8e1f368a        device
  2. I issue the ADB backup command (details to follow).

  3. I get the following message at the command prompt:

    Now unlock your device and confirm the backup operation.

    ...and the following prompt on the phone:

    enter image description here

    It makes no difference what I do here (details to follow).

  4. I tap the Back up my data button (bottom right corner).

  5. The phone returns to the home screen and shows me the Backup starting... message, then the Backup finished message a few seconds later. A 0-byte file is created, named either the default backup.ab or whatever I specified with the -f switch.

The ADB backup command (used in step 2):

I've tried multiple combinations of options, ranging from as simple as

adb backup -all

to things like

adb backup -all -apk -s 8e1f368a -f 'C:\Data Files\PDA\Backups\ADB\GalaxyS4_20140919.ab'

I also tried adding the -nosystem switch after reading this and this, which indicate that trying to include a system backup on an unrooted device may result in a 0-byte file, and that this switch must be used. It makes no difference, the process still completes in a matter of seconds and I still get a 0-byte file.

The "Full backup" password prompt (step 3):

I'm quite sure I have never set a backup password before. I've never had the occasion to set this password or access this setting in any way before. However, I have tried all of the following:

  • Leaving both passwords blank
  • Leaving the "current backup password" blank and entering a new password in the second box
  • Entering the current screen lock PIN and all PINs I've ever used in the past as the "current backup password".
  • Entering every password I can think of that I would have ever used for anything on this device

In all cases the behavior is exactly the same as described in step 5. I get no errors or any kind of indication that anything is wrong or that my passwords are invalid, and no hint as to whether it's actually expecting a current password or whether that field should be left blank. (The screen shot in this answer and several other support forums I've looked at seems to imply that the "current backup password" box wouldn't be displayed if there's no current password, but that's just an inference; nothing makes it clear whether a current password is actually required.)

I suspect that the password it's prompting for might be the "Desktop backup password" set in Developer options:

enter image description here

I have never set that password before. If I try to set one, I get a message saying Failed to set backup password.

In searching for information about this error, I've encountered at least one other case in which someone who was having this problem said this was preventing him from using ADB backup, but he wasn't specific about what happens when he tries to use ADB backup.

Most people who received this message having never set the password before say that the solution was to leave the current password blank, but I tried that in the first place and it didn't work. I found a question by another person who encountered this problem and was sure he hadn't set the password before. Unfortunately it doesn't look like he ever got a solution or even an explanation.

Regardless of whether ADB is looking for the "Desktop backup password" or the ADB encryption password is something separate, it boggles my mind why ADB would require you to enter a previous password in order to initiate a new backup. I'm not trying to restore, overwrite, or in any way access previously encrypted data, so even if an encryption password for a backup had previously been set, I can't imagine why anyone would think it's a good idea to prevent you from backing up your device if you don't remember what password you used to encrypt backups in the past.

Additional information:

Model: Samsung Galaxy S4 SCH-I545
Kernel version: 3.4.0
OS version: 4.4.2
Android SDK Tools version: 1.16
USB debugging is enabled.

Note that my reason for using ADB backup is to take a full backup of my phone to be on the safe side before rooting it* so I can use nandroid backup tools such as Titanium backup. So, any suggestion involving rooting my phone would be a Catch-22, not a solution. Needless to say, a factory reset is also not a solution, since it would defeat the entire purpose of performing the backup.

The phone is set up to sync with my company's Exchange servers, and there are some policies enforced by the server. I had thought that the device was encrypted when I first set up the sync with company account, but apparently it isn't currently encrypted. In fact, that's what set this chain of events in motion: I'm getting a message telling me that I need to encrypt the device in order to continue to connect to company servers. I want to take a nandroid backup before encrypting, which requires rooting, and I want to use ADB backup before rooting.

* Yes, I'm aware that Towelroot is purported to be safe, but I'd rather not take chances, and I'd like to resolve or at least understand this problem in case related issues come up in the future.

  • I've had several issues with ADB on one of my tablets (rooted or not, in both cases) which were similar (just the other way around: while adb backup worked fine, adb restore always failed). Turned out it was a permission problem (manufacturer had messed up with the ROM), so adb restore was unable to read the backup file once it was transfered to the device. Was a bit tricky to find, and I'm not sure if something similar really is the case here; but it might be worth checking.
    – Izzy
    Commented May 27, 2015 at 10:56
  • 2
    For those who would end up here with same 0bytes problem: I had this problem because I once setup desktop password under Settings and forgot it. Because the device is rooted, I followed this answer(mine) and everything went well.
    – Firelord
    Commented Jul 4, 2015 at 10:18
  • You might also look at: code.google.com/p/android/issues/detail?id=47009 - If you have encrypted your phone, you might need to use your encryption password as the "current password" in all prompts: either in the "Full backup" screen, or in the "Desktop backup password" one. Commented Jul 13, 2015 at 7:33

10 Answers 10


Short Answer

Try using an earlier version of adb. 1.0.32 did not work for me, but 1.0.31 did.

Long Answer

I just encountered this issue on a Nexus 5 running CyanogenMod 11 (based on Android 4.4) using the current version of the Platform Tools and ADB (Android Debug Bridge version 1.0.32 Revision eac51f2bb6a8-android).

Using adb logcat to watch the device logs, I noticed that after invoking adb backup -apk -obb -shared -all -nosystem there were some suspicious log entries:

V/BackupManagerService(  811): Requesting full backup: apks=false obb=false shared=false all=false pkgs=[Ljava.lang.String;@4181ffc8
W/BackupManagerService(  811): Unknown package  '-apk' '-obb' '-shared' '-all' '-nosystem', skipping

Where it appears that the device is interpreting the command-line options as non-option arguments, and producing an error because they are not installed package names. This made me suspect the adb protocol or the command/service invocation options had changed on the device relative to the host, so I tried an older version of adb and voilà, it worked.

I did a bit of digging and came across a change to Use escape_arg in "adb backup", which now causes all arguments to be single-quoted when invoking /system/bin/bu backup. This explains the behavior and the single-quoted arguments in the log message. However, it does not seem to match the time at which you encountered the error. It would also suggest the issue to be much more widespread than it appears to be. So I am hesitant to call this the cause, but it may a good starting point for further investigation.

  • 2
    Using an earlier version (1.0.31) solved my problem. This question stackoverflow.com/q/9555337/1741542 and especially this answer stackoverflow.com/a/23022718/1741542 helped me finding an earlier version, e.g. platform-tools_r20-linux.zip. Commented Nov 10, 2015 at 20:33
  • Seems it doesn't work with all models though. While I made a full backup of a Samsung S3 mini (Android 4.2) without any problem, I couldn't do so with a tablet, which is on Android 4.0. I tried all from adb-r10 up to adb-r23 (excluding adb-r15) with no success. Commented Nov 12, 2015 at 13:59
  • 4
    I had a similar issue with adb 1.0.32 and a Nexus 5 (Android 6). I resolved this via explicitly quoting the backup arguments, i.e. executing adb backup '-noapk -noshared -all -nosystem' instead of adb backup -noapk -noshared -all -nosystem (inside a bash shell). Without the quotes I get logcat messages like this: 'unknown backup flag -all:-nosystem:-noapk', 'no backup packages supplied and neither -shared nor -all given' and finally 'Finished.'. Commented Nov 23, 2015 at 15:22
  • I finally got a full backup with Android 4.0, too. Stupid me, it was just a reboot of the tablet, which got me going. Commented Nov 23, 2015 at 22:15
  • 7
    Thanks! By the way, you can download adb 1.0.31 for all platforms here: ftp.mozilla.org/pub/labs/r2d2b2g
    – eflorico
    Commented Jan 8, 2016 at 1:27

Building on kevenoid's answer, it may depend on what version of adb is running on the phone.

You can find out what version the phone is running natively by doing the following:

First find out what version you are running on your desktop

adb version

Then open the shell on your phone

adb shell

Once the shell is open then you can run

adb version

Then exit the shell by running


I found that my phone was running version 1.0.31 and not 1.0.32 (it is a samsung note 2)

I tried using quotes or escape characters like Hunter showed but none of those worked from the windows command line. However downgrading did fix the incompatibility issue between the two versions.

I was able to find the older version following the instructions here: https://stackoverflow.com/a/23022718/1741542

The download link I used was:

Other platforms:


The other answers about the command arguments being quoted is accurate. I've found that if you escape the spaces between the arguments, it works.

Like this: adb backup -apk\ -shared\ -all\ -system

  • This may not be the solution to OP's problem, but it is a better solution to @Kevinoid's problem than using an older ADB, which didn't work for me. Commented Dec 1, 2015 at 20:41
  • This is a duplicate of Kevinoid's answer without the rationale. However, it worked well for me, and I prefer using \ to ' Commented Dec 7, 2015 at 22:59
  • 1
    This solution worked for me, no need to downgrade adb Commented Dec 18, 2015 at 4:10
  • I can confirm @HunterPerrin 's suspicion that this is a different problem because I tried this first and it didn't solve my problem but the second I went to 1.0.31 adb it started to copy correctly
    – Allison
    Commented Nov 11, 2016 at 21:19

None of the workarounds worked for me here, and I don't want to downgrade my SDK tools. Here's what I came up with: skip adb backup on the computer and go straight to device via adb shell.

$adb version
Android Debug Bridge version 1.0.35
Revision fc2a139a55f5-android

$ adb shell
shell@jflte:/ $ bu 1 backup -apk app.package.name > /sdcard/backup.ab
shell@jflte:/ $ exit

$adb pull /sdcard/backup.ab
[100%] /sdcard/backup.ab

This calls /system/bin/bu and dumps the backup file onto STDOUT (File descriptor #1). Parameters are the same adb backup <params> -> bu 1 backup <params>. The output is redirected to a file on the device and then can be pulled like any file.

The only drawback is that you can't do a full backup if your device is more than half full. This can be worked around if you have an external SdCard slot. bu can write there even on Android 4.4.2, because it is a system app. /mnt/extSdCard/backup.ab worked the same for me as /sdcard.

  • bu 1 backup -apk app.package.name > /sdcard/backup.ab creates an empty 47 bytes file in my case. Commented Nov 22, 2021 at 11:27
  • 2
    @user2284570 yeah, I had a similar experience (empty ab file) recently on Android 9. I think back in the day it was simply broken (0 bytes), but now they have further restricted access, and it'll be also removed, see link.medium.com/4edL3pBnolb
    – TWiStErRob
    Commented Nov 22, 2021 at 12:50

sigh I'm really sorry if this is the case, and you seem to be careful judging by your screenshots and command lines, but I discovered to my chagrin the same symptoms and thought I'd post just in case future discoverers make it here. It turns out that adb is very picky about single vs. double dashes in its options. For me, double dashes reproduced this case exactly: same prompt on the phone, same 0 byte file. Single dashes even though there are long argument names worked like a charm.

In case it matters, my phone is a Samsung Galazy Note 2 AT&T SGH-i317 running Android 5.1/Cyanogenmod 12.1.

  • This solved my problem. Commented Sep 11, 2015 at 0:38
  • Please post your actual command lines.
    – RoboJ1M
    Commented Feb 2, 2016 at 16:03

You need to execute the adb backup command on adb version 1.0.31.

For windows i did:


$ adb backup -apk -obb -shared -all -system -f bckp.ab

adb server is out of date. killing...

  • daemon started successfully *

Now unlock your device and confirm the backup operation.

...then set everything back to normal.


OK, this is how I fixed mine.

I tried Hunter Perrin's solution:

adb backup -apk\ -shared\ -all\ -system

But it just returned immediately with no error, no backup screen on the phone.

Through trial and error this worked for me:

adb backup -all\

I think I have a solution for those using 1.0.32:

enter a password when prompted on the android screen

Despite the fact that it says it will use the default password if you enter none, I believe it doesn't and adb 1.0.32 perhaps does not allow the creation of unencrypted backups.

Entering a password worked for me, then I ended up using "Android Backup Extractor" (Warning Sourceforge) and "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy" to extract it into a tar file.


I ran into the inverse problem: 1.0.31 with a newer phone (Android 7) fails too. 1.0.31 uses : as separator when passing arguments to the phone. As adb logcat -s BackupManagerService shows, the newer adb on the phone can't handle the old style either: 02-19 01:59:44.330 1100 9830 W BackupManagerService: Unknown package com.gameloft.android.ANMP.GloftPOHM:-apk, skipping Fortunately, the newer adb accepts spaces as separator too, so enclosing the arguments within double quotes works, e.g.: adb.exe backup "com.gameloft.android.ANMP.GloftPOHM -apk" -f game-backup.ab


For me it was that the package name had been changed, so adb backup wasn't finding it and was creating an empty backup file, without reporting any error. adb logcat showed the error. Once I updated the package name, adb backup succeeded.

This was using ADB version 1.0.41, with a desktop backup password enabled.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .