Obtaining the current activity

Support
1

In our screen factory, we use the current activity to identify the screen we are on. Something like this:

  screen_name = appium.driver.current_activity

I notice, however, if we open notifications, we do not get “StatusBar”, but the activity of the screen underneath. In the past, I’ve used “adb shell dumpsys window windows |grep Current” with a regexp to find the current activity, but it looks like Appium is doing this some other way. Is there some other non-hackish way in appium to detect the current activity or notification screen? Can we update the way to we detect the current activity?

2

That’s exactly what appium does.

In my experience, relying on the value of the current activity is a fragile way to test. It’s better to look for known elements.

3

I’m not delighted at checking current activity, but checking the mFocusedApp is not returning the notification. Any thoughts on other ways to detect it? I hate the thought of looking for specific elements since Android plays fast and loose with element_ids.

4

I recommend reading what Google has to say on the subject.

The Espresso API encourages test authors to think in terms of what a user might do while interacting with the application - locating UI elements and interacting with them. At the same time, the framework prevents direct access to activities and views of the application because holding on to these objects and operating on them off the UI thread is a major source of test flakiness. Thus, you will not see methods like getView and getCurrentActivity in the Espresso API.
Google Code Archive - Long-term storage for Google Code Project Hosting.

If there’s some better way to parse the dumpsys output then you could open an issue on GitHub with the suggestion.

5

This goes down to the design philosophy of the test tool. Espresso expects that you are only testing the application, not how it interacts with the rest of the system. It’s one of the reasons we didn’t move from UIAutomator to Espresso when it became available. Android doesn’t do the greatest job of producing applications that are easy to test; e.g. using the same resource id to describe numerous different elements, not using consistent naming patterns, using bad names (app_size for the version number), using the same value for FocusedApp on different settings subscreens, or, my personal favorite, using bad names for activities, such as StatusBar for the notifications page.

Additionally, because we have to test many different vendors’ implementation of the android screens, relying on them to present the same objects is troublesome at best. At least if they’ve renamed the activity, I can maintain a list of activities that map to the notification screen. I am not so sanguine about my chances of success if I’m looking for resource ids, and I can’t check for text strings since I want to be able to test multiple languages.

What I’m curious about is why you don’t believe that using CurrentFocus is a robust method for detecting the activity. This is the first case I’ve found where CurrentFocus and FocusedApp do not match. I’m leaning towards requesting an interface from appium to get the CurrentFocus unless you have any other ideas that I’m missing.

I really appreciate your attention to my questions.

6

Exactly, which is why both uiautomator and espresso fail to provide a method to get the current activity.

I think it’s common for them to not match such as when the keyguard is up. It sounds like this is a bug in our getFocusedPackageAndActivity method. The regex should be updated to search for both mCurrentFocus and mFocusedApp. If mCurrentFocus is found then that’s the more accurate value. Sometimes mCurrentFocus is empty and then we’d fall back to mFocusedApp.

If you open an issue on GitHub then I don’t think it’ll be a problem to get this fixed.