AWS Device Farm can not get the correct app activity for Android app to launch app using Appium



I'm trying to run a small test for an Android app using Appium and TestNG on AWS device farm and I'm facing this problem. As recommendation from AWS, I just kept the desired capabilities empty like this and I could run the test successfully on my local machine

    public void setUpAppium() throws MalformedURLException {
        final String URL_STRING = "";
        URL url = new URL(URL_STRING);
        DesiredCapabilities capabilities = new DesiredCapabilities();
        driver = new AndroidDriver<MobileElement>(url, capabilities);
        driver.manage().timeouts().implicitlyWait(35, TimeUnit.SECONDS);

Then I followed all the steps in the instruction: uploaded the apk, zip file, etc. to AWS Device farm. And then when I ran the test on AWS, I got this error:

Cannot start the '' application. Visit for troubleshooting. Original error: Activity name '' used to start the app doesn't exist or cannot be launched

As the error message, AWS tried to launch the activity "" which is kind of weird because when I used the command "adb shell dumpsys window | grep -E 'mCurrentFocus'" to check the app activity then I got this result "com.simplemobiletools.calculator.activities.MainActivity" and I don't know where AWS got that activity. So I guessed because of the wrong activity, appium couldn't start my app and the test couldn't be run on the device farm. I also checked with other apps and I saw the same problem. App activity that I used the adb shell command to check is always different to the app activity AWS got. AWS seems to tend to add the word "Splash" into the app activity and I don't know what it meant I tried this solution from this link "" by adding appActivity and appWaitActivity to the yaml file

- echo "Start appium server"
      - >-
        appium --log-timestamp
        --default-capabilities "{\"deviceName\": \"$DEVICEFARM_DEVICE_NAME\", \"platformName\":\"$DEVICEFARM_DEVICE_PLATFORM_NAME\",
        \"app\":\"$DEVICEFARM_APP_PATH\", \"udid\":\"$DEVICEFARM_DEVICE_UDID\", \"platformVersion\":\"$DEVICEFARM_DEVICE_OS_VERSION\",
        >> $DEVICEFARM_LOG_DIR/appiumlog.txt 2>&1 &

      - >-

but it didn't work either. Now I get another error "Waiting for appium server to start. Sleeping for 1 second". I tried to find any solution but couldn't find anything Please help me resolve this issue, I really appreciate your help!

asked a year ago126 views
1 Answer

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.

  1. 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.
  2. 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 "". 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"


  1. Set the desired capability "appWaitActivity" in yaml file to ""
  2. Set the desired capability "appActivity" to the splash Activity ""
  3. 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.
  4. Set desired capability "appPackage" to ""
  5. 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.

answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions