Develop Reference

"adb pull" stuck in half way

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.

Android adb logcat missing some logs during emulator booting

I met a weird issue when I tried to search some logs during emulator booting.
When I create an emulator, the adb device started with "offline" first, then I type
adb logcat -v time | tee log1.txt
and adb will keep "wait-for-device" until the adb became online.
Then when the emulator boots up, I type adb logcat -v time | tee log2.txt again except the destination of the log file.
Now, I use vimdiff log1.txt log2.txt to compare these two logs and found log1 missed many logs as Log_Diff
I have no idea why some logs in log1.txt will missed.
Any ideas?
P.S. I am using Android 5.1-64bit Emulator in sdk.

After some research, finally I found the root cause in Android log daemon.
The main problem is the LogBufferElement is using a CLOCK_MONOTONIC timestamp as the sorting index.
When the timestamp of the multiple LogBufferElement are the same, LogReader may only dump the last entry. That's why some logs seem being lost.
AOSP Android 5.1 still had this issue, but Android 6.0 had fixed it.
You can refer to this patch.
Btw, I also did some modification for this patch.
The main reason is Android 6.0 supports the C++ 11 atomic std libs, but Android 5.1 is not yet. Some the atomic APIs need to roll back. (e.g. atomic_fetch_add_explicit())

Android: The right way to debug an running application (runtime errors/log)

I am new to Android development. I have been going through the tutorials.
I would like to know which is the right way to debug / log an application during its execution. I am guessing I should be able to execute my application directly on my android device and be able to view a log or so to catch runtime errors and logs?
How could I accomplish this ?
I am using this to install the application on my phone
adb install <path to apk>
p.s. I am sure this question might seem like something I should already know. But I could not figure it out :) Hence I am here :)

You can build on the command line with ant. See this guide.
& install it by using adb on the command line.
adb install MyApp.apk
path of apk with file extension
update
for getting logcat or crash report
do this way:
adb logcat
note: make sure only one device is connected to adb bridge
for filtering:
check this & this.

Android: Adb rejected connection to client

I was trying to install an app on my nexus 5 from intellij and for the first time i get an error saying
"DeviceMonitor: Adb rejected connection to client '5081': closed"
I tried restart my adb restart computer, disable, enable android debugging sync gradle.
The weird thing is that when i try running it on a virtual device it works.
Anyone has an idea?
Here is the full error code :
DeviceMonitor: Adb rejected connection to client '5081': closed
DeviceMonitor: Adb rejected connection to client '5064': closed
DeviceMonitor: Adb rejected connection to client '4962': closed
DeviceMonitor: Adb rejected connection to client '5081': closed
DeviceMonitor: Adb rejected connection to client '5064': closed
DeviceMonitor: Adb rejected connection to client '5064': closed
DeviceMonitor: Adb rejected connection to client '3483': closed
DeviceMonitor: Adb rejected connection to client '3483': closed
logcat shows nothing, i tried running it in terminal "adb logcat" and it showed normal either.

I just had this issue, and Googling didn't yield a ton of results when I looked it up. Alchete's answer was what solved this issue for me, but being new to the Windows command line, I didn't know how to execute it. So I just want to elaborate in case anyone is in the same boat as I was.
Open the Start Menu and type cmd to get to the command line.
Change directories to get to the sdk folder that contains the adb.exe file.
For me the command looked like this:
cd Documents\Programming\android-studio\sdk\platform-tools
Adjust based on the path to your sdk folder.
Then, you can enter:
adb kill-server
Followed by:
adb start-server

I just had this problem as well. Closing and re-launching Android Studio had no effect.
The solution for me was to execute the following commands in a terminal window:
adb kill-server
adb start-server
After that, my Android device connected as normal.

I had the same problem recently.
I had moved the intent-filter tag in the AndroidManifest.xml file inorder to start a different activity.
What I had forgotten to do was change the run/debug target inside Android Studio. Click Run -> Edit configurations. Look at Launch string and check it matches the activity in AndroidManifest which has the launch XML inside it:
Launch XML:
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>

My reputation is not high enough, but I wanted to respond to say that Alex Lowe's and Alchete's answer worked for me, combined with andy boot's answer. (+1 to Alex Lowe for the detailed response).
Furthermore, restart your Android Studio session once you have killed the adb. The server should start right back up again.
If, like me, you are getting this error because you may have changed intent filters around in your Android Manifest, i.e. you created a Splash Screen and added the Category_Launcher intent
For example, CATEGORY_LAUNCHER means it should appear in the Launcher
as a top-level application
..then you will want to make sure it is specified as your Launch Activity as previously explained (Run - Edit Configurations - Launch). "Launch default activity will initially be selected, but you want to change that to the new Activity you have specified as your Launcher.
Hopefully one of those two solutions will work!
Also, if you are having trouble finding the directory path for your Android SDK, go to your SDK Manager in Android Studio and the directory path should be at the top of the dialog box.

I had the same problem which in my case was due to having erroneously selected wear instead of app (and the watch feature was optional, see e.g. android studio error : missing feature: WATCH for details). The GUI was stuck in "waiting for phone" forever.

Where does Android store shutdown logs?

I know that the boot up log can be obtained by pulling out contents of kmsg or dmesg through ADB.
But I'm not aware of how to retrieve the shutdown logs in Android as there's no /var folder in Android (place where most desktop linux distros generally store their shutdown logs).
So how can I obtain the shutdown logs in Android?

Look in some locations such as these:
/proc/last_kmsg
/data/tombstones/
/data/dontpanic/
/data/system/dropbox/
(This list isn't strictly kernel logs, including framework and application logs too, which are also sometimes of interest)

One work around I found for collecting shutdown logs in Android is to run adb pull /proc/kmsg C:\Logs.txt on the host PC and then switch off the device. You will get the logs till the USB communication between the host and the device snaps! I know this is only one case out of the numerous shutdown scenarios but I haven't found satisfactory answers for other cases!

TL;DR:
Run command through adb that copies logcat and proc/kmsg to a file and keep it running even when adb disconnects with nohup, disown or setsid. Probably needs busybox, needs root and adb root, too.
setsid cat proc/kmsg > /sdcard/kmsg.txt &
and
logcat -v long -f /sdcard/logcat.txt (somehow only works without setsid)
Or add normal copy commands to some startup script.
/TL;DR
You can constantly copy proc/kmsg and logcat to a file on your android device or a microSD card to get the logs even after adb disconnects.
You need root access and adb root access for this to work. For the latter, use the setting in the developer options if you have a custom rom or the adbd insecure app.
After using adb shell to get your android shell, type su to get superuser access.
Then you not only need to put an ampersand (&) after the command but also make sure that the command keeps running after adb disconnects. That is done by nohup, disown or setsid (see here for usage).
If it doesn't work because you don't have these commands, you need to install busybox.
See my question here.
See here for how to get logcat and kernel logs and print it to some file or merge it.
See developer.android.com/tools/help/logcat.html for parameters for the logcat command.
In the end you could have a command like setsid cat proc/kmsg > /sdcard/kmsg.txt & for the kernel messages.
For logcat you could have one of the following commands: logcat -v long -f /sdcard/logcat.txt or logcat -v long > /sdcard/logcat.txt
I don't know why, but sometimes it didn't work with setsid and just didn't copy continuously but stopped shortly after executing the command. In these situations, it also showed up when entering jobs, which it didn't otherwise. Then it just worked without setsid, it stayed alive after disconnecting and reconnecting. I guess you must just try when the file does keep getting larger. If someone figured out why it is behaving like it is... let me know and I'll edit the answer.
Probably adding the commands to a startup script could be a solution for some, too.
Hope this helps.
fightcookie

Newer phones do NOT use any of these locations so if you're reading this article then as of now
The kernel crash logs are now in /sys/fs/pstore instead of /proc/last_kmsg

I was looking for the same thing, and finally, I found the answer!
In android 8 all logs are located in \data\log\android_logs\... including apps and kernel logs. Kernel logs are called kmsgcat-log_timestamp_.gz
edit: Although this is a very old thread, I think the answer might be helpful.