Latest Xamarin starts adb.exe, when earlier version did not. Causing CI issue. RRS feed

  • Question

  • User139501 posted

    Quick background, we have been using Xamarin for a while (I know it's dated) and I'm trying to get our developers moved up to the latest ( Works great locally, but I installed it on our build server that uses CruiseControl.net (to be replaced some day....). We have a few tasks that run as we build Android along with other platforms. The issue is with the latest Xamarin, it seems that msbuild of the android release from the command line will start the 'adb.exe' process, and it will never kill the process. The problem with this is that the CCNet task is waiting for the adb.exe process to stop as it was started from the msbuild task. Using Xamarin it does NOT start adb.exe. Our build hangs until it reaches an hour timeout and fails.

    Any ideas as to why it would start adb.exe when command line building an android release build? I bumped up msbuild to verbose, and searched for adb. I see this quite a bit (I changed a few names of folders for posting here):

    Target "_GetPrimaryCpuAbi: (TargetId:12191)" in file "C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.Debugging.targets" from project "C:\OurBuildFolderName\Build\src\SomeProject\SpeechManager\SpeechManager.and.csproj" (target "_CheckInstantRunCondition" depends on it): Using "GetPrimaryCpuAbi" task from assembly "C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Build.Debugging.Tasks.dll". Task "GetPrimaryCpuAbi" (TaskId:18223) Task Parameter:ToolPath=C:\Users\UserName\AppData\Local\Android\android-sdk\platform-tools\ (TaskId:18223) Task Parameter:AndroidPackage=PNet.SpeechManager (TaskId:18223) Task Parameter:OnMultipleTargetsDetected=ignore (TaskId:18223) Adb Task: (TaskId:18223) ToolPath: C:\Users\UserName\AppData\Local\Android\android-sdk\platform-tools\ (TaskId:18223) ToolExe: adb.exe (TaskId:18223) OnMultipleTargetsDetected: ignore (TaskId:18223) C:\Users\autobuild\AppData\Local\Android\android-sdk\platform-tools\adb.exe devices (TaskId:18223) FoundDevices: False (TaskId:18223) Output Property: _DeviceSdkVersion=0 (TaskId:18223) Done executing task "GetPrimaryCpuAbi". (TaskId:18223)

    If it's intended behavior to start this process and not stop it upon a successful build, then I guess we'll have to stay on our older Xamarin and start working on a better build server (Jenkins!).


    Wednesday, February 22, 2017 3:13 PM

All replies

  • User139501 posted

    I found a temporary fix by running a batch to restart the adb server before a build, but still wondering why it's necessary for it to be running during an Android build on the latest Xamarin.

    Wednesday, February 22, 2017 5:42 PM
  • User12817 posted

    Hey again Justin.

    This is quite an interesting bug.

    When you do use the Xamarin.Android tooling, there are many MSBuild tasks that can at the end of the day invoke adb.exe. This one is saying that within the tooling for debugging, it is using adb.exe within the GetPrimaryCpuAbi Task. In fact the reason why is because this Task needs to figure out your connected device to figure out the primary ABI(aka your chipset)

    One thing I'd like you to do on your CC build is to run MSBuildStructuredLog on it:



    This should help determine why this Task is invoked in the first place

    I see that this is Target runs on the DefineInstantRunBuildTargetAbis, CheckInstantRunCondition and many more. In your case it's CheckInstantRunCondition

    I highly doubt you are using InstantRun in any way, so I have a feeling these targets shouldn't run in the first place...

    Wednesday, February 22, 2017 5:50 PM
  • User139501 posted

    Thanks for the quick response.

    What exactly is instant run? I see that Android Studio has instant run, but sounds like Xamarin does not. Is there something we could have done to cause instant run? I see this in most of our project builds. Looks like there's a sequence of targets with dependencies that eventually call adb.exe here.

    Wednesday, February 22, 2017 7:24 PM
  • User12817 posted


    Can you please expand all of the DependsOnTargets from the Target GetPrimaryCpuAbi up to _SetupApplicationJavaClass? This will help me figure out what's the culprit here. I believe it might be a custom multidex step that might invoke into it or along those lines! However visually I cannot see what's going on.

    My suspicion is that _SetupApplicationJavaClass depends on _BeforeSetupApplicationJavaClass.

    _BeforeSetupApplicationJavaClass thus calls _SetupInstantRun.

    This of course makes no sense from your point of view because you haven't opted into Instant Run as it's not available. I think overall this is looking like a bug on our end. I will have to file a bug after I can visually confirm my theory.

    Wednesday, February 22, 2017 7:34 PM
  • User139501 posted

    Here's with the dependsontargets open. Let me know if you want me to send you this log privately for more troubleshooting! Thanks.

    Wednesday, February 22, 2017 7:47 PM
  • User12817 posted

    Hi Justin,

    I went ahead and reported a bug on this issue:


    One thing I noticed is that it might be possible to avoid the adb.exe if there's no device connected to a computer. However the task will still run, so it may or may not still invoke the adb.exe. Either way, there should be more about this shortly when a framework engineer can respond to the bug report.

    Thanks for reporting the issue!

    Wednesday, February 22, 2017 8:52 PM
  • User139501 posted

    I ran this locally on my PC and had an Android attached, but on our build server VM we don't have any devices attached. That's why this log shows a device attached. Without a device it still shows the same steps.

    Thanks again!

    Wednesday, February 22, 2017 10:33 PM
  • User177766 posted

    We are seeing the same issue on all Android builds on AppVeyor.

    Is there any workaround available?

    Friday, February 24, 2017 6:55 PM
  • User12817 posted

    @FeodorFitsner Right now there is some investigation happening regarding this regression. I believe one work around that you and @JustinWojciechowski might be able to use is to remove adb from your system's PATH. If you don't have access to that from AppVeyor, it will most likely need to be fixed on our end so the targets do not invoke adb at all.

    Friday, February 24, 2017 6:57 PM
  • User177766 posted

    OK, thanks - let me try that.

    Friday, February 24, 2017 7:01 PM
  • User177766 posted

    Unfortunately, with adb.exe removed the build fails like this: https://ci.appveyor.com/project/FeodorFitsner/android-app-test/build/1.0.15#L29

    Friday, February 24, 2017 7:25 PM
  • User139501 posted

    I was going to mention the PATH on our build server didn't have the bin defined for adb.exe and it was still launching it through msbuild/xamarin. I believe it's because we launch msbuild through visual studio command prompt, and has the adb path already defined.

    Friday, February 24, 2017 7:33 PM
  • User177766 posted

    OK, looks like disabling adb.exe task in _GetPrimaryCpuAbi target is a workaround: https://github.com/appveyor/ci/blob/master/scripts/fix-xamarin-4-2-2-11.ps1

    Friday, February 24, 2017 8:07 PM
  • User48 posted

    This issue should have been fixed in Cycle 9/XamarinVS 4.3.x, currently in the stable channel.

    Monday, March 13, 2017 7:26 PM