Android.mk detailed

Source: Internet
Author: User

ANDROID.MK is an makefile file provided by Android that specifies such things as compiling generated so library names, referenced header file directories,. c/.cpp files that need to be compiled, and. A static library files. To master the JNI, we must master Android.mk's grammatical norm.

I. Purpose of the ANDROID.MK file
One or more android.mk files exist in an Android sub-project
1. Single ANDROID.MK file
Refer directly to the HELLO-JNI project under the NDK's sample directory with only one android.mk file in this project
2. Multiple android.mk files
If you need to compile more modules, we may place the corresponding modules in the corresponding directory,
In this way, we can define the corresponding Android.mk file (similar to the one above) in each directory.
Finally, place a android.mk file in the root directory with the following contents:
Include $ (call All-subdir-makefiles)
This is all you need to do, which is to include the Android.mk file in all subdirectories.
3, multiple modules share a ANDROID.MK
This file allows you to organize your source files into modules that contain:
-Static libraries (. a files)
-Dynamic libraries (. so files)
Only shared libraries can be installed/copied into your application (APK) package
Include $ (build_static_library), compile a static library
Include $ (build_shared_library), compiled with a dynamic library



Ii.. Custom variables
The following is a list of variables that are dependent or defined in android.mk, and you can define other variables for your own use, but the NDK compilation system retains the following variable names:
-Names beginning with Local_ (e.g. Local_module)
-Names beginning with Private_, Ndk_ or app_ (for internal use)
-Lowercase names (internal use, e.g. ' My-dir ')
If you want to define your own variables in android.mk, it is recommended to use the My_ prefix, a small example:
My_sources: = foo.c
Ifneq ($ (my_config_bar),)
My_sources + = Bar.c
endif
Local_src_files + = $ (my_sources)
Note: ': = ' is the meaning of the assignment; ' + = ' is the appended meaning; ' $ ' indicates a value that refers to a variable.



Third, GNU make system variables
These GNU make variables are defined by the compilation system before your Android.mk file is parsed. Note In some cases, the NDK may analyze android.mk several times, and each time certain variables are defined differently.
(1) Clear_vars: Point to a compilation script, almost all undefined local_xxx variables are listed in the "Module-description" section. This script must be included before starting a new module: include$ (Clear_vars), which resets all LOCAL_XXX series variables except the Local_path variable.
(2) Build_shared_library: Point to compile script, compile the listed source code file into a shared library according to all the local_xxx variables.
Note that Local_module and local_src_files must be defined at least before the file is included.
(3) Build_static_library: A build_shared_library variable is used to compile a static library. Static libraries are not copied to the APK package, but can be used to compile shared libraries.
Example: Include $ (build_static_library)
Note that this will generate a file named lib$ (Local_module). A.
(4) Target_arch: The name of the target CPU platform
(5) TARGET_PLATFORM:Android.mk the name of the target Android platform when parsing. Details can be/development/ndk/docs/stable-apis.txt.
Android-3-Official Android 1.5 system images
Android-4-Official Android 1.6 system images
ANDROID-5-Official Android 2.0 system Images
(6) Target_arch_abi: Only two Value,armeabi and armeabi-v7a are supported temporarily.
(7) Target_abi: A combination of target platform and ABI,


Iv. Module Description Variables
The following variables are used to describe your module to the compilation system. should be defined between ' include $ (clear_vars) ' and ' include $ (build_xxxxx) '. $ (clear_vars) is a script that clears all these variables.
(1) Local_path: This variable is used to give the path to the current file.
Must be defined at the beginning of the ANDROID.MK, which can be used: local_path: = $ (call My-dir)
If there is a folder name src in the current directory, then you can write $ (call src), then you will get the full path of the SRC directory
This variable is not cleared by $ (clear_vars), so each android.mk needs to be defined only once (even if several modules are defined in one file).
(2) Local_module: This is the name of the module, it must be unique, and cannot contain spaces.
It must be defined before the $ (build_xxxx) script that contains the any. The name of the module determines the name of the generated file.
(3) Local_src_files: This is the list of source code files to compile.
Simply list the files to be passed to the compiler because the compilation system automatically calculates the dependencies. Note that the source code file names are relative to Local_path, and you can use the path section, for example:
Local_src_files: = foo.c toto/bar.c\
hello.c
Between the files can be separated by a space or TAB key, line-breaking please use "\"
If the source code file is appended, please use local_src_files + =
Note: You can local_src_files: = $ (call all-subdir-java-files) in this form to include all Java files in the Local_path directory.
(4) Local_c_includes: Optional variable that represents the search path for the header file.
The default header file search path is the Local_path directory.
(5) Local_static_libraries: Indicates which static libraries the module needs to use in order to link at compile time.
(6) Local_shared_libraries: Represents a shared library (dynamic Library) that the module relies on at run time, which is required at link time to embed its corresponding information when the file is generated.
Note: It does not attach the listed modules to the compilation diagram, which means that they still need to be added to the module in the APPLICATION.MK for the program requirements.
(7) Local_ldlibs: Additional linker options to use when compiling the module. This is useful for passing the name of the specified library using the '-l ' prefix.
For example, local_ldlibs: =-lz indicates that the module generated by the linker is to be linked to/system/lib/libz.so at load time
To view Docs/stable-apis. TXT gets a list of open system libraries that can be linked to using the NDK release.
(8) Local_module_path and Local_unstripped_path
In the Android.mk file, you can also specify the final destination installation path with Local_module_path and Local_unstripped_path.
Different file system paths are selected with the following macros:
Target_root_out: Represents the root file system.
Target_out: Represents the system filesystem.
Target_out_data: Represents the DATA file system.
Usage: Local_module_path: =$ (target_root_out)
As for the difference between Local_module_path and Local_unstripped_path, it is not clear for the time being.
(9) Local_jni_shared_libraries: Defines the name of the so library file to include, if the program does not use JNI, it does not need
Local_jni_shared_libraries: = libxxx So at compile time, the NDK will automatically pack this libxxx into the apk; put it in the youapk/lib/directory.



V. Function macros provided by the NDK
The GNU make function macro must be called by using ' $ (call) ', and the return value is the textual information.
(1) My-dir: Returns the path to the directory where the current android.mk resides, relative to the top level of the NDK compilation system. This is useful, as defined at the beginning of the Android.mk file:
Local_path: = $ (call My-dir)
(2) All-subdir-makefiles: Returns a list of all android.mk that are located in the subdirectory of the current ' my-dir ' path.
For example, a sub-project has the following directory hierarchy:
Src/foo/android.mk
Src/foo/lib1/android.mk
Src/foo/lib2/android.mk
If Src/foo/android.mk contains one line:
Include $ (call All-subdir-makefiles)
Then it will automatically contain src/foo/lib1/android.mk and src/foo/lib2/android.mk.
This feature is used to provide a deep nested code directory hierarchy to the compilation system.
Note that by default, the NDK will only search for files in src/*/android.mk.
(3) This-makefile: Returns the path to the current makefile (that is, where this function is called)
(4) Parent-makefile: Returns the parent makefile path in the call tree. The makefile path that contains the current makefile.
(5) Grand-parent-makefile: Returns the path of the parent makefile of the parent makefile in the call tree

#编译静态库 Local_path:= $ (Call my-dir) include $ (clear_vars) Local_module=Libhellos local_cflags=$ (l_cflags) Local_src_files=hellos.c local_c_includes=$ (includes) Local_shared_libraries:=libcutils local_copy_headers_to:=Libhellos local_copy_headers:=hellos.h include $ (build_static_library) #编译动态库 Local_path:= $ (Call my-dir) include $ (clear_vars) Local_module=Libhellod local_cflags=$ (l_cflags) Local_src_files=HELLOD.C local_c_includes=$ (includes) Local_shared_libraries:=libcutils local_copy_headers_to:=Libhellod local_copy_headers:=hellod.h include $ (build_shared_library) #使用静态库 Local_path:= $ (Call my-dir) include $ (clear_vars) Local_module:=hellos local_static_libraries:=Libhellos local_shared_libraries:=Local_ldlibs+= -LDL Local_cflags:=$ (l_cflags) Local_src_files:=mains.c local_c_includes:=$ (includes) include $ (build_executable) #使用动态库 Local_path:= $ (Call my-dir) include $ (clear_vars) Local_module:=Hellod local_module_tags:=Debug Local_shared_libraries:=libc libcutils libhellod local_ldlibs+= -LDL Local_cflags:=$ (l_cflags) Local_src_files:=maind.c local_c_includes:=$ (includes) include $ (build_executable)

Android.mk detailed

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.