at the moment, if the emulator.exe aborts when it is starting up the AVD image, TestyDroid is oblivious and keeps polling for the device until it hits it's timeout.
However we do capture the STD Error Out and here is an example of one scenario of the emulator aborting because there is an existing instance using the same port allready:
Standard error output from D:\android-sdk\tools\emulator.exe was:
WARNING: userdata image already in use, changes will not persist!
WARNING: cache image already in use, changes will not persist!
WARNING: SD Card image already in use: C:\Users\darrell.tunnell\.android\avd\Xamarin Android API 15.avd/sdcard.img
it seems too many emulator instances are running on this machine. Aborting
Now, the information written to STDERROROUT is ofcourse subject to change, but let's add an enhancement to TestyDroid:
If it detects anything being written to STDERROROUT written the "WARNING" prefix, we will throw an exception.
If it detects the word "Aborting" in the STDERROROUT we will throw an exception.
This way, if there are problems with the emulator.exe we can fail fast, based on analysis of STDERROROUT, rather than waiting until timeout.
at the moment, if the emulator.exe aborts when it is starting up the AVD image, TestyDroid is oblivious and keeps polling for the device until it hits it's timeout.
However we do capture the STD Error Out and here is an example of one scenario of the emulator aborting because there is an existing instance using the same port allready:
Now, the information written to STDERROROUT is ofcourse subject to change, but let's add an enhancement to TestyDroid:
If it detects anything being written to STDERROROUT written the "WARNING" prefix, we will throw an exception.
If it detects the word "Aborting" in the STDERROROUT we will throw an exception.
This way, if there are problems with the emulator.exe we can fail fast, based on analysis of STDERROROUT, rather than waiting until timeout.