Exceptions in Android Apps

Oh!!! App Crashed

Many app users while using the app, would expect the app to work faster and smoother. Users might feel unhappy for reasons like app loads slow, links/buttons don’t work as intended, more battery consumption, using large mobile data, UI distortion and many more. If the user feels bad for any of these, then how about the scenario where app exits automatically?

Yes, how the user would react if the app crashes frequently or randomly?  User might move out of the app (uninstall), if the app causes any of the such problems and if the problems are not fixed immediately.

App crash needs to be controlled as much as possible. The crash could be due to device specific/ OS specific, etc. Now it’s in the programmers/testers or concerned people hands to work on the various areas/scenarios to identify if the app exhibits any crash while using it.

What is an exception?

An exception (or exceptional event) is a problem that arises during the execution of a program. When an exception occurs the normal flow of the program is disrupted. As the result, the program/application terminates abnormally, which is not recommended. Therefore the exceptions are to be handled.

What is ANR’S (App Not Responding) in Android?

An ANR will occur if the process is running a thread (frequently observed on UI thread) and which is taking a long time to respond back. The ‘long time’ here is subjective to the device environment and condition.

Say the ‘long time’ is 5 seconds then the waiting thread which is not receiving the response back will wait.  This behaviour can be noticed with UI freeze generally where the user’s tap or gesture or actions are not getting any response. But a dialog box shows  ANR or app not responding.  Refer the image below.

After the ‘long time’ , if the thread still hasn’t recovered from that state, then an ANR will be shown depicting that app is not responding and asks the user to wait or close the application. Based on the user’s action, the application will exit or retrieved to the expected state.

This is a case to study how the CPU is being utilised by the app.  Thus, it also infers about the CPU utilisation by app’s process.

Why logs?

Viewing logs help tester/programmer to know the potential root causes of the crash. It is also a supporting technical evidence for the testers to advocate and report about the crash.

The log is not only useful to know about the crash information. Also we can get more information about the app activities like — how the app responds based on user interaction; device specific information; and other relevant things.

As a practising Software Tester, testing the mobile apps, it is a useful practice to record the logs before starting the testing.

How to collect the logs in Android?

Prerequisites:

Check if the device is recognised by the system through USB.  Assumption is, the Android SDK is installed and configured.

If the device is not recognised, one of the troubleshooting path is as below.

• In the Android device, go to Settings → Developer Options
• Enable USB debugging
• Go back to terminal and check if the device is recognised now by entering below command
  • adb devices

Note: If this is not helping, explore on how to configure and setup the Android SDK and setting up the environment variable path for the Android SDK.

How to check this?

1. Open adt bundle
2. Go to platform tools
3. Open the command prompt
4. Enter the command “adb devices”
5. Check if the device details appears below that line.
6. If yes, then adb was recognised. If no, then install Adb driver manager
7. Check if the device name appears in the tool
8. If yes, click install. If no, then download the Usb drivers for that device model in your system. For example( search for Usb driver for moto g3) and download it.

An image below shows device was recognised.

Using DDMS to collect log

• In Android SDK Bundle folder go to folder /android-sdk/tools
• Open the ‘monitor.bat’ file
• Select the device (device ID) in DDMS in “Devices” panel.
• Notice the “Logcat” tab in bottom panel. The logs keep publishing here.  Refer the picture below.

Collecting logs via Command Prompt or Terminal

• Open the command prompt or terminal
• Give the path to platform tools
• Execute the command “adb devices”
• See if the device is recognised and authorised
• Then enter below command
  • “adb logcat -vtime >> path_where_tosave/log_file_name.txt
    • For example, adb logcat -vtime >> d:\sampleApp/sampleApp_01Jul2016.txt
• Or adb logcat > filename.txt ( file will be saved in platform tools folder)

Collecting logs via Android apps

The below mentioned Android apps can be downloaded from Google Play Store and used to collect the logs.

1. aLogrec
2. aLogcat

Note: By using the above mentioned apps, explore on how to use these apps to record and collect the logs.

How to identify crash information in logs?

An information related to crash will be recorded in the logs. If we are using the the appropriate log level in the command, then it helps us to collect them. Generally using ‘verbose’ level is good. So it collects the entire information, though the file size tends to grow and number of log lines keep growing.

If the crash was due to app process, then the information like app package name, app’s process id will be listed in the logs. In case if the crash was due to device condition, still the information will be recorded. Further we can learn how to fix and handle run time exception due to device condition or particular to device model on conducting the test investigation.

The screenshot provided below is a sample to show where/how to find a crash information.

Here in the log, we can search for  package name, pid and type of crash. Also searching for these words can help — “exception”, “fatal”, “kill”, “terminate” etc.

If the crash is  relevant to the specified process then we can share the crash log to the development team.

 Types of Crashes I came across so far:

I came across below mentioned run time exceptions frequently in Android apps which results in the app crash. Apart from these there are other run time exception as well.

1. java.lang.NullPointerException
2. java.lang.OutOfMemoryError
3. android.view.WindowManager$BadTokenException
4. java.lang.IllegalArgumentException (extends java.lang.RuntimeException)
5. android.database.sqlite.SQLiteException
6. Array index out of bound Exception
7. java.lang.NumberFormatException

More information about the above mentioned crashes will be shared in my next blog post.

Author :Himansha Tyagi (Exploratory Software Tester)

Email id : himansha.tyagi@moolya.com