How to locate errors encountered in Android NDK development

Do the debugging of Android application, the most afraid is error, crash, see this Good article, record:

Transferred from: Http://www.csdn.net/article/2014-12-30/2823366-Locate-Android-NDK

What is the Android ndk?

The Android NDK was added in front of the SDK with the word "native", the native development Kit, which Google called the "NDK". As is known to all, Android programs run in Dalvik virtual machines, and the NDK allows users to execute part of the program using native code languages like C + +. The NDK includes:

• The tools and build files needed to generate the native code base from C + +;

• Embed a consistent native library into the application package files that can be deployed on Android devices (application packages files, the. apk file);

• A range of native system header files and libraries that support all future Android platforms.

Why use the NDK? Broadly speaking, it is mainly divided into the following situations:

• Code protection, because the Java layer Code of the APK is easy to decompile, and the C + + library is difficult to reverse the sink;

• Call third-party C/S libraries in the NDK, because most of the open source libraries are written in C/s code;

• Easy to migrate, libraries written in C + + can be easily reused on other embedded platforms.

the relationship between the Android Jni and the NDK

The Java Native Interface (JNI) standard is part of the Java platform that allows Java code to interact with code written in other languages. JNI is a local programming interface that enables Java code running inside a Java Virtual machine (VM) to interoperate with applications and libraries written in other programming languages such as C, C + +, and assembly language.

In short, the NDK is a tool that can easily and quickly develop. so files. The process of JNI is more complex, generating. So requires a lot of action, and the NDK's role is to simplify the process.

What common NDK type exceptions can cause program crash?

The NDK compiles the generated. So file as part of the program, which also causes the program to crash when an exception is run. Unlike the Java code exception caused by the program crashes, when the NDK exception occurs, the program on the Android device will immediately exit, that is, usually said the flashback, and will not pop up "program XXX no response, whether immediately close" such as the Prompt box.

The NDK is developed using C + +, and programmers familiar with C + + know that pointers and memory management are the most important and most problematic places, with a slight loss of common problems such as invalid memory access, invalid objects, memory leaks, stack overflows, and finally the same result: program crashes. For example, we often say null pointer error, that is, when a memory pointer is set to NULL (NULL) and then access it again, another common mistake is to release a memory space somewhere in the program, and then try to access the memory address elsewhere in the program, resulting in an invalid address error. Common types of errors are as follows:

• initialization error;

• Access error;

• Memory leaks;

• Parameter error;

• Stack overflow;

• type conversion error;

• Number except 0 error.

How do I find and resolve NDK errors?

When developing native apps with the Android NDK, almost all programmers have experienced program crashes, but its crash will print a stack of seemingly heavenly-like stacks in logcat, giving people a head-on. It is a matter of course to locate the number of lines that the error code is doing by adding a row of printed information alone. Searching for "Android Ndk crashes" on the Web, you can search for many articles about how to find and locate NDK errors using the tools provided by Android, but are mostly obscure. Here is a practical example of how to locate the wrong function name and line of code in two different ways.

First, let's look at what we did in the code for the Hello-jni program (about how to create or import a project, here's a little bit), in the following code: in the Jni_onload () function, that is, when so is loaded, the Willcrash () function is called, and in the Willcrash () function, This assignment method of std::string produces a null pointer error. This will cause the HELLO-JNI program to flash back when it loads. Let's remember these two rows: the Willcrash () function was called in line 61, and a crash occurred on line 69.

Let's take a look at the Logcat log that the system prints when a crash occurs (flash back):

If you have seen the Logcat printed NDK error log will know that I omitted a lot of content, many people see so many dense log has been dizzy brain swelling, even many senior Android developers, in the face of the NDK log is also mostly silently chose to ignore.

In fact, as long as you carefully review, and then with the tools provided by Google, we can quickly and accurately locate the wrong code location, this work we call "symbolic." It is important to note that if you want to symbolize the NDK errors, you need to keep the so files that are generated during compilation that contain the symbol tables, which are typically kept in the $project_path/obj/local/directory.

The first method: Ndk-stack

This command-line tool is included in the installation directory of the NDK tool, and is put together with ndk-build and other commonly used NDK commands, such as on my Computer, where the location is/android-ndk-r9d/ndk-stack. According to Google's official documentation, the NDK provides the Ndk-stack command from the R6 version, and if you use the previous version, it is recommended that you upgrade to the latest version as soon as possible. There are two ways of using the Ndk–stack command

Real-time analytics logs

While running the program, use ADB to get the Logcat log, and through the pipe character output to ndk-stack, but also need to specify the location of the so file containing the symbol table, if your program contains a variety of CPU architectures, where the requirements based on the error occurs when the phone CPU type, Select a different CPU architecture directory, such as:

When a crash occurs, you get the following information:

We focus on #03 and #04, both of which are error messages in our own generated libhello-jni.so, so we will find the following key information:

Recall our code, in the Jni_onload () function (line 61st), we called the Willcrash () function, and in the Willcrash () function (line 69th), we made an error. All of this information is accurately extracted! Isn't it very simple?

Get log re-analysis first

There is no big difference between this method and the above method, just the way the Logcat log gets is different. You can save the Logcat log to a file while the program is running, and even when the crash occurs, quickly save the Logcat log, then analyze it, a little more flexible than the method above, and the log can be left to analyze later.

Second method: Use the Addr2line and Objdump commands

This approach applies to simple usages that are not satisfied with the above ndk-stack, and to inquisitive programmers, these two methods can reveal what the Ndk-stack command does, although it may be a little cumbersome to use, but it can satisfy the programmer's curiosity slightly.

Let's just say these two commands, you can find them in most Linux distributions, if your operating system is Linux and you're testing your phone using the Intel x86 series, you can use the commands that come with your system. However, if that's the case, most people are desperate because most developers are using Windows and the phone is probably the Armeabi series.

The NDK has its own toolchain for each operating system and CPU architecture, which includes both commands, but with a slight change in name, you can find them in the Toolchains directory of the NDK directory. Take my Mac computer as an example, if I'm looking for a tool for the Armeabi architecture, they're arm-linux-androideabi-addr2line and arm-linux-androideabi-objdump, respectively. Location in the following directory, this location will be omitted from subsequent introductions:

Assuming your computer is a Windows system and the CPU architecture is MIPS, then the tool you want may be included in the directory:

Next, let's look at how to use these two tools, as described below.

Find key function pointers in the log

In fact, it is very simple, is to find backtrace information, belong to our own so file error lines.

First of all to find backtrace information, some of the opportunity to explicitly print a line of backtrace (such as the mobile phone we use this time), then this line of the following a series of "#两位数字 PC" line is backtrace information. Sometimes the phone does not print a line of backtrace, so just find a line that starts with "#两位数字 PC".

Next to find their own so file error lines, this is relatively simple. After you find these rows, note the address of the functions in those lines.

Find Code Locations using Addr2line

Execute the following command, multiple pointer addresses can be entered in a command, separated by a space

The results are as follows:

As we can see from the results of the addr2line, we get the call relationship and the number of rows for our own error code, In the hello-jni.cpp of 69 rows and 61 lines (the other two lines because the standard function can be ignored), the results and ndk-stack are consistent, indicating that Ndk-stack is also addr2line to get the location of the code.

Get function Information using Objdump

With the Addr2line command, we've actually found the wrong place in our code, and we've been able to help the programmer locate the problem. However, this method can only get the number of lines of code, and does not display function information, it is not so "perfect", for the pursuit of the ultimate programmer, this is certainly not enough. Let's show you how to locate the function information.

First, use the following command to export the function table:

Find the two key pointers 00004fb4 and 00004f58 that we have just positioned in the generated ASM file:

From these two graphs can be clearly seen (note that in different NDK versions and different operating systems, the format of ASM files is not exactly the same, but all the same, please carefully compare), these two pointers belong to the Willcrash () and the Jni_onload () function, respectively, Combined with the results of the addr2line just now, the corresponding information for these two addresses is:

Quite perfect, and ndk-stack get the information exactly the same!

Testin Crash Analysis How to help developers discover NDK bugs

The above mentioned method is only suitable during the development test, if your app or game is online, and users often feedback that crashes, flash back, it is almost impossible to expect users to help you collect information location problem. At this point, we need to use other means to capture the crash information.

At present, some companies in the industry have launched crash information collection services, by embedding the SDK, in the event of a crash, collect stack information, sent to the cloud service platform, to help developers locate the error message. In this regard, domestic testin and foreign crittercism can provide similar services.

Testin supports the NDK crash Analysis starting with version 1.4, and its latest version has been upgraded to 1.7. When a NDK error occurs in the program, the embedded SDK collects the stack information of the program when it crashes on the user's phone (mainly the function pointers we get through the Logcat log above), device information, thread information, and so on, and the SDK reports the information to the Testin cloud service platform. Unique processing on the platform, and can be customized time period for detailed statistical analysis, from the multi-dimensional display program crashes information and severity; The latest version also supports user-defined scenarios to help developers locate the problem.

Stack information escalated from the user's phone, Testin provides a symbolic function for the NDK crash, as long as the so file containing the symbol table generated during our compilation is uploaded, the function pointer address can be automatically positioned to the function name and the number of lines of code. Once symbolized, it looks the same as the results we had in the local test before, at a glance. There is also a benefit to using this feature: the so file containing the symbol table will change after each developer's compilation, and it is likely that we have changed since the release, because the developer will modify the program. In this case, even if we get the stack information at the time of the crash, we can no longer symbolize it. We can upload these files to Testin for symbolic work, Testin will save and manage different versions of so files for us to ensure that the information is not lost.

Yin Chunpeng, vice president of Testin Cloud measurement technology, head of development, Testin crash master. Graduated from Tsinghua University, Department of Engineering Physics; focused on mobile application development, since 2011 to participate in the creation of Testin, focused on Android and iOS mobile application Automation test research and development, is responsible for the construction of Testin automated test platform, is a pioneer in the field of automated test technology research and development and frontier exploration.

How to locate errors encountered in Android NDK development