![]() ![]() Users/Shared/Jenkins/android-sdk/platform-tools/adb This basically just runs adb start-server from the user launch daemon to avoid Jenkins from owning it. Here's an example: ~/Library/LaunchAgents/. plist file to trigger the adb daemon on bootup. In theory, a better way would be to make. This is an annoying step to have to perform every time your machine restarts, and if anyone closes that command window you will revert to the previous problem. You can tell if it is the parent process by whether this message is shown after running blah$ adb devices One way to fix this, is to just run "adb devices" from a shell that gets left open on the CI machine. This results in a cycle of starting and stopping the adb daemon, but what you want is for it to just stay up indefinitely. If Jenkins kicks off the adb daemon with an "adb devices" call (for example), then the adb daemon will be owned by some short-lived Jenkins shell, and when that shell finishes executing and closes, the adb daemon will be cleaned up, until it is started back up automatically by another adb call. The causes problems because Jenkins jobs are associated with shells that come in and out of existence. ![]() I believe the problem is that you are allowing Jenkins to start the adb server. We had some similiar problems with our Continuous Integration environment with Android devices from an OSX machine (also using for both iOS and Android). Be it a few commands before each Jenkins job, patching ADB or any other black magic trick. So at this point I'm all ears for a solution that would allow us consistently running Android on our CI server. My lurking of the ADB source code was a very, very long shot. It's not that you can mount/unmount the device, but to be honest I'm not even sure where the problem is, I don't know enough about low level USB protocols, let alone for Macs. I've attempted a few rather lame commands to "refresh" all USB activity, but I've gone nowhere. Indeed, running a command like system_profiler SPUSBDataType successfully finds the device, including the serial number that ADB reports when working correctly. While approaching the problem I thought that if at the OS level the device is found, that's at least a start. Sadly, all I've found on the internet are variations of "unplug and replug the device", which is obviously not a solution for us (we can't spare a human being to sit by the CI server to unplug and replug devices before each build).Īs a bit of background, we use Jenkins on a Mac, since it runs our CI for iOS too. We are setting up a continuous integration server for our Android development and we've quickly run into ADB's waiting for device issue.įor the record, we've already tried a lot of combinations of adb kill-server, adb start-server, adb devices, etc. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |