I like the idea to create backup without any other tools and without require root - so "adb backup" seems to be the perfect solution.
But for some strange reason it creates just almost empty backups for some apps.
The command I use is:
adb backup -f ${APP}.ab -apk -share -nosystem ${APP}
Around 50% of my apps are suffered. I can't see any rule. Neither this are just payed apps, nor it depends whether they are from playstore or FDroid. What can be the reason for that?
I use that one on my ubuntu linux machine:
Android Debug Bridge version 1.0.39
Version 1:8.1.0+r23-5ubuntu2
Installed as /usr/lib/android-sdk/platform-tools/adb
Tested different parameters - no change.
I created a script that create backup for each user app (so skip these in priv-app and system folders).
Maybe that is useful for others. A complete backup is not very usefull, as there is no command to restore a selection out of the backup - all or nothing.
The script has two issues:
not all apps get backup
there is need to unlock for each app (tip on phone to confirm)
To create a list I used that command:
adb shell pm list packages -f | grep -v priv-app | grep -v '/vendor' | grep -v '/system' | rev | cut -d = -f 1 | rev | sort
Edit:
Think I could find the reason. In each APK there is an AndroidManifest.xml file that can/must (?) have a setting:
android:allowBackup
Whether to allow the application to participate in the backup and
restore infrastructure. If this attribute is set to false, no backup
or restore of the application will ever be performed, even by a
full-system backup that would otherwise cause all application data to
be saved via adb. The default value of this attribute is true.
Bummer!
I think two ways to workaround that. Either change that on phone (which might be not possible or need root) or to manipulate that before installing it.
It that will work I guess it has to repeat after each update.
Anyone has a solution?
Are backups without root/google cloud possible?
You can follow these steps:
copy the app's apk from the device to your computer
decompile the apk using apktool (using "d" option)
modify the allowBackup attribute in the AndroidManifest.xml and set it to true
recompile the app using again apktool (this time with "b" option)
install the recompiled app
use adb command you posted to perform the backup
I spend lots of time in finding a way to do it and can for sure say:
In 2023 with recent android versions (12 and 13) there is no way in getting app data backed up without root.
Even the mentioned apktool method doesn't work because android uses signed apks now.
Even if you try to bypass this using a custom certificate/keystore you'll need to uninstall the original app and then the app data is most certainly gone.
Related
With the backup command you could make a complete backup of android smartphones, now that I know only the pull command remains but it is not like the backup command, are there alternatives?
The adb backup command may be able to make a complete backup of an Android smartphone, but nowadays it becomes more and more useless:
adb backup can only backup apps that allow backup at all (an app has to declare allowBackup=true in it's AndroidManifest.xml or don't have such an entry at all). If it sets allowBackup=false then adb backup can not get any data on this app.
Cryptographic keys stored in AndroidKeystore can not be extracted, they are bound to the phone hardware. https://developer.android.com/training/articles/keystore
adb backup fails on recent apps that have targetSDK level to 31 or higher (if the abb is a production and not a debuggable app). adb backup was marked deprecated years ago, seems like Google wants to finally cut it off. https://developer.android.com/about/versions/12/behavior-changes-12#adb-backup-restrictions
I'm trying to install my apk on system partition. I've rooted device and here are the steps I'm following,
adb install -d -r <apk_name>
Now apk gets installed in /data/app/<apk_name>/
Move all contents present from /data/app/<apk_name> to /system/priv-app/<apk_name>
Clear the contents within /data/app/<apk_name> and reboot the device
Post reboot not able to find my apk under adb shell pm list packages | grep <apk_name>
I'm trying to read and write value to secure setting which is asking my app to be in system partition. When I'm trying to move I'm facing this issue. I could not find something suspicious from logs while installing the apk.
Tried all possible solutions listed here (Android 5.0/Lollipop: Force rescan of /system/priv-app) but none didn't help.
Any help to debug this issue would be really helpful.
I need help from you guys, because I don't know what I did wrong with adb backup.
I want to backup my Samsung Galaxy S3 LTE (GT-I9305) without root. I googled it and found Full Android Backup with SDK Manager. I installed all i need for this like Java Development Kit 8 version 66 (JDK 8u66 x64) and Android Studio which contains SDK Manager. Then they sad i should download the Google USB Driver. I downloaded it but nothing happened. I thought it should work now and then I went to C:\Users\MYNAME\AppData\Local\Android\sdk\platform-tools and left-clicked adb whilst holding Shift. Then I clicked "Open command window here". After this I typed in "adb devices" and it said:
List of devices attached
3204cfaaf8611199 device
Then I typed in:
adb backup -apk -shared -all -f C:\Users\NAME\backup.ab
It said
Now unlock your device and confirm the backup operation.
I did this and my Smartphone opened "Full Backup" and then I was able to set a password for the backup. I don`t need a password and I just clicked "Back up my data" Then it went back to my homescreen and said "Starting backup..." as a toast message and immediately after this it said "Backup finished" and created a backup file with 40 bytes. I don't know what I should do now.
Rather than trying to find an old version of adb, it's easier to add quotes to the arguments to adb backup :
adb backup "-apk -shared -all -f C:\Users\NAME\backup.ab"
The line, which correctly invokes adb, needs to look like this at my side:
adb backup "-apk -obb -shared -all -system" -f phone-20180522-120000.adb
This line is for Linux, but should do for Windows and OS-X as well. For Linux (and probably OS-X), you can use a script like following, which automatically assigns a timestamp to the file:
adb backup "-apk -obb -shared -all -system" -f "${PHONE:-phone}-`date +%Y%m%d-%H%M%S`.adb`"
Important After doing a backup, verify your data! At my side, sometimes some corruption of the file shows up (and I doubt it is my computer, as I only observe such errors with adb).
Here is a check instruction I use:
set -o pipefail
for a in *.adb;
do
echo "$a";
dd if="$a" bs=24 skip=1 | zlib-flate -uncompress | tar tf - >/dev/null;
echo "ret=$?";
done
It should show ret=0, but it doen't.
If you see inflate: data: invalid code lengths set your archive is corrupted and - very likely - unusable for restore!
If you see tar: Unexpected EOF in archive your backup probably is usable (all backups end this way, I do not know why).
Even if you see just ret=0 there might be undiscovered errors which still prevent a restore.
There is definitively missing an adb verify command, to verify correctness of a backup!
FYI
I post this update, as all other answers were helpful, but not exact to the last detail. (When used with full quotes, a backup was done, but called backup.ab)
Here is my environment:
OS: Ubuntu 16.04
Phone: Android 7.0
ADB: 1.0.32
The full procedure was (just in case somebody stumbles upon this not knowing what is needed):
Zeroth: Install adb (on Ubuntu: sudo apt-get install android-tools-adb)
First: Enable USB debugging mode on the phone.
Second: Attach phone to USB of the computer with an USB data cable (a charge only cable is not enough)
Note that the Ubuntu Phone Manager might show up and ask you for the phone's PIN. You do not need that, close this if it happens.
Third: run adb devices - you should see something like XXXXXXXXXXXX unauthorized
After some time on your phone a message shows up which asks for USB debugging permission
Allow this once. For security reasons, you should not automatically trust the computer, as the fingerprint can be easily faked.
Note that if something is obstructing a single pixel of this confirmation window (like some accessibility feature button) you cannot tap on the OK. First move the obstructing window.
Forth: Now again run adb devices - you should see something like XXXXXXXXXXXX device
If more than one line shows up, you attached more than one phone to the computer. The easy way is to unplug all those you do not want to backup. (The complex way is to set the environment variable ANDROID_SERIAL=XXXXXXXXXXXX.)
Now run adb backup as shown above. Change the file to your needs.
This brings up a window which asks for backup permission.
Do not close the backup window while the backup is taken. When I tried this, the backup stopped and the resulting archive was broken.
You can give a password to encrypt your backup. I do not have any information on how secure the password is. But it is very likely, that you cannot restore the backup taken in case you ever forget this password.
I have no idea on how to restore such a backup to other phones. I even never tried the restore, so I cannot help here, too.
Notes:
adb help shows all possible options to adb backup
Close all open applications on your phone before the backup. I do not know if this is needed, but it certainly cannot hurt.
Leave the phone alone while the backup runs. I do not know if this is needed, but it certainly cannot hurt.
Do not be impatient. Leave the backup plenty of time. At my side I see a progress of about 100 MB/Minute (YMMV). So the backup takes about half an hour for my phone (2.5 GB).
Apparently adb backup does not completely backup everything!
I had a look into the backup (cd X && dd if=../XXXX.adb bs=24 skip=1 | zlib-flate -uncompress | tar xf -) and did not find all installed applications.
What I was able to find was (note that this list is incomplete):
Internal emulated SD-Card: shared/0
External SD-Card: shared/1
Apps: apps/ - many apps (like Google Authenticator) were missing
Calendar: apps/com.android.providers.calendar/db/calendar.db (probably)
What I was not able to find (note that this list is incomplete):
Alarms. (I was probably not able to detect the right app)
Full external SD-card (there is more on this card than what is shown below share/1. For example the apps, which are moved-to-SD.)
Conclusions:
Sometimes adb backup might create corrupt backups, which can go unnoticed. So either check your backup or do frequent backups and pretend to be lucky enough such that not all backups go corrupt.
With adb backup you get a backup of most of your precious data, like camera images and so on. It might be a bit difficult to unpack it, though.
adb backup is not enough to do a complete backup of your phone.
adb backup is not enough to backup your SD-card such, that if it breaks, you are able to replace it by a new one with the contents restored. This is very sad!
PS: The typo "Forth" is not an accidental one.
PPS: zlib-flate can be found in package qpdf on Ubuntu 18.04
This just worked using Ubuntu 15.10 ("wily") to backup a Galaxy SM-G900V running Android version 6.0.1.
Installed using:
sudo apt-get install android-tools-adb
Then I ran the following from the command line (without 'sudo'):
adb backup -apk -shared -all -f backup.adb
Result:
user#hostname:~/droid$ ls -lah
total 1.2GB
drwxrwxr-x 2 user user 4.0BK Mar 6 18:43 .
drwxr-xr-x 52 user user 4.0KB Mar 6 17:40 ..
-rw-r----- 1 user user 1.2GB Mar 6 18:29 backup.ab
Thank you "NG". I was beginning to think my phone was borked.
Forgot to add: Running adb version: Android Debug Bridge version 1.0.31
Seem not all apps can be backed up. Android apparently allow apps to disable backup :(
https://developer.android.com/guide/topics/manifest/application-element.html (search for allowbackup)
The problem is the adb version of your PC. Using adb version 1.0.31 the backup/restore will be sucessfull.
More info on: https://android.stackexchange.com/questions/83080/adb-backup-creates-0-byte-file-prompts-for-current-backup-password-even-though
and How to downgrade my SDK Version?
If your device has an adb version prior to 1.0.31, then you must use an adb version of 1.0.31 on PC. Versions of adb 1.0.32+ broken the backwards compatibility. Source: Issue 208337
Just incase anyone is still having trouble - In windows, I found putting the quotes around only the directory, for example "C:\Users\NAME\backup.ab" worked.
I found this solution :
adb backup -apk -shared -all -f "<path-where-the-backup-will-be-created>.ab"
And to restore :
adb restore "<path-where-the-backup-is>.ab"
i want to do my Home app,and put it to /system dir,and my home app is the Unique home.of course i custom made my home app,and modify android source. all is ok. but i have a question, how to auto update my home app，i donot want to :
adb root
adb remount
adb shell rm /system/app/your.apk
adb push your.apk /system/app
if i can do it like common app update like:
download apk and
intent.setDataAndType(Uri.fromFile(file), "application/vnd.android.package-archive");
mContext.startActivity(intent);
or modify android source. can someone give me advice?
You can use the "common app update" method, or install the apk silently using android.permission.INSTALL_PACKAGES.
Either way your /system/app/whatever.apk is untouched, as it is not possible to change it without root (and the remount thing you mention in the question). Instead, the updated apk will get stored as /data/app/whatever.apk which will replace your system app. You can still use system app features.
The user can remove the updated apk ("uninstall updates") similar to regular, non-system apps, in that case, your original system apk is used again.
I'm tired of uninstalling and than reinstalling in development.
Is there a way to do adb -force install some.apk ? I mean this would save a lot of time. Each time going to system ->apps->uninstall every time a signature is different.
Obviously debug is a dev setting so I don't see why one constantly needs to uninstall the app manually, what a waste of time? Anything that can make development easier is going to result in better code, and better apps so whats up with this?
I have hot deployed to server side Java EE servers in less time. This is less an issue on command line, since one could do an uninstall or replace the adb script with an uninstall followed by an install.
However in eclipse its still a pain. It has been pointed out that this is largely about signature changes. Yes, it is. But why should signatures change in development, and debug mode, and cause the reinstallation issue?
adb has [-r] parameter to reinstall.
adb install -r some.apk
A web search you could have done reveals that the answer to your adb question is:
adb uninstall some.package.name
Note that it's not the file.apk name you use with adb install, but rather the actual package name it ends up installed as.
The normal build process uses the android debug keystore that can be found in your android folder in your home directory (path depends on your OS).
With this debug keystore your app will be signed. This debug signature can be installed on every android device in the world as long as there isn't your app with another signature already installed.
When you say you only do code checkouts, rebuild and your signature is different, than probably your build process is broken. Your debug keystore is valid for at least a year and as long as you are on the same PC while building the generated APK should never have a different signature.
For further checking you should bring some light in your development process. What do you use? Eclipse?
If you work on different developing machines, pick one keystore from one machine and put it into your version control and use this to sign your apk with the debug signature.
adb install -r -d path/to/file.apk
-r to replace
-d to force downgrade
You can install an app forcefully by passing -r parameter.
-r parameter lets adb to reinstall the app.
adb install -r app-release.apk
The debug keystore can be set in Eclipse in Preferences/Android/Build/Custom debug keystore, which is very helpful when working in a team. Every member should set up the same keystore there, and then it is no problem any longer to share devices.
for uninstall
adb uninstall app_package_name
for install
adb install app_package_name
into the command prompt in windows
and terminal in linex/Macos