Native Android Applications: Testing of “Activity” class

by TestFort News Editor on 09/20/2018

When testing native Android applications, it is important to have the understanding of Android system components. Knowing how the system works at least at a basic level, testers can expand Android app testing abilities as well. It allows them to go through scenarios related to the operation of the application components and makes the process more reliable and efficient.

In this article we will focus on the “Activity” class and explain why it is important for testers to clearly understand how it works.

What is “Activity” in Android native apps?

Activity is an Android native apps‘ class that displays an interactive screen with the help of which users can perform any action. This way, activities can be perceived as screens which display UI-elements. In general, native Android application includes one activity, but sometimes, there are two or several activities, where one is selected as the principal, like the start screen that the user sees after the application is launched. Then, each activity can also launch another activity (screen) to perform various actions.

When new activity starts, the previous activity stops or pauses. The system saves it in the “transition back stack”. New activity is also added to stack and becomes visible to user. The key principle of the “transition back stack” is LIFO that works on the principle “last in, first out”. So after the user has completed the current operation and pressed the “Back” button, the current activity will be removed from the stack, destroyed, and the previous activity will be resumed.

The life cycle of activity can be represented by the following scheme:

Activity life cycle

Android native apps‘ “Activity” life cycle in detail

The main app’s activity is created and loaded when we run the application for the first time. This activity then goes into the “Resumed” state. In this state, the activity is performed on the screen and is available for interaction with the user.

When we move from the first screen to the second one, the second activity’s screen is created and launched and goes into the “Resumed” state now, so the screen is visible and active to users. The activity of the first screen goes into the “Stopped” state and is not visible to the user, while all operations are performed in the background.

When we return from the second screen to the first one, the first activity doesn’t need to be re-created. It is loaded from the memory, if it wasn’t destroyed by the system, and goes into the “Resumed” state. The second activity is stopped and destroyed, as it is removed from the transition stack.

When the activity is visible but the user cannot interact with it due to the loss of the focus, it goes into the “Paused” state. A good example is a screen pop-up. We see the screen but we cannot interact with it until we close the pop-up.

Activities in the “Stopped” state can be destroyed by the system in case of a memory shortage.

Activities in the “Paused” state can be destroyed by the system in the case of a critical memory shortage.

When the activities are liquidated, their state changes to “Destroyed”.

When the app is folded (runs in the background), for example, after clicking the “Home” button—the activity stops.

When you exit the application with the “Back” button—the activity is automatically destroyed and recreated next time you start this application.

Each time you rotate the screen, the activity passes through the full cycle of destruction and re-creation.

Starting with Android 7, in multi-window mode, active application which user is currently interacts with—is in the “Resumed” state and all other launched applications are automatically set to the “Paused” state.

Why DO engineers need to know this for testing apps on Android?

The major amount of errors occurs during the return of activity from the “Stopped” state and activity re-creation. It is clear now why such cases as screen rotation, background/foreground—are relevant and important for testing apps on Android. The consequence of an incorrect activity re-creation can be the crash. The other type of inconvenience like loss of data in input fields occurs during the incorrect retrieval from the “Stopped” state, for instance, when the application is returned from the background to the active state.

Understanding what are activities and their life cycle allows testers to assume which test cases are necessary for testing and what are the weakest parts of native Android applications. As a result, it can improve product quality and coverage.

However, even good understanding of activities’ life cycles and covering them with test cases doesn’t fully protect the application from unexpected activities’ suspension when it shouldn’t be happening.

As mentioned above, in case of a memory shortage, the operating system can complete the activity process, which is in the “Stopped” and “Paused” states, if a new one with a higher priority appears. This usually happens in devices with insufficient processing power and/or outdated hardware. It is difficult to predict when it can potentially occur, hence hard to check all the correct activity recovery. On device with a powerful hardware it can be difficult to reproduce such a situation. In such cases, QA engineer can use the “Do not keep activities” setting.

It emulates the situation when there’s a memory shortage and the system destroys all background activities, leaving only the active one, which is in the “Resumed” state. This means activities will be recreated each time there’s a transition between the screens. Therefore, while testing apps on Android, engineers can check whether they are ready for unexpected activity suspensions.

This option can have some drawbacks though. Due to the constant re-creation of activities when navigating the screens:

the device works much slower;
the battery charge drops much faster.

Testers who use “Do not keep activities” option should be ready for unstable performance of a poorly-developed native Android application. Since mobile devices get more powerful with each day—unexpected suspension of activities is not so widespread. Still, it’s better to warn the client about the possible consequences in advance.

TestFort is an experienced team of engineers who are working with the products of all complexity levels. We are not afraid to be challenged by security testing of Android apps, desktop software, and web application testing. Having 250+ physical devices at our hand, and a team of 160+ QA engineers––we are ready to find bugs and errors in your software. Contact us to get the job done.

We Work With

Having one outside team deal with every aspect of quality assurance on your software project saves you time and money on creating an in-house QA department. We have dedicated testing engineers with years of experience, and here is what they can help you with.

Software is everywhere around us, and it’s essential for your testing team to be familiar with all the various types and platforms software can come with. In 21+ years, our QA team has tested every type of software there is, and here are some of their specialties.

There are dozens of different types of testing, but it takes a team of experts to know which ones are relevant to your software project and how to include them in the testing strategy the right way. These are just some of the testing types our QA engineers excel in.

The success of a software project depends, among other things, on whether it’s the right fit for the industry it’s in. And that is true not just for the development stage, but also for QA. Different industry have different software requirements, and our team knows all about them.

Full-Cycle Services

By Platform

By Type

Industries