The Android platform supports JNI single-step debugging from froyo 2.2

From: http://blogold.chinaunix.net/u/26691/showart.php? Id = 2247039

Source code: http://blogimg.chinaunix.net/blog/upfile2/100604145124.gz

 

 

 

Beijing University of Technology, 20981 Chen Yu
I. Preface (it can be understood as nonsense)
Some time ago, I saw Google's I/O conference on the Internet and saw Google's work in the IT technology development and innovation field. (I would like to congratulate you on Apple's artist portal. You have worked hard ). Although Google believes that there may only be two types of programs on PC in the future-browser and game, at present, applications on PC platforms still have a certain market, after all, HTML5 promotion and application take some time (the first person who eats crabs may eat well, but what if the first person who eats mushrooms? What if I eat poisonous mushrooms? The industry is waiting, and it seems that once others eat well, they will be flocking at that time ). This is as if Google is advocating various HTML5 features, but it still adds support for flash 10.0 on the Android platform (in the original saying: "Hey, man, people use flash! "), From this point of view, Google is more user-friendly, while Apple is more radical (this is not to say who is good, who is not good, and occasionally like radical style pull, after all, the iPhone is revolutionizing the entire mobile phone industry, and the principle of uidesign is suddenly very high, which makes some companies that once sold wood very depressed ).

Back to the truth, froyo has added many new features and improved many places, but I think the most gratifying thing for developers is that Android 2.2 has modified the Dalvik Running Mechanism (it should be said that it has added something similar to the JIT engine), which can make the program run faster, in addition, it supports JNI single-step debugging (the tears of this feature can be seen in a bid, and I want to close my eyes in the face of the dense log output by the JNI module ...). Other things such as app to SD, Wireless AP, exchange, push API, voice translation, search, and so on are all icing on the cake.

From an even point of view-speed is the final truth!

Otherwise, it would be a pity that the 1 GHz Nexus One processor is used.

2. ndk-r4 brings us a pleasant surprise
Let's just say nothing, just translate the important part of changes.txt (if you are a good English friend, you can ignore it directly ).
The original changes.txt in the android-ndk-r4/docs directory:
Reuse bug fixes:
(1) <fenv. h> the position of this header file in the ndk of previous versions is incorrect. This will cause compilation failure because the file cannot be found during some general compilation processes. (This problem has been fixed in the ndk-r4)

Important changes:
(1) In the Win32 environment, ndk must be used with cygwin of version 1.7 or later. Currently, ndk may not work normally in cygwin 1.5.
(2) further simplify the compilation process:
Developers no longer need to enter the root directory of ndk, and then run build/host-setup.sh scripts to initialize environment variables or modify any files under the $ ndk_root/apps directory, instead, when compiling the JNI module, you only need to run the "ndk-build" command under the JNI directory to automatically complete the compilation process (this script can even be automatically compiled by the modules under the subdirectory ).
For details about how to use the ndk-buildscript, see overview.txtand ndk-build.txt.
Note:
For compatibility considerations, developers can still create projects in "$ ndk_root/apps/<Name>. However, the sample project of ndk has been transferred from the apps directory to the "samples/<Name>" directory, and it must be compiled using the "ndk-build" script when compiling the JNI module.
(3) Introduce more convenient debugging methods:
Starting from Android 2.2 (also applicable to later Android systems), developers can use the "ndk-GDB" tool to conveniently debug native modules. For more information, see "ndk-gdb.txt. (This is what I want to talk about in this article)
(4) FPU supporting hardware:
Depending on a device at the ARMv7-a level, you can specify the ndk to generate the machine code for the new armeabi-v7a Abi.
Note:
In the default configuration, the ndk still generates the old "armeabi" Abi (based on the armv5te Instruction Set) machine code. This configuration can work in all the currently known Android system images. (It takes half a day, in fact, it means that the default module generated by ndk has better compatibility, and the new features can be optimized to provide higher performance and use more advanced arm instruction sets ).

To modify the configuration of the ndkgeneration machine code, you must complete the modification of the app_abi variable of the mkfile. For specific modifications, see the application-mk.txt document.

(5) provides a small "cpufeatures" static library, which can be used to obtain the features currently supported by the CPU during JNI running. This library supports all platforms starting from Android 1.5. For more detailed information about the database, see cpu-features.txt.

(6) support the optional arm advanced SIMD (a.k. A. Neon) features. The following CPU-related features are still well studied by friends interested in hardware optimization. Note that there is an example named hello-neon under the samples directory to demonstrate CPU features. Do not miss it if you are interested.

(7) added <Android/bitmap. h> header file, which can provide the JNI module for the imported android. graphics. direct operations on Bitmap objects (this function is too useful; otherwise, it is troublesome to operate bitmap objects in JNI ...), For usage, see the bitmap-plasma sample program in the samples directory.

In addition, it is to support some security functions and some bug fixes that ensure that the module will not be executed by the kernel, and finally mention that the ndk-r4 has started to support. the pure assembly code at the end of S has been compiled (the previous compilation can support embedded compilation), so the hardcore players have paid attention to it!

Finally, the header files of some C and C ++ libraries are modified and fine-tuned, so noise will not be added here.

3. Start to experience ndk-r4
After reading the changes above, I think everyone is starting to itch ?! OK, immediately began to install this ndk-r4, of course, the premise is that the SDK must be updated to Android 2.2 this platform corresponding to the latest version, of course, the corresponding ADT also want to upgrade Oh!

Old rules, even all the introductions are based on the Linux platform.

1. Download ndk-r4
Of course, the official website is: developer.android.com/sdk/ndk/index.html. Thanks to the reason for harmony, we cannot download it. You can download it through a proxy. I believe there will always be a way to download it.

2. Install ndk-r4
It's actually quite easy. Just use one command:
$ Unzip android-ndk-r4-linux-x86.zip
After decompression will see a directory called android-ndk-r4, this directory needs to export to the current path environment variables to go:
$ Export Path = ~ Android-ndk-r4: $ path
Then the ndk is installed. (Don't ask why I don't run the build/host-setup.sh script, it's already out on R4)

3. Compile a hello World file.
$ Cd ~ /Android-ndk-r4/samples/Hello-JNI/
$ Ndk-build
Gdbserver: [arm-eabi-4.4.0]/home/Wayne/android-ndk-r4/samples/Hello-JNI/libs/armeabi/gdbserver
Gdbsetup:/home/Wayne/android-ndk-r4/samples/Hello-JNI/libs/armeabi/GDB. Setup
Gdbsetup: + Source directory/home/Wayne/android-ndk-r4/samples/Hello-JNI/JNI
Install: libhello-jni.so =>/home/Wayne/android-ndk-r4/samples/Hello-JNI/libs/armeabi
If you see the above output, congratulations! The so library of JNI has been compiled successfully.

4. generate an APK.
This step is annoying. You must install ant and the latest Android SDK, and export the $ android_sdk/tools and ant bin directories to the path environment variable.
Here, I only paste the configurations:
$ Export Path =/usr/local/Apache-ant-1.8.1/bin: $ path
$ Export Path =/home/web/android-sdk-linux_86/tools: $ path
Of course, these changes to the path can be directly written to the/etc/profile file. The next time you enter the shell, the system will automatically prepare the changes. Here, press "no table.

Okay. Start generating the APK.
$ CD ../
$ Android update project -- path hello-JNI
$ CD hello-JNI
$ Ant debug
Buildfile:/home/Wayne/android-ndk-r4/samples/Hello-JNI/build. xml
[Setup] Android SDK tools Revision 6
[Setup] project target: Android 2.2
[Setup] API level: 8
[Setup] Warning: attribute minsdkversion in androidmanifest. XML (3) is lower than the project target API level (8)
[Setup] importing rules file: platforms/Android-8/ANT/ant_rules_r2.xml

-Compile-tested-if-test:

-Dirs:
[Echo] creating output directories if needed...

-Resource-Src:
[Echo] generating R. Java/manifest. Java from the resources...

-Aidl:
[Echo] compiling aidl files into Java classes...

Compile:
[Javac]/home/Wayne/android-sdk-linux_86/platforms/Android-8/ANT/ant_rules_r2.xml: 255: Warning: 'includeantruntime' was not set, defaulting to build. sysclasspath = last; set to false for Repeatable builds
[Javac] compiling 1 source file to/home/Wayne/android-ndk-r4/samples/Hello-JNI/bin/classes

-Dex:
[Echo] converting compiled files and external libraries into/home/Wayne/android-ndk-r4/samples/Hello-JNI/bin/classes. Dex...

-Package-resources:
[Echo] packaging Resources
[Aaptexec] creating full resource package...

-Package-debug-sign:
[Apkbuilder] creating HelloJni-debug-unaligned.apk and signing it with a debug key...
[Apkbuilder] Using keystore:/home/Wayne/. Android/debug. keystore

Debug:
[Echo] running zip align on final APK...
[Echo] Debug package:/home/Wayne/android-ndk-r4/samples/Hello-JNI/bin/HelloJni-debug.apk

Build successful
Total time: 7 seconds
After these commands are run, if the above output is displayed, the generated APK is normal, and then the installation program is used.

5. Install and debug the program
Even fans of Android, Nexus One brushed froyo 2.2 early, so it was installed directly on the mobile phone. Since many friends do not have Nexus One, it is better to use emulator for demonstration below.

First, run the android command to create a 2.2 emulator. (The method for creating a simulator does not enable noise, as shown in)

Secondly, enter the android-ndk-r4/samples/Hello-JNI/bin directory, you should be able to find an APK installation package, directly install it.
$ ADB install./HelloJni-debug.apk
1201 kb/s (78926 bytes in 0.064 S)
PKG:/data/local/tmp/HelloJni-debug.apk
Success
If you see success, the installation is successful.

Then, pay attention to the following: If you have endured so many nonsense friends, the following is the key point!
$ Cd ~ /Android-ndk-r4/samples/Hello-JNI/
$ Ndk-GDB
Now, observe the simulator's response. Hoho, do you see the hello-JNI program in the simulator opened by yourself ?!

Then, ndk-GDB automatically enters the status of a command line prompt:
And track explicitly loaded dynamic code.
Warning: Shared Library handler failed to enable breakpoint
0xafd0eb08 in ?? ()
(GDB) List
1 /*
2 x copyright (c) 2009 the android open source project
3 *
4 * licensed under the Apache license, version 2.0 (the "License ");
5 * you may not use this file except T in compliance with the license.
6 * You may obtain a copy of the license
7 *
Http://www.apache.org/licenses/LICENSE-2.0 8 *
9 *
10 * unless required by applicable law or agreed to in writing, software
(GDB) List
11 * distributed under the license is distributed on an "as is" basis,
12 * Without warranties or conditions of any kind, either express or implied.
13 * See the license for the specific language governing permissions and
14 * limitations under the license.
15 *
16 */
17 # include <string. h>
18 # include <stdlib. h>
19 # include <JNI. h>
20
(GDB) List
21 static void upper_str (char * s, int Len ){
22 int I;
23 For (I = 0; I <Len; I ++ ){
24 if (S [I]> = 'A') & (s [I] <= 'Z ')){
25 s [I] = s [I]-'A' + 'a ';
26}
27}
28}
29
30/* This is a trivial JNI example where we use a native Method
(GDB)
Those who have developed it in Linux must be familiar with the command line mode of GDB? Now everything is open.

Some may ask, why is there a lot of warning, as if the symbols cannot be found?
In fact, this is very simple. The simulator of Android 2.2 is a release version, and the debug version must be slow. Therefore, many function libraries and symbols are unavailable. Therefore, I can't find it in GDB. It's just a matter of fact. Just ignore it! I would like to admire it here. In addition, if someone really wants to figure this out, he can use the android source code to compile a debug version of Android. Even the native program can be debugged, and there is no such warning, but it will be a painful process ).

Then there is the conventional GDB debugging command.
List-display code
X-view memory
P-view Variables
B-set breakpoints
Cont-program continues to run
S-one-step execution, but can be tracked into the function
N-one-step execution, but does not enter the Function
Let's take a look at the usage of GDB, and I will not bother with it any more. There are many instructions on the Internet.

Please note that I believe our careful friends have seen how the interface is different from everyone's hello-JNI ?!

The basic principle of online debugging for Android is not a local GDB program. Instead, it starts something called GDB-server on the simulator (or a real machine) and passes through the TCP connection of ADB, connect the local GDB of the developer to the GDB-server on the simulator (or real machine) and debug it. This process is relatively cumbersome. If you are interested, you can refer to the ndk-GDB script (Hoho, when I tried to debug the native program, it is a self-written script for connecting GDB and GDB-server. During this period, I greeted many generations of Google's founders, and pressed them here)

In hello-JNI, JNI functions are called in the oncreate function of activity. That is to say, once a program is started, JNI has been called, when the PC-side GDB is connected to the GDB-server of the simulator, JNI has been run, and the oncreate function is not called at will. Therefore, where can I place a breakpoint ?! I thought of a method, that is, to modify the original hello-JNI program, add a small button in it, and call the JNI function only when the button is pressed.

In this way, when ndk-GDB is used, the activity is started and the JNI function is not called. When the breakpoint of the function is set, run the "Cont" command, then click the button, and then it will actually run into the breakpoint.

For your convenience, I will paste the modified source code of hello-JNI.
I hope this article will be helpful to my friends who have developed the Android platform.