#Mac android emulator doesn't boot serial#
Each android device has its own serial number, which can be viewed by the command ‘adb devices’, with an optional ‘-l’ parameter also printing out extra useful information such as the model. The Android SDK has a program called ‘ Android Debug Bridge‘, which is used for interaction between a system and a connected Android device. I can now execute the launching of each emulator as a build step inside their respective build jobs. So now I can launch the Galaxy S4 emulator with one command: /Applications/Genymotion.app/Contents/MacOS/player –-vm-name a20cf63e-9b75-41f9-936f-7887b002de62
![mac android emulator doesn mac android emulator doesn](https://i.stack.imgur.com/trtTz.png)
I did this with VirtualBox’s own VboxManage executable, which is in the VirtualBox installation directory: /Applications/VirtualBox.app/Contents/MacOS/VBoxManage list vms So I needed to find out the Virtual Machine IDs of each of my Genymotion devices. When specifying the device parameter, you can either use the device’s name as displayed in Genymotion, or you can use its associated VirtualBox ID. I used the IDs because they would always be constant for the installation of that emulator, while one could easily change the title of the device in Genymotion’s main window at any time. Genymotion uses VirtualBox behind the scenes. (This last number is 1, not 0, because the act of searching with grep creates a new process, and that process contains the string I’m grepping for! Grepception.) This means I can also kill the emulator task if it has frozen: player_grep = `ps aux | grep player.app/Contents/MacOS/player`
![mac android emulator doesn mac android emulator doesn](https://4.bp.blogspot.com/--JDGMpc-dhE/W0OUetzsGyI/AAAAAAAAFmQ/IVVQjR5YF_UQEhrmq21chrm9sGuvk-GCQCLcBGAs/w1200-h630-p-k-no-nu/amd_android_emulator.png)
I shut the emulator down with a ruby script just using the build machine’s process list. You can start an emulator with the ‘player’ command: /Applications/Genymotion.app/Contents/MacOS/player -vm-name Genymotion comes with its own shell as a separate program, which executes commands with the emulators including starting devices (but at first glance I couldn’t find a command to shut them down). I decided to find a way to launch each device every time a suite was due to run on it, and close it again when the tests were complete.
#Mac android emulator doesn't boot manual#
The emulators were left constantly for days, reinstalling the app and running test suite after test suite, and would always inevitably crash and require some manual rebooting. However, Genymotion is still viewed by the Android community (and us!) as the best emulator programs for Android, especially in terms of speed, so giving up Genymotion wouldn’t have been the correct solution here. Unfortunately, all Android emulators are sometimes prone to crashing if left running for a while. Some of the devices are real ones plugged into the build machine, while some are emulated using an Android emulator called Genymotion. We decided to test more on emulated devices than real ones due to problems with the physical devices losing wifi intermittently, running out of battery due to only being trickle-charged by the machine, and occasionally just losing connection to the machine (cables just add another point at which to fail!) Genymotion Emulator running VB underneath The first problem We have a separate build job for each device to give us visibility of test successes/failures on a per-device basis. The team’s TeamCity build agent kicks off functional tests on a variety of devices each time there is a merge into the develop branch of the Android repository.
![mac android emulator doesn mac android emulator doesn](https://www.technipages.com/wp-content/uploads/2017/08/Android-XX-header-1280x720.png)
![mac android emulator doesn mac android emulator doesn](https://i.ytimg.com/vi/IxYq1UAhZ84/maxresdefault.jpg)
The main problem I found myself solving with this setup was that the emulators would eventually crash if they were kept running. The team uses Git for version control of the code, and our build server is linked to activity on the repository and will automatically run jobs when certain events occur. In the JUST EAT Android team, we use a continuous integration system called TeamCity, which compiles and packages the app, installs it on our test devices, runs the tests on each one and then reports the result back to TeamCity.