Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
When attempting to deploy to a Android 4.4 device/emulator, the deployment hangs with "Waiting for device..."
However, this same deployment from XS completes successfully.
Android Debug Log from "waiting for device" deployment attached.
Microsoft Visual Studio Ultimate 2013
Version 12.0.30110.00 Update 1
Microsoft .NET Framework
Installed Version: Ultimate
Xamarin.Android 4.12.01000 (0deb0164)
Visual Studio plugin to enable development for Xamarin.Android.
We are not sure, what is meant by Case #...... mentioned in Comment#1.
However, on the basis of description in the bug, I have checked this issue on below environments:
Microsoft Visual Studio Professional 2013
Version 12.0.21005.1 REL
Microsoft .NET Framework
I have deployed android sample application successfully on to a Android 4.4.2 API 19 emulator. Refer screen cast: http://screencast.com/t/gaRAP8Ive
Also I check on VS 2012
While typing here to confirm I have the same problem, the emulator comes alive after ca 12 minutes of 'waiting for device'. So while I thought there was indeed a bug, the app starts showing after ca 10 to 15 minutes. So to the normal user it may appear that there is indeed a bug.
So my suggestion, start again and wait.....
I can confirm this bug on version 4.12.03003 when trying to debug on a android 4.3 device with VS 2013. Anything you need to fix this bug I'd like to provide
Looks like we have some additional information, moving back to NEW.
I have the same issue, forever "waiting for device".
It deploys with no problem to 4.1.1.
I tried with Android SDK Emulator and Genymotion.
Xamarin.Android 4.12.02001 (a1e3982a)
I have managed to replicate this issue using a genymotion API 19 emulator image connected via dab over wifi. This works previously with a API 16 image.
The issue is the command we use to check if the device is ready is returning additional information
WARNING: linker: libart.so has text relocations. This is wasting memory and is a security risk. Please fix.
The warning lines need to be stripped out (or the code modified to handle additional information)
This seems to be a side effect of the ART runtime.
Hello, I hit the same issue with an Intel Nexus 5 emulator, Android 4.4.2 (Windows 7 64-bit, Visual Studio 2013). I hope it can be fixed soon.
problem resolved! In which version we can get this fix?
How is it solved?
I'm here with my Nexus 5, Android version 4.4.2 with Dalvik Runtime and it stays indefinitely waiting for device...
Is this fix included in the Xamarin 3.0?
I can confirm it is also a problem in Android 4.4.4 (Paranoid Android 4.41), running Dalvik VM.
I am having this problem trying to deploy to a Huawei868C.
6>Waiting for device..
and then nothing happens.
If you're using the Xposed Framework on your device, try uninstalling it through the app (the framework, not the app itself). I had this problem on my Nexus 7 until I uninstalled the framework.
I got the same problem 'Waiting for device'. I managed to get past it by setting the Emulators SD Card size to a minimum of 512mb (as the whole of the Mono framework is preloaded on the device - http://docs.xamarin.com/guides/android/advanced_topics/application_package_sizes).
As per the advice here: http://forums.xamarin.com/discussion/comment/10251/#Comment_10251
Hello dean.ellis, You have made the status fixed but the problem seems to be still exist