Android. mk usage | static library | dynamic library

Linux function library Introduction

The function library can be seen as a collection of functions written in advance. It can be separated from the main function to increase the reusability of program development. In Linux, function libraries can be used in three forms: static, shared, and dynamic.

1) the code of the static library has been connected to the application developed by the developer at the time of compilation;

2) The shared library is loaded only when the program starts running;

3) the dynamic library is also loaded when the program is running, but unlike the shared library, the library function used by the dynamic library does not start loading when the program is running, instead, the statements in the program are loaded only when the function is used. The dynamic library can release the memory occupied by the dynamic library during the running of the program, freeing up space for other programs to use.

Note: Because the shared library and dynamic library do not include the library function content in the program, but only contain references to the library function, the code size is relatively small.

Android. mk usage | static library | dynamic library

An android. mk file is used to describe your source code to the compilation system. The compilation system handles many details for you. For example, if you do not need to list header files and dependent files in your android. mk file, the ndk compilation system will automatically handle these problems for you. After upgrading 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:
Local_path: = $ (call my-DIR)
Include $ (clear_vars)
Local_module
: = Helloworld
Local_src_files: = helloworld. c

Include $ (build_shared_library)

Let's explain these lines of code:
(1) 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 ).
(2) 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.
(3) 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.
(4) 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, 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, you can specify the final target installation path in the Android. mk file.,
Use local_module_path and local_unstripped_path to specify. 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)