Android. mk usage and basics

 

Transferred from: zhandoushi blog

Address: http://blog.csdn.net/zhandoushi1982/archive/2010/02/22/5316669.aspx

 

An android. mk file is used to describe your source code to the compilation system. Specifically, this file is a small part of GNU makefile and will be parsed once or multiple times by the compilation system. You can define one or more modules in each android. mk file. You can also use the same source code file in several modules. The compilation system handles many details for you. For example, you do not need to list header files and dependent files in your android. mk file. The ndk compilation system automatically handles these problems for you. This also means that after you upgrade the ndk, you should get the new toolchain/platform support and do not need to change your android. mk file.
Let's take a look at a simple example: A simple "Hello World", such as the following file:
Sources/helloworld. c
Sources/helloworld/Android. mk
The corresponding Android. mk file will look like the following:
---------- Cut here ------------------
Local_path: = $ (call my-DIR)
Include $ (clear_vars)
Local_module
: = Helloworld
Local_src_files: = helloworld. c
Include $ (build_shared_library)
---------- Cut here ------------------
Let's explain these lines of code:
Local_path: = $ (call my-DIR)
An android. mk file must first define the local_path variable. It is used to search for source files in the Development tree. In this example, the macro function 'my-dir' is provided by the compilation system and used to return the current path (that is, the directory containing the Android. mk file ).
Include $ (clear_vars)
Clear_vars is provided by the compilation system, specifying that GNU makefile clears many local_xxx variables for you (for example, local_module, local_src_files, local_static_libraries, etc.), except local_path. This is necessary because all the compilation control files are in the same GNU make execution environment, and all the variables are global.
Local_module: = helloworld
The local_module variable must be defined to identify each module you describe in the Android. mk file. The name must be unique and contain no spaces. Note that the compilation system automatically generates the appropriate prefix and suffix. In other words, a shared library module named 'foo' will generate the 'libfoo. so' file.
Local_src_files: = helloworld. c
The local_src_files variable must contain the C or C ++ source code files to be compiled and packaged into the module. Note that you do not need to list header files and contained files here, because the compilation system will automatically find the dependent files for you; just list the source code files directly transmitted to the compiler.

Add local programs or libraries in Android. These programs and libraries have nothing to do with their paths, but only with their android. mk files. Android. mk is different from a general makefile. It has a unified Writing Method and mainly contains some common macros of the system.
Multiple executable programs, dynamic libraries, and static libraries can be generated in an android. mk file.
1. Compile the Application Template:
# Test exe
Local_path: = $ (call my-DIR)
# Include $ (clear_vars)
Local_src_files: = Main. c
Local_module: = test_exe
# Local_c_includes: =
# Local_static_libraries: =
# Local_shared_libraries: =
Include $ (build_executable)
(Cainiao-level explanation: = is the meaning of the value assignment, $ is to reference the value of a variable.) Add the source file path to local_src_files and add the header file path to local_c_pair des, local_static_libraries is added to the static library to be linked (*. a) Name. Add the dynamic library (*. so) name. local_module indicates the final name of the module, and build_executable indicates compiling in an executable program.
2. Compile the static library template:
# Test static lib
Local_path: = $ (call my-DIR)
Include $ (clear_vars)
Local_src_files: =/
Helloworld. c
Local_module: = libtest_static
# Local_c_includes: =
# Local_static_libraries: =
# Local_shared_libraries: =
Include $ (build_static_library)
In general, it is similar to the above. build_static_library indicates compiling a static library.
3. Compile the dynamic library template:
# Test shared lib
Local_path: = $ (call my-DIR)
Include $ (clear_vars)
Local_src_files: =/
Helloworld. c
Local_module: = libtest_shared
Target_prelink_modules: = false
# Local_c_includes: =
# Local_static_libraries: =
# Local_shared_libraries: =
Include $ (build_shared_library)
In general, it is similar to the above. build_shared_library indicates compiling a static library.
The above three generation results are as follows, and the generic changes according to the specific target:
Out/target/product/generic/obj/executable
Out/target/product/generic/obj/static_library
Out/target/product/generic/obj/shared_library
The target folders of each module are:
Executable program: xxx_intermediates
Static Library: xxx_static_intermediates
Dynamic library: xxx_shared_intermediates
In addition, in the Android. mk file, you can specify the final target installation path, which is specified using local_module_path and local_unstripped_path. Use the following macro to select different file system paths:
Target_root_out: indicates the root file system.
Target_out: indicates the system file system.
Target_out_data: indicates the data file system.
Usage example:
Cal_module_path: = $ (target_root_out)

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/zhandoushi1982/archive/2010/02/22/5316669.aspx