1 Antwort
- Neueste
- Die meisten Stimmen
- Die meisten Kommentare
1
Thank you for sharing the details in such a nice manner. Let's start by clarifying some confusion around what AWS changes and does not change.
- AWS Device Farm does not change the binaries or the intended behavior of Appium server or client code when running in custom environment. The expectation is you should get the same result as you get locally when running an Appium based test.
- Device Farm is identifying the activity to launch based on what the app is returning in the Manifest file and what is passed in desired capabilities.
In this case, you want to wait for the MainActivity which is "com.simplemobiletools.notes.pro.activities.MainActivity". The SplashActivity is typically seen on a fresh install and launch of an app. In case of someone using Device Farm public devices, this is default behavior every time.
A simple way to list all the activities would be an adb command which is slightly different than the one you used: "adb shell dumpsys package | grep -i " + (enter package name) + " |grep Activity"
Suggestion:
- Set the desired capability "appWaitActivity" in yaml file to "com.simplemobiletools.notes.pro.activities.MainActivity"
- Set the desired capability "appActivity" to the splash Activity "com.simplemobiletools.notes.pro.activities.SplashActivity.Grey_black"
- As a precaution to eliminate any timing issue, I would also desired capability "appWaitDuration" to 10 secs. This will give it enough time to bypass the Splash screen.
- Set desired capability "appPackage" to "com.simplemobiletools.notes.pro"
- Check when you run a fresh install and launch of your app if you get the SplashActivity locally. I would expect to see the same results locally and on Device Farm for SplashActivity.
Hope this helps.
beantwortet vor 2 Jahren
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 2 Jahren