The old logic was completely broken.
The pkg must not be prepended to the activity. This is invalid.
shell am start -n
com.thehomedepot/com.thehomedepot..Foundation.Controller.SetServicesActivity
The activity must not have the first bit chopped off. This is invalid:
Foundation.Controller.SetServicesActivity
The correct command is adb shell am start -n
com.thehomedepot/.Foundation.Controller.SetServicesActivity
Notice there's no prepended activity and that the string after the / starts with
a "."
Fixes#782
One thing to keep in mind: iOS and Android treat dialogs differently. iOS "system" dialogs can be triggered from the application under test as well as from external sources (the system). However, Android treats dialogs as any other window. So, to make this work, the bootstrap app looks for windows with the package name of "com.android.systemui". These are dialogs that the system has instantiated, but not the app.
So, for example, if we had the same application written on both platforms, and they both had a login screen, and you click on the login button without putting in a username. On iOS, you would be notified if they used a standard system dialog, and you would not be notified on Android. However, if the system put up a low battery dialog, it would be detected on both systems.
So... The main reason for implementing this is to stop failing tests from unintentional dialogs appearing during an overnight test.
Updated call signiture to instruments.
adb shell am commands return immediately, not when they're finished. am
instrument will close the app once it completes. It's possible for instrument to
be running, the am start command is issued, then instrument finishes and closes
the app. Appium is now waiting for an activity that will never appear and the
tests fail.
The fix is to only start the app once reset has closed the app.
Fixes#662
Jonathan Lipps