You don’t have to be a developer to be able to automate an Android App, but having a basic understanding of the way an App works certainly helps. This is the first post in a small series aimed at giving a high level explanation of the way Android Apps are constructed.
This first post is about Activities, the other posts will cover what Views, IDs, RecyclerViews and Intents are.
An activity is a Class that can act as an entry point to an application and that can invoke other Activities.
So what does this mean?
The mobile-app experience differs from its desktop counterpart in that a user’s interaction with the app doesn’t always begin in the same place. Instead, the user journey often begins non-deterministically. For instance, if you open an email app from your home screen, you might see a list of emails. By contrast, if you click an email link in a browser that then launches your email app, you might go directly to the email app’s screen for composing an email.
The Activity class is designed to facilitate this paradigm. Instead of only being accessible as one whole thing, an App contains one or more Activities (developers decide which of those Activities are publicly accessible). When one app invokes another, the calling app invokes a (public) Activity in the other app, rather than the app as an atomic whole. In this way, the activity serves as the entry point for a user’s interaction with the app.
- Android OS
- App X
Has a button that takes you to the ‘compose email screen’ in your mail app
- Mail app
- ‘MainActivity’ of the App. If you start the app, this is the activity that automatically gets started. It loads your inbox and has a few buttons, for example a ‘compose email’ button.
- ‘ComposeEmailActivity’. This activity allows you to compose an email. If you press the ‘compose email’ button in the MainActivity, this gets started. It’s also directly accessible by activities from other apps. This means that this activity can also be invoked from App/Activity X in this example.
Activities and Testing
It’s not just activities that can invoke other activities, we can do the same while testing manually, or when automating.
Being able to launch specific (public) activities enables us to better isolate those parts of the app we’d like to test, and even launch Activities in specific states that might be hard to create when following the regular app flow.
Launching a Specific Activity Using ADB
If your emulator is running (or you physical device is connected) and your app has been installed, you can use the ‘adb shell am start -n ‘ command to launch a specific activity.
You do need to have ADB installed to try this: https://developer.android.com/studio/command-line/adb
In the example below I’m launching the MainActivity from my MailOrderCoffeeshop app:
adb shell am start -n nl.testchamber.mailordercoffeeshop/.MainActivity
For more information on the different parameters you can use to launch an Activity see the official docs:
The second part of this series: Views
The third part of this series: IDs
Official Android documentation about Activities: https://developer.android.com/guide/components/activities.html