|Summary:||A numeric comparison was attempted on "$(_DeviceSdkVersion)" that evaluates to "" instead of a number, in condition "$(_DeviceSdkVersion) >= 21".|
|Product:||Android||Reporter:||Cody Beyer (MSFT) <cody.beyer>|
|Severity:||critical||CC:||abhishekk, brendan.zagaeski, dominic, leo.reading, mono-bugs+monodroid, parrjw, peter.collins, prchol, ron.jacobs|
|Target Milestone:||7.0 (C8)|
|Tags:||BZSRC7S1||Is this bug a regression?:||---|
|Last known good build:|
Description Cody Beyer (MSFT) 2016-06-25 03:45:01 UTC
Comment 3 Brendan Zagaeski (Xamarin Team, assistant) 2016-06-25 05:03:35 UTC
Based on the logs, the next thing I'd curious about would be, what happens if you run the following 2 commands in a `cmd.exe` command prompt immediately after you hit the error with the build: C:\Users\beyer\AppData\Local\Xamarin\MonoForAndroid\AndroidSDK\platform-tools\adb.exe -s 169.254.138.177:5555 shell getprop ro.build.version.sdk echo %ERRORLEVEL% The prediction would be that the first command would produce empty output or an error message, and the second command would return an error level of 1, matching up with the log output: > "adb.exe" exited with code 1. (As hinted at in one of the forum comments , the issue seems to be that `adb.exe` is not communicating successfully with the emulator at this step. Based on the forum comment, it sounds like one possible cause of that problem is if the emulator is using its own mismatched version of `adb`.)  http://forums.xamarin.com/discussion/comment/204507/#Comment_204507 ## Sample "good" results For comparison, if I run the corresponding 2 commands from the first test environment I'm looking at here , I get the following results: > C:\>C:\android-sdk\platform-tools\adb.exe -s 172.16.5.1:5555 shell getprop ro.build.version.sdk > 23 > > C:\>echo %ERRORLEVEL% > 0  Google x86 API 23 2-core hardware accelerated emulator running on OS X, deploying from Visual Studio in a Windows VM hosted on the same machine.
Comment 4 Cody Beyer (MSFT) 2016-06-25 18:43:55 UTC
Slightly different than expected. Upon deployment failing, it appears that ADB either disconnects, or never actually connects >C:\Users\beyer\Documents\Visual Studio 2015\Projects\uuidTest\uuidTest>adb -s >169.254.138.177:5555 shell getprop ro.build.version.sdk >error: device '169.254.138.177:5555' not found >C:\Users\beyer\Documents\Visual Studio 2015\Projects\uuidTest\uuidTest>echo %errorlevel% 1 However, after after this occurred, I connected ADB manually >C:\Users\beyer\Documents\Visual Studio 2015\Projects\uuidTest\uuidTest>adb connect >169.254.138.177 >connected to 169.254.138.177:5555 >C:\Users\beyer\Documents\Visual Studio 2015\Projects\uuidTest\uuidTest>adb -s >169.254.138.177:5555 shell getprop ro.build.version.sdk >19 from here, I attempted to deploy again and was able to deploy the app. Interestingly, if I run >adb devices while the build/deploy process underway, the following error is thrown. >adb server version (36) doesn't match this client (35); killing... >could not read ok from ADB Server >error: could not install *smartsocket* listener: cannot bind to 127.0.0.1:5037: Only one >usage of each socket address (protocol/network address/port) is normally permitted. >>(10048) >* failed to start daemon * >error: cannot connect to daemon Not sure if this is related in any way at this time, but it is persistent while it is deploying. Again, after the deployment failure, I am able to connect with >C:\Users\beyer\Documents\Visual Studio 2015\Projects\uuidTest\uuidTest>adb connect >169.254.138.177 and then deploy.
Comment 5 dean.ellis 2016-07-06 09:01:39 UTC
@Cody I cannot replicate this on a clean VS 2015 + VS Emulator installation. Looking at the thread on the forum it is more than likely the miss match adb client issue . Can you do a search on the failing PC to see how many copies of adb.exe you have. On my system I have one which is in c:\Program Files (x86)\Android\andorid-sdk\platform-tools\ We cannot control which adb we use. That setting is passed to us via the settings in Visual Studio. So if that is pointing to an outdated/incompatible version there isn't much we can do.  http://enblog.clock-up.jp/entry/2016/06/26/xamarin-android-device-sdk-version-error
Comment 6 Peter Collins 2016-07-06 18:45:27 UTC
My investigation appears to confirm Dean's (and others) comments about mismatching adb severs running simultaneously. I'm unable to reproduce this using various physical devices, an API 23 x86 google emulator, and an API 19 VS Emulator. I am however able to reproduce using an API 23 genymotion emulator, but _only_ when the following is true: > 1. I toggle the checkbox which tells Genymotion to use it's own SDK tools (instead of the path Xamarin knows about). > 2. Any such "custom tools" Genymotion emulator must be actively running. When the latter condition is true, deployment attempts to _any_ connected device will fail. At this point I have three adb.exe processes running, and any invocation of `adb` will fail due to a server mismatch. > adb server version (x) doesn't match this client (y); killing... @Cody did you by chance also have a genymotion emulator running in the background while trying to deploy to the VS emulator? If not, do you have multiple Android SDK installations? The VS emulator uses the 'Path' variable from the following registry key to determine which tools to use. > HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Android SDK Tools Does this key exist, and is it different from the path set in VS under `Tools -> Options -> Xamarin -> Android Settings -> Android SDK Location`? Presumably if the path in this key and the path in the IDE are pointing to mismatched versions of ADB this would also result in the same failure reported. If this is the case, I'm also not sure what can be done on the C7SR1 timeline outside of better communication/education around this possible failing scenario.  https://msdn.microsoft.com/en-us/library/mt228282.aspx#ADB
Comment 7 Cody Beyer (MSFT) 2016-07-06 20:43:56 UTC
Hey, I do not have genymotion installed, nor did I have any other emulators running. I do have two SDKs installed (Android Studio and Xamarin as separate SDKs). They are pointing to different locations. This brings up a scenario which we may want to trap, its not unheard of at all for two different Android SDKs to exist, and for there to be this mismatch. Would it be prudent to add some sort of messaging? I would not want to imply that users should check their registry, but if we can compare the two paths (whats in reg versus whats in Visual Studio) we may be able to print an error message that asks for the customer to update one of the other. Thanks!
Comment 9 email@example.com 2016-07-07 11:29:44 UTC
I have this same issue and my registry value matches my VS value for the location of the SDK. I did an update of visual studio and the issue started happening. I updated to VS 2015 update 3. Also, I don't use the emulators I always use a device.
Comment 10 dean.ellis 2016-07-07 14:31:16 UTC
@ron Can you give any more details on your system setup. How many versions of adb.exe are present on your system. Which devices are you seeing the issue on? If it fails on a device can you see if 'adb shell getprop ro.build.version.sdk' returns anything .
Comment 11 firstname.lastname@example.org 2016-07-08 13:42:28 UTC
I have three versions of build tools on my machine: 19.1.0 21.1.2 and 23.0.1. Where should I run that adb command? I tried it from the visual studio command and it did not recognize it, same result from a windows command. I get the same result on every device. I have tried a nexus 7 a Samsung S7 and a Samsung Note. All fail the same.
Comment 12 dean.ellis 2016-07-15 18:55:37 UTC
This was fixed in monodroid/cycle7/13cf91a and cp'd to cycle7sr1. Still needs to be revisited in cycle8. So I am changing the milestone.
Comment 13 dean.ellis 2016-07-26 09:04:04 UTC
On the latest master if we try to "Install" with Genymotion when its using its own adb we get the following message. "* failed to start daemon * error: cannot connect to daemon /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets: error : Tool exited with code: 1. Output: error: could not install *smartsocket* listener: Address already in use List of devices attached adb server version (32) doesn't match this client (36); killing... ADB server didn't ACK * failed to start daemon * error: cannot connect to daemon /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.Debugging.targets: error : Error executing task GetPrimaryCpuAbi: Failed to run adb. Arguments are: devices Build FAILED. " Which seems reasonable to me.
Comment 14 dean.ellis 2016-07-29 10:11:02 UTC
Fixed in monodroid/cycle8/8c464ed48d1d1ce3e7a49dd372f77fbe01f5d4a8 monodroid/master/a9432f62768a1ad66740ef49791b554cda02c68a
Comment 15 englishguy64 2016-08-01 14:04:46 UTC
Updated to Visual Studio 2015 Update 3 Latest patch A numeric comparison was attempted on "$(_DeviceSdkVersion)" that evaluates to "" instead of a number, in condition "$(_DeviceSdkVersion) >= Was not deploying. This happened on all of the sample solutions but other lots of trial and error some of them deployed This however did the trick A reboot of the Android Nexus 5 handset after disconnecting it from the PC. Reconnected to pc and then deployed OK after a successful clean and re-build has been done before disconnecting and re-booting.
Comment 16 Abhishek 2016-08-03 18:50:00 UTC
I checked this issue and able to reproduce this issue at my end: Xamarin.VisualStudio_220.127.116.11_34a92cd0c31b7d476cdf7f4bcb0c613564874734 Application Output: https://gist.githubusercontent.com/Abhishekk360/ce7a161f77b1190d10bc53417770b321/raw/e8a535d3780c8bd9c8684f5046c1c9854c1e65b0/Build%2520Output To verify this issue I have checked this issue with XVS C8 and master. Xamarin.VisualStudio_18.104.22.16895/ea75daf Xamarin.VisualStudio_22.214.171.1246/60a7764 Screencast C8 XVS: http://www.screencast.com/t/xRXLgsJ7vd Application Output: https://gist.github.com/AkhileshKumar01/c08899c0182ecf8b0f73f11f54412416 Screencast Master XVS: http://www.screencast.com/t/i15Nj1r6Ql Application Output: https://gist.github.com/AkhileshKumar01/bb41c143a3240d540dc9cf3bdd04acfd Hence closing this issue. Thanks!