I'm having a problem with emulator-5554, it keeps telling me it is offline.
When I do a adb devices from the command line it says
emulator-5554 offline
Even after a fresh restart, I try that command and it still says it is offline.
The problem is when I try to install .apk files to the emulator using abd install <path> from the command prompt, it tells me that it is offline, if I create another device and run that one, then try to install the .apk files, it says I have too many devices connected. So in other words, I can't install my .apk files.
How in the world can I get rid of that damn emulator-5554? I heard that if you do a restart, it should clear all the devices, but that does not seem to be working. It is like it is getting initialized when my computer starts up. Has anyone run into this issue?
Thanks
1 . Simply "Wipe data" to fix this issue.
2 . If it doesn't work, go to emulated device and enable developer options > enable usb debugging
In such a case, you can do all of the following in order to be assured that your emulator starts working again :
Go to cmd and type adb kill-server
Go to task manager and find adb in processes. If you find one, right click on it and click on end process tree.
In eclipse, go to Window>Android Virtual Device Manager, click on the AVD you want to launch, click on start and uncheck "Launch From Snapshot" and then click on launch.
That's it! It will take a while and it should resolve your problem.
The way that Android detects emulators is by scanning ports starting at port 5555.
The number you see in the adb devices list (in your case 5554) will be one less than the port that adb is finding open.
You probably have a process running that is listening on port 5555. To get rid of the "offline" device, you will need to find that application and close it or reconfigure it to listen to a different port.
This solution is for Windows.
(See #Chris Knight's solution for Mac/Linux)
Start Windows Powershell:
Start -> type 'powershell' -> Press ENTER
Run the following command: adb devices
PS C:\Users\CJBS>adb devices
List of devices attached
emulator-5656 host
emulator-5652 host
12b80FF443 device
In this case, 12b80FF443 is my physical device, and the emulator-* entries are garbage.
Per #Brigham, "The way that Android detects emulators is by
scanning ports starting at port 5555.". The port number is indicated after the emulator name (in this case 5656 and 5652). The port number to check is the emulator port number plus 1. So in this case:-
5656 + 1 = 5657
5652 + 1 = 5653
So let's see which program is using these ports. In this case, the ports to check both start with "565". So I'll search for ports in use starting with 565. Execute: netstat -a -n -o | Select-String ":565"
PS C:\Users\CJBS> netstat -a -n -o | Select-String ":565"
TCP 127.0.0.1:5653 127.0.0.1:5653 ESTABLISHED 5944
TCP 127.0.0.1:5657 127.0.0.1:5657 ESTABLISHED 5944
The final field in this output is the PID (Process ID) - in this case it's PID 5944 for both of these two ports. So let's see what this process ID is. Execute: tasklist /v | Select-String 5944. Replace 5944 with the output of the previous command:
PS C:\Users\CJBS> tasklist /v | Select-String 5944
adb.exe 5944 Console 1 6,800 K Running MyPCName\CJBS 0:06:03 ADB Power Notification Window
What a surprise. It's ADB. As noted by other answers, it could be other programs, too.
Now, just kill this process ID. Execute kill 5944, replacing 5944 with the PID in the previous command.
PS C:\Users\CJBS> kill 5944
To confirm that the spurious emulator is gone, re-run the following command: adb devices
PS C:\Users\CJBS>adb devices
List of devices attached
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
12b80FF443 device
ADB re-starts (as it was previously killed), and it detects no more fake emulators.
From the AVD Manager try the "Cold Boot Now" option in the drop-down. It worked for me!
If you are on Linux or Mac, and assuming the offline device is 'emulator-5554', you can run the following:
netstat -tulpn|grep 5554
Which yields the following output:
tcp 0 0 127.0.0.1:5554 0.0.0.0:* LISTEN 4848/emulator64-x86
tcp 0 0 127.0.0.1:5555 0.0.0.0:* LISTEN 4848/emulator64-x86
This tells me that the process id 4848 (yours will likely be different) is still listening on port 5554. You can now kill that process with:
sudo kill -9 4848
and the ghost offline-device is no more!
On macOS Big Sur and later, use
sudo lsof -i -P | grep LISTEN | grep 5554
to find out the process.
I finally solved this problem,
I had to go to the Developer options from the Settings in the Emulator,
then scrolled down a little, turned on the USB debugging. Instantly my device was recognized online, and I no longer faced that issue. I tried restarting android studio and emulator, killing adb process, but those did not work.
I also had the same issue. I've tried all solutions described here, but they didn't help me. Then I've removed all emulators in the Android Virtual Device Manager and created new ones. The problem was in the CPU/ABI system image configuration of the Android Virtual Device Manager. My Windows10 machine emulator with system image x86 is always offline, where the emulator with system image x86_64 is working fine as expected. Just be aware of this
I solved this by opening my commandprompt:
adb kill-server
adb devices
After starting up, ADB now detects the device/emulator.
In my case, I found some process that makes adb not work well.
You can try to kill some strange process and run "adb devices" to test.
It worked for me:
kill the process name MONyog.exe
Just write
adb -e reboot
and be happy with adb))
Enable USB Debugging into your emulator
Settings > About Phone > Build number > Tap it 7 times to become developer;
Settings > Developer Options > USB Debugging.
That's it enjoy
The "wipe user data" option finally solved my problem. just wipe user data every time you start the emulator. This always works for me!
I use windows 8 x64 , eclipse
open your emulator,
setting --> about emulated device --> click Build number repeatedly-->open developer options --> open USB debuggin
From AVD manager list at the actions dropdown:
Cold Boot Now
restarts it without all pain above.
Do you have bluestacks installed? If you do, the background processes that it runs creates the offline device "emulator-5554".
Go to the task manager and end all the processes with the description of "Bluestacks"
Try this ...
Close emulator if it Running.
Start Emulator again and wait for its online.
enter Command in commandprompt and press ENTER key : adb tcpip 5555
(Make sure that only One emulator running at a time.)
adb -s emulator-5555 emu kill
Press Enter Key....
Done.
check devices by command "adb devices" in cmd.
In my case, I started in 'Cold Boot Now' and clicked on Message to allow the connection.
Did you try deleting and recreating your AVD?
You can manually delete the AVD files by going to the directory they're stored in (in your user's /.android/avd subdirectory).
Go to windows task manager and end process "adb.exe". There might be more than 1 instances of the same process, make sure to end all of them.
on linux or mac the port thats blocked will emulator-id + 1 so 5555 so:
sudo lsof -i :5555
will show you the pid of process that are taking the port (should be the second column) so to kill it:
sudo lsof -i :5555 | awk '{print $2}' | xargs kill
then adb (fake) devices will no longer show on the list
In my case, the emulator was working with Oreo and lower, but not with Pie, and everything I tried seemed to have no effect. What finally worked was updating the emulator to latest (version 28).
I found that the emulation environment comes up as "offline" when the adb revision I am using was not recent. I properly updated my paths (and deleted the old adb version) and upon "adb kill-server", "adb devices", the emulation environment no longer came up as "offline".
I was immediately able to use "adb shell" after that point.
If the emulator is already open or executing it will tell you is offline. You can double check on the Command Line (Ubuntu) and execute:
adb devices
You must see your emulator offline, you have to close the running instance of the emulator (since the port will show as busy) and after that you can run your application. Hope this helps someone.
I tried everything but only this one works for my case:
Use SDK manager, and reinstall the system image.
Android Studio, click Configure, SDK Manager, Launch Standalone SDK Manager,
Check all "Google APIs Intel x86* System Image", "Intel x86 Atom*System Image" and install. Then re-start Android studio.
You might have to reconfigure and wipe the virtual device with AVD Manager, make sure you choose x86 version.
Ensure that your enable ADB integration is marked;
go to Tools>Android>Enable ADB integration .
if doesn't checked , check this option and close your virtual device and re-open it . this worked for me.. good luck!!
In MAC, you can use Activity Monitor utility, since, unlike Linux, we cannot use netstat -tulpn command in MAC. Search for the running instance of the emulator, typically qemu-system-i386. Kill that instance and you will see none of the ghost emulator running.
Simplest way to grab Activity monitor utility is to use spotlight search. just hit cmd-space and type in Activity Monitor.
I had the same issue with my virtual device. The problem is due to the Oreo image of the virtual devices that have the Play Store integrated. To solve this problem I installed a new device without the Play Store integrated and all it was fine.
Hope it helps, Bye
See emulator-5554 unauthorized for adb devices. On API 29 emulator I run adb devices command and got emulator-5554 unauthorized message. Then I created a new avd device from Google APIs image (in my case Q, x86), not from Google Play.
Simply delete and created gear avd again.It will work.
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 understand that this question has been asked 1000 times but every answer I can find on Stackoverflow and other websites are all the same: Either (1) The user is using Genymotion, (2) the user is using HTC Sync in Windows.
I am doing neither. I am currently running in OS/X (10.11.6) and am using a Moto X (2nd gen) phone running Android 6.0.
Many times (not every time) when I run "adb logcat", I get
adb server is out of date. killing...
* daemon started successfully *
This is a problem because I am trying to run some automated tests using gradlew (since using "adb shell am instrument" doesn't produce the JUnit style report I need) and collect logs... but every time I start "adb logcat", something in gradlew (apparently) tries to startup adb, which then kills all running instances of adb.
Has anyone seen this problem without using Genymotion/HTCSync/Windows and knows a solution?
Thanks!
The root cause of the server is out of date issue is still the same regardless the OS and/or other software used - you have multiple copies of adb binary in your system. And the solution is also the same:
kill all running adb processes
make sure you have the only copy of adb (remove the duplicates)
update it to the latest version
reconfigure all your software packages to use that copy
Just check that every tool you use is using the same adb version. For example, delete all versions except the latest.
Please check all your environmental paths which ADB has.
Your system may have several ADB.exe files so that mismatches makes the issue.
My Phonegap app refuses to load onto my Android device (even the HellowWorld default app is refusing to load)
Everything was running just great until today.
Here's my console log:
***\>adb devices
List of devices attached
4c05609b device
***\>phonegap run --device -V android
[phonegap] detecting Android SDK environment...
[phonegap] using the local environment
[phonegap] compiling Android...
[phonegap] Generating config.xml from defaults for platform "android"
[phonegap] Compiling app on platform "android" via command "cmd" /c ***\platforms\android\cordova\build
[phonegap] Platform "android" compiled successfully.
[phonegap] successfully compiled Android app
[phonegap] installing app onto device
[phonegap] Generating config.xml from defaults for platform "android"
[phonegap] Running app on platform "android" via command "cmd" /c ***\platforms\android\cordova\run --device
It just sits there saying running... forever.
I have another terminal window open with adb logcat running and at some point (maybe 10-15 seconds into that last line getting printed) it stops logging. Termination of the process and subsequent calls to adb logcat result in more hanging (no logging at all)
So then I have to do a kill-server, start-server to break out of this endless hanging at which point the phonegap process terminates with:
[error] An error occurred while running the android project.
***\platforms\android\cordova\node_modules\q\q.js:126
throw e;
^
ERROR: Failed to launch application on device: ERROR: Failed to install apk to d
evice: Error executing "adb -s 4c05609b install -r "***\platforms\android\bin\Po
ached-debug-unaligned.apk"": protocol failure
I have tried::
deleting my .cordova folder in C:\Users\Name
running the adb install directly (without phonegap)
deploying to an emulator (same problem)
unplugging / replugging the device
rebooting all devices
toggling "developer mode" on the device and revoking USB debugging privileges
I am all out of ideas!
Would greatly appreciate any tips or leads.
ADB version 1.0.31
Galaxy S3 running Android v4.3
EDIT:
Deploying to an emulator claims to complete successfully, but the app never opens and does not appear in the app list inside the emulator. So I have no way of actually testing it on the emulator either.
Would really appreciate some assistance.
EDIT 2:
After some further tinkering I've discovered my issue can be more specifically described as ADB hangs (freezes) when I attempt to talk to my device. I've determined this because adb shell, adb install, and adb push all fail the same way as described above. No error, just finite waiting.
adb logcat, adb devices, and other read functions work perfectly fine until one of the aforementioned write functions hangs in which case I need to do a adb kill-server or TASKKILL to get adb logcat working again.
Not sure if this added information helps, but there you go. The last thing I haven't yet tried is to do a factory reset on my phone as suggested by this fellow. If I can't find a solution soon I will back up my data as best I can and attempt this...
Please save me before this becomes my last option!
In case this helps others I had a problem with similar symptoms. ADB install -r "apk path" would hang indefinitely.
I troubleshooted a myriad of things and identified that it was my USB cable length.
I have an USB extender cable as that I plug my devices into. The combined length of my device's cable and the USB extender cable caused this issue. Removing the extension cable fix the issue and eventually I replaced my USB extender cable with a shorter extension cable for the final solution.
The issues seems to resolve itself randomly. As others suggested, an arbitrary combination of ADB kill-server, restarting the device, and re-installing SDKs seems to alleviate the problem (even if only for a couple pushes).
I still have no idea what causes this hanging and, though superstitiously believe the arbitrary combination described above fixes it, am unsure how to permanently resolve it.
To future people reading this, until a solid explanation is given my only advice is to square away an hour or so to restart / rebuild your dev environment... and make sure you buy a durable stress ball.
Shot in the dark here, but some more things to try:
Are you on a work PC or something? Make sure you have USB write permissions. Also, try different USB ports and cables. You have the latest USB driver for your devices right?
Try updating the SDK tools. Or maybe something got corrupted and a re-install might do the trick.
You have free space on your devices right?
Unknown sources is checked on both devices?
What version of Android are you targeting?
Do try restart the device like other suggested. From my experience, kill the adb process, then run the cordova run command helps magically sometimes.
In my case adb seemed to hang, but in fact the data transfer from Mac to emulator was really slow:
$ adb push platforms/android/build/outputs/apk/android-debug.apk /data/local/tmp/
150 KB/s (15587200 bytes in 101.223s)
It's a lot faster on USB connected real device. Don't know why...
Had the same (original) issue (with cordova / testing on an old device) ie. hang during install.
Tried running adb install directly from cmd line ...
adb [-s <deviceID>] install <apk>
...and same issue so not cordova specific....
Opened android device monitor (ADM) ...
..sdk\tools>monitor
..and ran install from cmd line again and saw logcat message saying package was sdk 16 / device was 15...doh!
So went back to AndroidManifest.xml and changed android:minSdkVersion to 15 and all back to normal again - install worked fine.
( Issue arose because I had installed something else which had changed the minSdkVersion and then removed the something else and never reset the minSdkVersion )
So, possibly device sdk / android version is too low for your build. If not, a look at the ADM logcat output as you initiate the install from the command line might indicate what the issue is.
Unplugging and plugging device again usually helps.
I'm planning to build an automated system for deploying an Android build to various devices, in order to make development for multiple platforms a bit more comfortable. Is there a way to get the sdk version of a connected device through android shell or adb?
There will be a computer to which several test devices is connected, and I was planning to write a script which will fetch the correct build for each of those from a build-server, install the different apks on their respective devices, launch them and collect log info, to be made available through some other program whose specifications are beside the point.
The point is that I need to know the sdk version each device is running to install the correct apk, and I was hoping I could get this through adb, but I can't seem to find a way to access it short of building a tiny app, compatible with all versions, whose sole purpose would be to output android.os.Build.VERSION.SDK or similar somewhere my script could read it.
you can use this command:
adb shell grep ro.build.version.sdk= system/build.prop
It will output something like this:
ro.build.version.sdk=10
adb shell getprop ro.build.version.sdk
Note #Tim: this works even on phones without grep support on all host OS :-). (i.e. on old phones where toolbox does not support grep you you need to have busybox on your phone).
I also discovered a way to get the exact version of Android e.g. 4.2.2 based on the following web article http://xayon.net/looking-for-android-version-with-adb/ You need to be using a unix-like operating system - Linux and Mac OSX are fine, and windows users can use cygwin or equivalent.
At a command line:
echo version=$(adb shell getprop |awk -F":" '/build.version.release/ { print $2 }')|tr -d '[]'
Here is the result for my Nexus 4:
version= 4.2.2
I think you can by accessing the device with adb shell - change directories to position you at system and do a cat of build.prop. Here you will find for instance, ro.build.description=google_sdk-eng 2.2, ro.build.version.release=2.2 etc