Imagine a scenario in which a user installs a mobile application. Due to high expectations, the application is frequently used, perhaps several times in the One days of the previous weeks. The data created by the application and the effort that the user puts into the application are accumulating. Then, suddenly, the application crashes. The user's data is now corrupted or missing. Although the application has not been updated for several days, these issues remain unresolved. The user gives the app a one-star rating and critical comments, and then abandons the application. Even if a fix is provided at a later point in time, it is not possible for the user to return to use the application.
As an application vendor, you spent months designing and developing the application, then testing it for several weeks before submitting it to the store. So far, the comments have been positive. Many one-star evaluations may be the most important factor in discouraging potential users ' enthusiasm. In the worst case scenario, there is no configuration information available to understand and diagnose the problem. You can try contacting users to collect data (device model, operating system version, application version, stack trace, and so on), but you may not even be able to contact users at times. Factors such as privacy, a large user base, and other reasons may prevent you from establishing a connection. Even if you can contact some users, they may not know how to reproduce the problem. Getting logs and other device information can require a lot of work and technical experience. Users may not be able to provide this data to you.
The situation is real and terrifying. Your application is negatively rated for crashes, and there are no details of crashes, and you will be overwhelmed when your app's reputation has plummeted. Even if you fix this problem, it may be too late-people are moving away from your application.
If there is a way to automatically detect crashes, check the details of crashes and crash conditions, and the time of crash, without contacting the user, that would be great.
In this article, you will learn about:
The Android log system provides a mechanism to collect and view system debug output. The stack trace from the crash and the use of the Log class to get additional message output from the application are recorded. You can use LogCat to view and filter these logs. Examples of log levels include details, debugging, information, warnings, and errors.
LogCat is part of the Android log system. It can be called from within Dalvik debug Monitor Server (DDMS) or Android debug Bridge (ADB) shell.
Example 1 of an LogCat view in Eclipse is shown in. The diagram shows a stack trace of a crash caused by Java NullPointerException.
Figure 1. The LogCat view in EclipseEach entry in the LogCat view contains the following information:
tags help you identify or filter messages. You can filter data by application, log level, and so on.
IosWhen an application in IOS crashes, a crash report is created and the report is stored on the device. The stack trace in the crash report contains the hexadecimal address that corresponds to the method name and line number. The hexadecimal address itself does not make any sense to the user. Therefore, before parsing the stack traces, these addresses need to be parsed into human-readable symbols, such as method names and line numbers. This process is called symbolization. Symbolizing requires application binaries and. DSYM files, which are generated when the binaries are built. Application binaries and. dSYM files require an exact match.
Crash reportIn addition to logs and stack traces, other information may also be important in diagnosing crashes, such as:
The process of providing this information to the application vendor when a crash occurs is known as a crash report.
The IBM Mobile Quality Assurance for Bluemix (MQA) and IBM Worklight Quality Assurance (WQA) support both mobile application testing and user verification:
MQA is a software as a service (SaaS) product on the IBM Bluemix platform. No need to install, just register on IBM Bluemix to use MQA. The first 30 days of use are free of charge. Depending on your business needs, you may choose to install it in your on-premises environment. WQA is an on-premises product that can be installed on your own server.
The remainder of this article will use MQA as the Bluemix SaaS. However, on-premises WQA products can also perform all the actions in this article.
Enable crash reporting using IBM Mobile quality assurance for BluemixTo enable crash reporting using MQA, you first need to register your application in MQA, then equip your application with a MQA SDK library and finally rebuild the application. Figure 2 illustrates these steps.
Figure 2. Steps to enable crash reporting register your applicationTo register your application in the MQA Web dashboard, you need to specify the name and platform of your application (Android or IOS). MQA generates an application key for your application to uniquely identify it. You are also provided with a link to download the MQA SDK. The SDK is available for native Android, native IOS, and Worklight JavaScript applications.
Equip your AppOnce you have the application key and the SDK library, you can equip your application. The equipment described here is a process: include the SDK library in your application, specify your unique application key, and invoke the SDK API as needed.
You can equip your application with pre-production or production SDK libraries. The pre-production library is ideal when the application is still in beta and only a small group of people are using it. By default, testers who use an application with a pre-production library are prompted to sign in to the application. After logging in, MQA begins to record who reported which errors and issues. The production library contains a subset of the MQA attributes that are designed to be used after the application is published and used by the customer. The production library does not prompt the user to log on to MQA. MQA will report all data anonymously. The production model respects the privacy of the user and collects less detail from the application using logs, session data, and crash reports.
Table 1 shows the features provided in the pre-production and production SDK libraries.
Table 1. SDK Library| features | Pre-production | Production |
|---|---|---|
| Build version Distribution | X | |
| Crash report | X | X |
| Error Reporting | X | |
| User Feedback | X |
Try it yourself!
Follow the steps and try it out for yourself!
Rebuild the applicationThe final step is to reconstruct the application binaries. Once the application binaries are rebuilt, you can distribute the application for testing or publish the application to the end user.
Review Crash summaryWhen a tester or end user uses an equipped application, you can begin to see the session in MQA. As long as the application is started in a mobile device or emulator, a related session is reported. Figure 3 shows the basic quality metrics for the application from the report session. If the application crashes, then these metrics will be reported to MQA along with the support details.
Figure 3. Application Quality SummaryYou can click the number of sessions on this page to check the details of each session. For a session that reports a crash, a stack trace is also provided.
The top section of the session report displays the status information for the device, including:
Clicking on any icon will open the relevant detail page. Figure 5 shows the details of the session time.
Figure 5. Details of the session timeFigure 6 shows the bottom part of the session details page. It shows the stack trace associated with a crash.
Figure 6. Crash Detail Custom ReportYou can configure what information to display for the session. Figure 7 shows the Condition Filtering page where you can select the information you want to display on the report.
Figure 7. Conditional Filtering Select closingIn this article, you learned about:
Also understand the summary and details of sessions and crashes, as well as the stack traces from crashes.
The crash report indicates one of many features of MQA. MQA also provides other metrics, such as errors and user feedback. Even if your app doesn't crash, people may still dislike it and post it on the App Store. App Store sentiment analytics provides in-depth information about how much a user likes your app. MQA also provides this functionality.
With these features, your application is not only as sturdy as a bridge, but also noticeable!
Reference LearningWhen your application crashes, you want to know all the information
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
