Samsung Galaxy Tab 10.1 16BG Wifi-only, retail (not I/O) edition, running 3.1.
Up until a few days ago, I could access /data/data/com.my.app/{databases,...} from the Eclipse DDMS perspective without issues. This helped with development by e.g. letting me pull sqlite files to make sure my DB code was doing what I thought it should be doing, accessing the sqlite files from the Linux command line.
A few days ago I came to my desk and found the tab in a strange state: as if stuck in the boot process, and warm to the touch, suggesting that the CPU was spinning.
I assumed it was a crash, rebooted it and thought nothing more of it until, earlier today, I can no longer get DDMS access to /data. /system and /mnt are accessible.
Is anyone aware of what might have caused that change, and if/how it can be reversed? I had not rooted the tab before, and although I understand rooting it may bring back access to /data (over DDMS?) I'd rather try to understand what happened before proceeding.
Has anyone else seen the same/similar behavior?
Update: Here's what this looks like from an ADB shell:
shell#android:/ $ ls -ld data
drwxrwx--x system system 2011-07-05 15:49 data
shell#android:/ $ cd data
shell#android:/data $ ls
opendir failed, Permission denied
255|shell#android:/data $
Related
Suddenly my "adb pull" command will stuck in the middle of the process.
I'm not sure what cause it, after install some application or driver.
Happens for Pull one files or multiple files.
Does anyone encounter the same issue before? thanks.
Example:
U:\batch>adb pull /sdcard/xxxlog/mobilelog .\xxxlog\
[ 94%] /sdcard/xxxlog/mobilelog/APLog_xxx/main_log_1__xxx: 87%
Here a screenshot from my console
for my specific answer, and provide a possible answer to who encounter similar problem.
after I reinstall the whole os, testing different adb version,
the issue still remains.
during testing adb version,
I found the issue will not happens if i use Local Disk...
where issue happens when using Network Drive..
So a possible solution, is don't use Network drive
I encountered similar problem on adb server (v 1.0.40) started on Windows 7 machine. When tried to pull files from device on other machine running Linux in same local network (I used: "adb -H pull ...") the adb was freezing occasionally.
The solution was to not use Windows for ADB server.
This problem was NOT visible, when adb server was running on Linux VM (Ubuntu 16.4/ VirtualBox). Hope that this helps.
BR,
Ziggy
Every time I encounter this, it ends up being a max path length issue. Open a shell on the device using adb and review the file names within the directories that you are pulling. If any have exceedingly long names, they will silently fail and adb will hang
The thing that really throws you for a loop is that it usually fails after giving a percentage complete which makes you think it's a faulty connection or some other issue.
I haven't found a good way to recursively list out file names in shell and test their name length prior to doing the pull in order to know that the issue is going to happen, but when I have the same issue and rename long files, it ends up working on the next attempt.
I encountered the same problem when trying to transfer a large amount of data from an Android phone to a Raspberry Pi 3B+, and the logcat output seemed to reveal that adb was silently failing due to an issue with USB buffer reads (unfortunately, I don't have the exact message with me).
After the initial failure, it was possible to get another few files individually by unplugging the phone, running adb kill-server and adb start-server, and plugging it back in between each one, but the only longer-term fix I could find was restarting the Raspberry Pi. This solution, however, is not permanent, and must be repeated occasionally.
I was not able to replicate this issue on Windows or on a traditional Ubuntu system.
I encountered this problem while copying files from My Ubuntu machine to my Pixel 7.
A workaround based on this bug report, is to run
adb shell exit
in another terminal whenever it gets stuck until all files are copied. You can also run
watch -n 30 adb shell exit
to run the command every 30 seconds so you don't have to keep watching the process. I hope this helps someone.
I use VS2015 with Xamarin to deploy an app to my phone. After recently rooting and wiping my phone data, I'm receiving errors upon deploying. The most common issue was that the "Fast deploy" was enabled, but I already had that turned off.
I figured out that my ADB Install seems to fail (permission denied), giving me the following error:
failed to copy 'x' to '/data/local/tmp/x': Permission denied
It really starts working on my nerves, and after trying several things which I found on the internet, I ended up asking a question here.
When I go to my 'ADB Shell' (running in root mode and showing this # sign), and type 'ls -ld data data/local data/local/tmp'
it shows the following, which seems to be normal (according to things I read):
drwxrwx--x system system 2016-06-26 15:11 data
drwxr-x--x root root 2016-06-26 08:52 local
drwxrwx--x shell shell 2016-06-26 01:58 tmp
I started by recreating the 'tmp' folder, and using 'EF File Explorer' on my phone I can modify things and do everything I'd like to do. (modify rights, add folders, remove folders, recreate the folders and so on).
When I go to 'Root explorer' in EF File Explorer, I changed the '/' folder mode to 'RW', but it didn't make any change. Root explorer says it's still on "r/o" (read only) mode.
I tried the 'busybox mount -o remount, rw /system' trick and other mount-commands which did the trick for others, but still same issue with my phone.
Furthermore, I tried a "move" trick in the shell, which didn't work out either.
As a last option I even tried to do a full format/wipe, but even thát did not solve my issue.
So I'm currently back at square one, where my 'ls -ld' is still showing the same information. Copying files to the internal storage via Windows Explorer works as it should.
Hopefully I'm doing something stupid and is there a fix for this issue. Thanks in advance for your help.
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 have this "old" Lenovo A2107 tablet which I rooted years ago (using a download from http://androidforums.com/threads/a2107-root-mods-and-rom-discussion.661261/, tho running its root.bat script by hand from my GNU/Linux machine) and that worked fine.
Then I passed this tablet to my daughter for a couple years, and now I got it back.
/system/bin/su is still present, still the same date and size, still mode "rwsr-sr-x", still the same firmware (Android 4.0.3) so all looks fine, but when I try to run it from a shell, it just tells me "Permission denied".
Any idea what might be going on? What I could try to do to track it down?
Nowadays Magisk is commonly used for rooting.
I've found that on my Oneplus 5 (Oxygen OS, Nougat) it was sufficient to go to Magisk Manager app, open superuser permissions screen and toggle Shell (com.android.shell) to resolve the adb su permission denied problem.
OK, for those curious to know, I figured out what it was: the /system/bin/su program either accepts the request as-is (depending on who asks) or passes the request to some other program (Superuser.apk).
As it turns out, I still have /system/bin/su but Superuser.apk was missing. Luckily, /system/bin/su worked fine from the "adb shell", even though it said "Permission denied" when used from ConnectBot and other terminal emulators. So I used "adb shell" to get root access and manually copied Superuser.apk into /system/apps.
FWIW... I had a similar problem ( running 'su' from ADB shell yielded 'permission denied' ), so I'll describe my solution.
For context, I had rebrained my Galaxy Nexus with CyanogenMod.
So, I looked at the system settings, and it contains a 'Superuser' section; in that section's own settings ( small menu ), there is a 'Superuser Access' option, which was set to 'Apps only'. I changed that to 'Apps and ADB', and then I was able to start an ADB shell, and from that shell, I was now allowed to run 'su'. :-)
A few days ago I received complaints from several customers who told me that "adware is installed automatically on your device Krono NET K5". I made invesigar and found a few apk on / system / app that had different permissions to the usual "rw-r - r--". I could erase the few simple steps in a shell:
adb shell "su -c 'mount -o rw, remount /'"
adb shell "su -c 'rm /system/app/156.apk'"
adb shell "su -c 'rm /system/app/Launcher0607wxDjbOa.apk'"
adb shell "su -c 'rm /system/app/Sync.apk'"
adb shell "su -c 'rm /system/app/SettingProvider.apk'"
(Note that a suspect name as there is a apk using the system call SettingsProvider.apk with letter s)
So far everything worked properly, however there is a apk which is the main cause of all adware and causing the discharge cone apk other battery savers, system cleaners, among others. This application is:
"/system/app/providerdown.apk" Permits "rwsr-sr-x"
I tried to remove it by the above method, I tried to change the permissions to remove it and it has not worked. I tried to install a recovery to eliminate apk thence Aroma File Manager (CWM, TWRP) MTK but this device does not support any custom recovery for devices MTK.
Any idea? Thanks in advance (sorry for my bad english)
I have same problem. You will have to be rooted for this, but i guess you have root because of that code you wrote, and the fact that app somehow gains root access and installs itself in system. Only thing I did to make things easier is:
Download Avast to your phone.
Download Clean Master to your phone and with Clean master make backup of your avast apk.
Go to your stock recovery. I used an app from google store to boot to recovery but any way is good.
Clean cache and do a factory reset.
Boot the device.
DO NOT CONNECT DEVICE TO ANY NETWORK.
Just skip all the stuff like login to your google account and other settings.
Find your Avast apk in the sd card and install it.
Turn on firewall and block all acces to TimeService-that is the name that apk uses when seen from android system.
Go to android system and disable time service. It is probably version 1.1.6
You will still have malware in your device but it wont make mess anymore.
I would like the permanent solution too.