Thanks to @Firelord for generously helping me out when I got out of my depth. The problem description and notes about the solutions have been made using his comments as reference.
Problem:
That is because after you've issued adb shell
, you're in Android's system shell and cannot use adb pull
any longer, as the client ADB binary you invoked exists on your development PC, not on the connected device itself. The device acts as a server with the development PC as the client. The client issues the commands and the server responds to them. The server itself cannot issue the command.
The ADB on-device itself can also act as the client, with 2 caveats:
- ADB from device to same device needs ADB to be running in wireless and loopback mode.
- The other device, supposedly the "server", must initially be connected via OTG to the ADB client (later client & server) device so that ADB can be restarted there in wireless mode.
TL;DR
If you're running adb
from the platform-tools
directory of the Android SDK install, try issuing ./adb pull
instead of adb pull
in case you are on Linux, and, I suspect, similar with Windows. ADB is probably not in your PATH variable. The terminal remembers the folder history 1 level down, and the local folder by default is not included in the PATH variable.
SOURCE: This question on StackOverflow.
Resolution:
What you should do after the chmod
command is enter exit
, followed by adb pull...
. The exit
command should drop you out of the system shell back to whatever terminal/prompt you were using adb in on your PC, from where you can safely use adb pull
.
Alternative Resolution:
You could also use cp
instead of adb pull
after chmod
to copy the database file. They have the same usage pattern, and cp
is definitely available in the shell session.
Notes:
I have a niggling issue with the way in which you use adb pull
to copy files from your /data/data
to your SD card, which could easily be accomplished with a root explorer or cp
in a shell session.
Ensure that you have issued adb root
prior to this entire set of commands under Resolution: so the adb daemon runs as root and can access /data
and its subdirectories.
PS:
From @Firelord's comment, adb root
will only work if you have set the ro.secure
property in your build.prop
to 0
instead of 1
, where 1
is usually the default with the exception of some debug-enabled custom ROMs. In that case, take the cp
alternative.
- I have personally faced this issue and avoided mixing up ADB and shell sessions from then on.