首页 > 代码库 > Android.mk
Android.mk
Android.mk
This page describes the syntax of the Android.mk build file, which glues your C and C++ source files to the Android NDK.
Overview
The Android.mk file resides in a subdirectory of your project‘s jni/ directory, and describes your sources and shared libraries to the build system. It is really a tiny GNU makefile fragment that the build system parses once or more. The Android.mk file is useful for defining project-wide settings that Application.mk, the build system, and your environment variables leave undefined. It can also override project-wide settings for specific modules.
The syntax of the Android.mk allows you to group your sources into modules. A module is either a static library, a shared library, or a standalone executable. You can define one or more modules in each Android.mk file, and you can use the same source file in multiple modules. The build system only places shared libraries into your application package. In addition, static libraries can generate shared libraries.
In addition to packaging libraries, the build system handles a variety of other details for you. For example, you don‘t need to list header files or explicit dependencies between generated files in your Android.mk file. The NDK build system computes these relationships automatically for you. As a result, you should be able to benefit from new toolchain/platform support in future NDK releases without having to touch your Android.mk file.
The syntax of this file is very close to that used in the Android.mk files distributed with the full Android Open Source Project. While the build system implementation that uses them is different, their similarity is an intentional design decision aimed at making it easier for application developers to reuse source code for external libraries.
Basics
Before exploring the syntax in detail, it is useful to start by understanding the basics of what a Android.mk file contains. This section uses the Android.mk file in the Hello-JNI sample toward that end, explaining the role that each line in the file plays.
An Android.mk file must begin by defining the LOCAL_PATH variable:
LOCAL_PATH := $(call my-dir)
This variable indicates the location of the source files in the development tree. Here, the macro function my-dir, provided by the build system, returns the path of the current directory (the directory containing the Android.mk file itself).
The next line declares the CLEAR_VARS variable, whose value the build system provides.
include $(CLEAR_VARS)
The CLEAR_VARS variable points to a special GNU Makefile that clears many LOCAL_XXX variables for you, such as LOCAL_MODULE, LOCAL_SRC_FILES, and LOCAL_STATIC_LIBRARIES. Note that it does not clear LOCAL_PATH. This variable must retain its value because the system parses all build control files in a single GNU Make execution context where all variables are global. You must (re-)declare this variable before describing each module.
Next, the LOCAL_MODULE variable stores the name of the module that you wish to build. Use this variable once per module in your application.
LOCAL_MODULE := hello-jni
Each module name must be unique and not contain any spaces. The build system, when it generates the final shared-library file, automatically adds the proper prefix and suffix to the name that you assign to LOCAL_MODULE. For example, the example that appears above results in generation of a library called libhello-jni.so.
Note: If your module‘s name already starts with lib, the build system does not prepend an additional lib prefix; it takes the module name as-is, and adds the .so extension. So a source file originally called, for example, libfoo.c still produces a shared-object file called libfoo.so. This behavior is to support libraries that the Android platform sources generate from Android.mk files; the names of all such libraries start with lib.
The next line enumerates the source files, with spaces delimiting multiple files:
LOCAL_SRC_FILES := hello-jni.c
The LOCAL_SRC_FILES variable must contain a list of C and/or C++ source files to build into a module.
The last line helps the system tie everything together:
include $(BUILD_SHARED_LIBRARY)
The BUILD_SHARED_LIBRARY variable points to a GNU Makefile script that collects all the information you defined in LOCAL_XXX variables since the most recent include. This script determines what to build, and how to do it.
There are more complex examples in the samples directories, with commented Android.mk files that you can look at. In addition, Sample: native-activity provides a detailed explanation of that sample‘s Android.mk file. Finally, Variables and Macros provides further information on the variables from this section.
Variables and Macros
The build system provides many possible variables for use in the the Android.mk file. Many of these variables come with preassigned values. Others, you assign.
In addition to these variables, you can also define your own arbitrary ones. If you do so, keep in mind that the NDK build system reserves the following variable names:
- Names that begin with LOCAL_, such as LOCAL_MODULE.
- Names that begin with PRIVATE_, NDK_, or APP. The build system uses these internally.
- Lower-case names, such as my-dir. The build system uses these internally, as well.
If you need to define your own convenience variables in an Android.mk file, we recommend prepending MY_ to their names.
NDK-defined variables
This section discusses the GNU Make variables that the build system defines before parsing your Android.mk file. Under certain circumstances, the NDK might parse your Android.mk file several times, using a different definition for some of these variables each time.
CLEAR_VARS
This variable points to a build script that undefines nearly all LOCAL_XXX variables listed in the "Developer-defined variables" section below. Use this variable to include this script before describing a new module. The syntax for using it is:
include $(CLEAR_VARS)
BUILD_SHARED_LIBRARY
This variable points to a build script that collects all the information about the module you provided in your LOCAL_XXX variables, and determines how to build a target shared library from the sources you listed. Note that using this script requires that you have already assigned values to LOCAL_MODULE and LOCAL_SRC_FILES, at a minimum (for more information about these variables, see Module-Description Variables).
The syntax for using this variable is:
include $(BUILD_SHARED_LIBRARY)
A shared-library variable causes the build system to generate a library file with a .so extension.
BUILD_STATIC_LIBRARY
A variant of BUILD_SHARED_LIBRARY that is used to build a static library. The build system does not copy static libraries into your project/packages, but it can use them to build shared libraries (see LOCAL_STATIC_LIBRARIES and LOCAL_WHOLE_STATIC_LIBRARIES, below). The syntax for using this variable is:
include $(BUILD_STATIC_LIBRARY)
A static-library variable causes the build system to generate a library with a .a extension.
PREBUILT_SHARED_LIBRARY
Points to a build script used to specify a prebuilt shared library. Unlike in the case of BUILD_SHARED_LIBRARY and BUILD_STATIC_LIBRARY, here the value of LOCAL_SRC_FILES cannot be a source file. Instead, it must be a single path to a prebuilt shared library, such as foo/libfoo.so. The syntax for using this variable is:
include $(PREBUILT_SHARED_LIBRARY)
You can also reference a prebuilt library in another module by using the LOCAL_PREBUILTS variable. For more information about using prebuilts, see Using Prebuilt Libraries.
PREBUILT_STATIC_LIBRARY
The same as PREBUILT_SHARED_LIBRARY, but for a prebuilt static library. For more information about using prebuilts, see Using Prebuilt Libraries.
TARGET_ARCH
The name of the target CPU architecture as the Android Open Source Project specifies it. For any ARM-compatible build, use arm, independent of the CPU architecture revision or ABI (see TARGET_ARCH_ABI, below).
The value of this variable is taken from the APP_ABI variable that you define in the Android.mk file, which the system reads ahead of parsing the Android.mk file.
TARGET_PLATFORM
The Android API level number for the build system to target. For example, the Android 5.1 system images correspond to Android API level 22: android-22. For a complete list of platform names and corresponding Android system images, see Android NDK Native APIs. The following example shows the syntax for using this variable:
TARGET_PLATFORM := android-22
TARGET_ARCH_ABI
This variable stores the name of the CPU and architecture to target when the build system parses this Android.mk file. You can specify one or more of the following values, using a space as a delimiter between multiple targets. Table 1 shows the ABI setting to use for each supported CPU and architecture.
Table 1. ABI settings for different CPUs and architectures.
| CPU and architecture | Setting |
| ARMv5TE | armeabi |
| ARMv7 | armeabi-v7a |
| ARMv8 AArch64 | arm64-v8a |
| i686 | x86 |
| x86-64 | x86_64 |
| mips32 (r1) | mips |
| mips64 (r6) | mips64 |
| All | all |
The following example shows how to set ARMv8 AArch64 as the target CPU-and-ABI combination:
TARGET_ARCH_ABI := arm64-v8a
Note: Up to Android NDK 1.6_r1, this variable is defined as arm.
For more details about architecture ABIs and associated compatibility issues, refer to ABI Management.
New target ABIs in the future will have different values.
TARGET_ABI
A concatenation of target Android API level and ABI, it is especially useful when you want to test against a specific target system image for a real device. For example, to specify a 64-bit ARM device running on Android API level 22:
TARGET_ABI := android-22-arm64-v8a
Note: Up to Android NDK 1.6_r1, the default value was android-3-arm.
Module-Description Variables
参考
Android.mk https://developer.android.com/ndk/guides/android_mk.html#var
Android.mk
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。