Android basics 18: Android interruptions and Testing

The interruption events provided by Android phones are different from those provided by mobile phones in the past. Of course, there are also many similar mechanisms. Therefore, we needProgramStarting from the interruption mechanism, we can customize the interruption events of our system test cases.
We can customize an application, print all the inherited methods, and then use these to interrupt the experiment to call these interfaces. If developers cannot handle these interfaces, there may be problems to achieve coverage testing.
To do this test well, we need to be very familiar with the lifecycle of our team activity. I have already mentioned this in the previous article.

Interruption events are generally classified into basic system interruption events.
1. When the Home Key is returned to the home app, the application currently tested will be put in the Stop State in the background. Of course, if the developer changes the interface, we will also see different things.
2. Long press the Home Key to switch the application
3. Back key

4. Press the power key to bring up the shutdown window.

5. Press the power key to lock the screen and then press the power key to unlock the screen.

6. Change the mobile phone direction

7. Content Provider)

8. Access released (even) applications through the program history record, such as the Bluetooth transmitter, delete the APN, and edit it.

There is also an interaction interruptions:
1. (Voice/common) SMS/MMS
2. the pop-up alarm
3. Incoming call (answer/reject/establish)
4. Bluetooth pair request
5. Bluetooth File Sending and receiving request window

6. Low-Power Prompt window

7. low memory
8. Charger plugging
9. USB cable/headset/charger plugging
10. SD card plugging
11. Remove the battery

These will interrupt the lifecycle of the current activity, so if these can be included in our test cases (as many activity interfaces as possible should be checked, of course, it is impossible for every UI to check, however, key business points need to focus on testing these interruptions .)
In normal business processes, we will not check this, and our developers will do it themselves, so it is difficult to find more problems during the testing process. If these checks are added, our test coverage should be very comprehensive and proved to be very effective.