The usage and foundation of android.mk "turn"

a android.mk file is used to describe your source code to the compilation system. Specifically: The file is a small part of the GNU makefile, which is parsed one or more times by the compiled system. You can define one or more modules in each android.mk file, and you can use the same source code file in several modules. The compilation system handles many detail issues for you. For example, you do not need to include your android.mk in your files and dependent files. The NDK compilation system will automatically handle these issues for you. This also means that after upgrading the NDK, you should get new Toolchain/platform support and do not need to change your android.mk file.
let's look at a simple example: a simple "Hello World", such as the following file:
SOURCES/HELLOWORLD/HELLOWORLD.C
sources/helloworld/android.mk
the corresponding android.mk file will look like this:
----------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)
a android.mk file must first define a good local_path variable. It is used to find source files in the development tree. In this example, the macro function ' My-dir ', provided by the compilation system, is used to return the current path (that is, the directory containing the android.mk file).
include $ (clear_vars)
Clear_vars is provided by the build system, specifying that GNU makefile clears many local_xxx variables for you (such as 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 that you describe in the Android.mk file. The name must be unique and does not contain any spaces. Note that the compilation system will automatically generate the appropriate prefix and suffix, in other words, a shared library module named ' foo ' will generate ' libfoo.so ' files.
local_src_files: = HELLOWORLD.C
The Local_src_files variable must contain a C or C + + source code file that will be compiled into a module. Note that you do not have to list header files and include files here, because the compilation system will automatically find the dependent files for you; Just list the source code files that are passed directly to the compiler.

adding native programs or libraries to Android, these programs and libraries have nothing to do with the path they are carrying, only their android.mk files. Android.mk and ordinary makefile different, it has a unified writing, mainly contains some of the system public macros.
multiple executable programs, dynamic libraries, and static libraries can be generated in a single android.mk.
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)
(Rookie level Explanation:: = is the meaning of the assignment, $ is the value of a reference to a variable) local_src_files to add the source file path, local_c_includes to include the required header file path, local_static_ Libraries add the name of the static library (*.A) that you want to link to, add the name of the dynamic library (*.so) you want to link to local_shared_libraries, local_module the final name of the module, Build_ The executable represents the compilation as an executable program.
2, compile the template for the static library:
#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, similar to the above, build_static_library means compiling a static library.
3. Compile the template for the dynamic library:
#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, similar to the above, build_shared_library means compiling a static library.
the results of the above three are as follows, generic depending on the target will change:
out/target/product/generic/obj/executable
out/target/product/generic/obj/static_library
out/target/product/generic/obj/shared_library
the target folders for 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 destination installation path, specified 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 such as:
cal_module_path:=$ (target_root_out)

Provenance ANDROID.MK usage and basics-Zhandoushi's column-CSDN blog

The usage and foundation of android.mk "turn"