ANDROID.MK Syntax parsing

Source: Internet
Author: User

The Android.mk file is equivalent to a small fragment from the makefile file, very, very small! Can be parsed by the system one or more times! Should be as few as possible to declare

A very important part of the file is the module


1.-A static library

2.-A shared library dynamic


Just install/Copy the dynamic library to your application package, and the static library is used to generate the dynamic library


You can define one or more modules, and the same source file you can put in multiple modules


There are some details to be aware of before compiling, such as: Do not need to write the header file or some dependencies to the Android.mk file, the NDK will automatically calculate for you, this means that when your NDK update, you do not have to worry about modifying the android.mk file


Before describing the syntax in detail, let's look at a small example:

Apps/hello-jni/project


In this project file:

The-src folder contains the Java source code

The-jni folder contains the local source code, for example: JNI/HELLO-JNI.C


This code implements a local call method for the VM to return to a shared library generated by a string


-jni/android.mk file, the general content contains the following:

Local_path: = $ (call My-dir)


Include $ (clear_vars)


Local_module: = Hello-jni

Local_src_files: = Hello-jni.c


Include $ (build_shared_library)


Each android.mk file must start with the Local_path variable, call <function> the function of the content with the most is my-dir, but there are other can also be used, the meaning of the representative you can look at, Like All-subdir-makefiles,this-makefile,parent-makefile,grand-parent-makefile,import-module. Through it to find your source file in the development structure code, in the example of the macro function ' My-dir ' is provided by the compilation system, to return the path of the current folder, the path contains android.mk files


Include $ (clear_vars)

This sentence is also necessary, through the clear_vars variable to clean up the entire system except Local_path local_xxx global variable definition, such as Ocal_module, Local_src_files, Local_static_ LIBRARIES, etc ..., after this is done, you can re-assign the data below, and this variable is provided by the compiler system.


Local_module: = Hello-jni

This is to specify that you are the secondary compilation generated by the Dynamic Link library folder name, must be unique, the name can not have spaces, the system will automatically give you the prefix and suffix, your name is Hello-jni so after the compilation is completed, the generated file name is libhello-jni.so


Note: If your local_module: = Libhello-jni, then the system will not add a prefix to you


Local_src_files: = Hello-jni.c

Local_src_files This variable must consist of a series of C + + source files to compile and assemble into your module, you do not need to include your header file here, because the compilation system will automatically calculate your dependencies, you only need to list directly compiled the required files.

The default C + + file suffix is. cpp, and if you want to change it, you can change it by local_cpp_extension=.c++ variable, and don't forget to add '. '

and the corresponding file or path under this variable is relative to your local_path, don't write it wrong


include $ (build_shared_library)

The build_shared_library variable is provided by a compiled system, pointing to a GNU makefile script that collects the values of the most recently modified global variables, determines what to build, how to execute precisely, uses this variable, Then your android.mk file must have the definition of local_module and local_src_files. Generated library file rule: lib$ (Local_module). So.


Compiling a static library (build_static_library) is similar to the above, and is essential to include definitions of local_static_libraries and local_whole_static_libraries. The rules for generating a library file are: lib$ (local_module). A


Prebuilt_shared_library

Prebuilt_static_library

Precompiled shared libraries and static libraries use the same method as above, add an include $ () at the end of the Android.mk file.

The difference is that this android.mk file does not generate a new library, but instead copies your precompiled library to $project/obj/local, stripping the processed copy to $project/libs/<abi>


In particular, it is important to note that at this point your local_src_files is storing the path to your shared library, not a C/s + + file, and if your shared library also relies on the *.h file, you also need to pass the Local_export_c_includes Bring the file in.


Target_arch

This setting of your CPU structure is arm x86


Target_platform

The value you see on the Web is: generic this is specifying the target platform name you want to compile, such as:

android-3-official Android 1.5 system images

Android-4-Official Android 1.6 system images

ANDROID-5-Official Android 2.0 system Images

Android-6-Official Android 2.0.1 system images

Android-7-Official Android 2.1 system Images

Android-8-Official Android 2.2 system images

Android-9-Official Android 2.3 system Images

ANDROID-14-Official Android 4.0 system images


Target_arch_abi This ABI is the abbreviation for Application Binary interface.

The value of this variable is a combination of Cpu+abi

There are two types of support: Armeabi is for armv5te instruction set versatility, but less efficient than the following

ARMEABI-V7A is for the armv7-a instruction set.

For the above two differences can be consulted: http://www.myexception.cn/android/1594360.html


Local_module_filename

Local_module generated library files will automatically add prefixes and suffixes, but if you use Local_module_filename, the name of the previously generated library file will be changed

Note: The value of this variable cannot be a path at the same time name cannot add suffix name, the compilation system will automatically add for you


Local_cpp_extension

This variable is optional and you can use this variable to specify the name of the C + + suffix that your compilation system recognizes when your C + + file's suffix name is not CPP.

After the NDK R7 version, this variable can be written like this: local_cpp_extension: =. cxx. CPP. cc


Local_c_includes

When compiling the path you want to append to this, and must be placed before local_cflags/local_cppflags, it is best to use local_c_includes instead of local_cflags/local_cppflags


Local_ldlibs

This is used to load specific system libraries, such as frequently used liblog.so. A prefix of "-l" must be added when using

The current encounters are:

-lz-ldl-lglesv1_cm-lglesv2-ljnigraphics-lopensles-lopenmaxal



Reference:

Http://www.kandroid.org/ndk/docs/ANDROID-MK.html

Http://www.cnblogs.com/wainiwann/p/3837936.html


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.