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.
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.
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.
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
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.
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.
From @Firelord's comment,
adb root will only work if you have set the
ro.secure property in your
0 instead of
1 is usually the default with the exception of some debug-enabled custom ROMs. In that case, take the
- I have personally faced this issue and avoided mixing up ADB and shell sessions from then on.