Bug 10677 - Xamarin studio not finding running emulator
Summary: Xamarin studio not finding running emulator
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Android Add-in ()
Version: 4.0
Hardware: PC Windows
: Normal normal
Target Milestone: ---
Assignee: Mikayla Hutchinson [MSFT]
URL:
Depends on:
Blocks:
 
Reported: 2013-02-26 04:15 UTC by softlion
Modified: 2014-05-22 18:52 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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 or GitHub 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.

Related Links:
Status:
RESOLVED FIXED

Description softlion 2013-02-26 04:15:31 UTC
Description of Problem:
When starting debugging, xamarin studio asks for a device, but they are all grayed out.

Steps to reproduce the problem:
1. Open an x86 emulator image using the AVD manager without administrator elevated prompt
2. Run Xamarin Studio without administrator elevated prompt

Actual Results:
All devices are grayed

Expected Results:
The running simulator device should not be grayed

How often does this happen? 
Always

Additional Information:

Xamarin Studio
Version 4.0 (build 2003)
Runtime:
	Microsoft .NET 4.0.30319.18034
	GTK 2.24.13
	GTK# (2.12.0.0)
Comment 1 Mikayla Hutchinson [MSFT] 2013-02-28 13:44:01 UTC
The is because we start the device with the following arguments:
-partition-size 512 
-prop monodroid.avdname=$NAME
Then only allow connecting to devices that have the avdname property set.

The reason for the first argument is to make MfA apps run properly on the emulator. I'm not sure if it's still necessary, but it was when this was implemented a couple of years ago. Perhaps there's some way were could detect the partition size of running emulators.

The second argument allows us to associate emulators with the actual AVD - there's no way to detect this from the running emulator AFAICT.

The reason you can't connect to the emulator is that we use the existence of the monodroid.avdname property to figure out whether the emulator was launched with the partition-size argument.

Jon, do you know whether it's possible to detect the partition size from a running emulator or whether this check is even necessary any more?
Comment 2 Jonathan Pryor 2013-02-28 13:55:00 UTC
>  Perhaps there's some way were could detect the partition size of running emulators.

`adb shell df | grep data`

The problem was that if -partition-size wasn't provided, the /data partition was 64MB in size, which isn't really large enough to do anything interesting. I haven't tested recently to see if this is still the case, but I see no reason for Google to have changed the default either.
Comment 3 Jonathan Pryor 2013-02-28 13:56:18 UTC
Also, iirc we had some `df` parsing code to check for disk free space, and there were a number of "bugs" in that code because various differing Android targets provided different output formats for `df`. (Fragmentation? Yeah, we've heard of it...)

So if you implement support for checking the disk free space, keep that in mind: you'll need to support a variety of output formats.
Comment 4 Mikayla Hutchinson [MSFT] 2013-02-28 15:44:47 UTC
Hm. Not sure what the solution is.

I assume there's less fragmentation across emulators that there is across actual devices, so DF parsing code might be acceptable. Or maybe we could dispaly a warning icon beside "unknown" emulators instead of disallowing them completely.
Comment 5 Mikayla Hutchinson [MSFT] 2014-05-22 18:49:57 UTC
This limitation was removed by https://github.com/xamarin/androidtools/commit/e8aed3eafd72c6bbebd8a1ca1bbf3055a83a44be which uses a fallback to find the name for emulators that were not started by XS.
Comment 6 Mikayla Hutchinson [MSFT] 2014-05-22 18:52:38 UTC
Since that fix was made a year ago, and the possible issue of users running into problems with too-small emulator partitions never came up, I don't think we need to worry about parsing df to provide a warning icon.