目录
1. 编译流程
Google 提供的原生 Android 编译流程:
-
初始化编译环境
进入 android 源代码根目录执行以下命令即可初始化编译环境。
source build/envsetup.sh
该过程主要是执行了 envsetup.sh 脚本且加载环境变量到当前终端。执行成功之后可以在当前终端执行 envsetup.sh 中定义的命令 (函数名) 来执行这些函数的内容,最后调用函数 source_vendorsetup 加载其他目录 (device/vendor/product) 下的 vendorsetup.sh 脚本。
-
lunch 选择平台
在 Android 根目录下执行 lunch 命令来选择当前编译平台,该命令可以直接跟上参数,也可以直接让其显示菜单让我们选择。lunch 函数定义在 envsetup.sh 中。
这里有一个疑问,就是当前平台定义的 product 是怎么获得的呢?可以查看 envsetup.sh 中定义的 print_lunch_menu 函数。在这个函数中调用 get_build_var,并传递参数 COMMON_LUNCH_CHOICES 来获取当前所有平台,COMMON_LUNCH_CHOICES 被定义在 AndroidProducts.mk 中。
-
开始编译
以上两步执行完之后,可以使用 make 或者 mm 等命令进行编译,但是他们的流程有差异。按照 linux 的 Makefile 机制,make 命令是直接执行当前目录下的 makefile 脚本,在 Android 系统中首先会判断有没有 soong_ui.bash 脚本,如果有则用 soong 编译系统,否则使用 Makefile 机制。m 、mm 或者 mmm 这些命令是 Android 在 envsetup.sh 中定义的。
在 Android 7.0 之后 google 采用了 soong 编译系统,直接执行当前目录下的 android.mk 或者 android.bp 脚本。(实际上还是使用 Makefile 机制进行编译,只是 google 做了封装)
-
make 命令
function make(){ _wrap_build $(get_make_command "$@") "$@"}function get_make_command(){ # If we're in the top of an Android tree, use soong_ui.bash instead of make if [ -f build/soong/soong_ui.bash ]; then # Always use the real make if -C is passed in for arg in "$@"; do if [[ $arg == -C* ]]; then echo command make return fi done echo build/soong/soong_ui.bash --make-mode else echo command make fi}
-
m / mm / mmm / mmma 命令
// 编译整个安卓系统function m()( _trigger_build "all-modules" "$@")// 编译当前目录下的模块,当前目录下需要有 Android.mk, 否则就往上找最近的 Android.mk 文件function mm()( _trigger_build "modules-in-a-dir-no-deps" "$@")// 编译指定目录下的模块function mmm()( _trigger_build "modules-in-dirs-no-deps" "$@")// 当前目录有修改时,可以用这个命令重新编译function mma()( _trigger_build "modules-in-a-dir" "$@")// 指定目录有修改时,可以用这个命令重新编译function mmma()( _trigger_build "modules-in-dirs" "$@")function _trigger_build()( local -r bc="$1"; shift if T="$(gettop)"; then _wrap_build "$T/build/soong/soong_ui.bash" --build-mode --${bc} --dir="$(pwd)" "$@" else >&2 echo "Couldn't locate the top of the tree. Try setting TOP." return 1 fi)
-
2. Soong 介绍
随着 Android 项目的逐渐庞大复杂,包含的模块增加。通过 Makefile 组织的项目编译要花更多的时间。Google 在 Android 7 引入了 ninja 进行编译系统的组织。目前 Android 项目中还在继续使用 Makefile 机制进行编译,因此 Google 引入了 kati ( soong) 将 makefile(Android.mk) 翻译成 ninja 文件。
Android 7.0 开始逐步引入kati soong (未正式使用默认关闭,需要 USE_SOONG=true 手动开启),将 makefile 文件和 Android.mk 文件转化成 ninja 文件,使用 ninja 文件对编译系统进行管理。
Android 8.0 开始引入了 Android.bp 文件来替代之前的 Android.mk 文件。Android.bp 只是纯粹的配置文件(类似json),不包括分支、循环等流程控制 (如果想要进行分支循环控制可自己写 go 来完成),因此 Android.bp 文件被转化成 ninja 文件的效率远远高于 Android.mk 文件。
Android 9.0 开始强制使用 Android.bp 来代替 Android.mk。
-
Soong工作原理
Soong源代码路径位于 /android/build/soong/ ,从前面说的 envsetup.sh 可以看到目前的 Android 代码编译命令 ( make / m / mm / mmm) 都基本上使用的该目录下的 soong_ui.bash 来进行代码编译。主要涉及到如下流程:
- Android.mk 转换成 ninja 文件:soong_ui.bash 将指定目录下的所有 Android.mk (包括makefile) 文件转换成 out/build-
.ninja 文件 - Android.bp 转换成 ninja 文件:soong_ui.bash 将指定目录下所有的 Android.bp 文件也转换成 out/soong/build.ninja 文件
- 组合 nijia 文件:soong_ui.bash 还会生成一个较小的 out/combined-
.ninja 文件,负责把二者组合起来作为执行入口 - Soong 根据 nijia 来控制源码编译
- Android.mk 转换成 ninja 文件:soong_ui.bash 将指定目录下的所有 Android.mk (包括makefile) 文件转换成 out/build-
- 术语介绍
- Android.mk:Android.mk 其本质是执行 envsetup.sh 之后,编译系统对 makefile 进行了一层封装,让开发者更加简单的使用 makefile。因此可直接把他当成 makefile 看待。
- Android.bp:Android.bp 的出现就是为了替换 Android.mk 文件。bp 跟 mk 文件不同,它是纯粹的配置,没有分支、循环等流程控制,不能做算数逻辑运算。如果需要控制逻辑,那么只能通过Go语言编写。
- Ninja:ninja 是一个编译框架,会根据相应的 ninja 格式的配置文件进行编译。 ninja 文件一般是由 Android.bp 或 Android.mk 文件转换来的。
- Kati:专为 Android 开发的一个基于 Golang 和 C++ 的工具,主要功能是把 Android 中的 Android.mk 文件转换成 Ninja 文件。
- Soong:Soong 类似于之前的 Makefile 编译系统的核心,负责提供 Android.bp 语义解析,并将之转换成 Ninja 文件。Soong 还会编译生成一个 androidmk 命令,用于将没有分支、循环等流程控制的 Android.mk 文件转换为 Android.bp 文件。
- Blueprint:Blueprint 是生成、解析 Android.bp 的工具,是 Soong 的一部分。Blueprint 只是解析文件格式,Soong 解析内容的具体含义。Blueprint 和 Soong 都是由 Golang 写的项目,从Android 7.0,prebuilts/go/ 目录下新增 Golang 所需的运行环境,在编译时使用。
- androidmk:androidmk 是 Soong 提供的一套可直接通过命令的方式将一个 android.mk 生成一个对应的 android.bp。通常开发者需要手动替换 Android.mk 的时候用到。
3. build.sh
全编命令
./build.sh fullbuild
具体编译过程后续再补充。
Android.mk 文件是用来描述 Android 的工程源码如何被构建系统来构建的。
语法概述
-
定义当前模块的位置
LOCAL_PATH := $(call my-dir)
每个 Android.mk 文件必须在文件头部最开始处定义 LOCAL_PATH 变量,该变量用来获取工程中的文件节点。
LOCAL_PATH 是表示当前模块位置的变量,my-dir 是由系统提供的宏函数,返回当前文件所在的路径,$(call my-dir) 表示调用这个函数。
-
清除 LOCAL_XXX 变量
include $(CLEAR_VARS)
这句代码清除了 LOCAL_PATH 变量之外的 LOCAL_XXX 变量。所有的编译控制文件都在同一个 GNU MAKE 执行环境中,所有的变量都是全局的,在编译该模块之前可能编译过别的模块,产生了大量变量,会被系统误认为是属于该模块的,可能产生不可预知的错误。
-
需要编译的文件
LOCAL_SRC_FILES := $(call all-subdir-java-files)
LOCAL_SRC_FILES 变量代表需要编译的文件,all-subdir-java-files 函数返回 LOCAL_PATH 子目录的所有 java文件。
也可以直接写出需要编译的文件路径:
LOCAL_SRC_FILES :=src/com/example/test/MainActivity.java \ src/com/example/test/Demo1.java \ src/com/example/test/Demo2.java // 需要在文件最后面加上以下语句,指明 LOCAL_PATH 目录。 include $(call all-java-file-under,$(LOCAL_PATH))
或者每个文件路径下都加上 LOCAL_PATH :
LOCAL_SRC_FILES :=$(LOCAL_PATH)/src/com/example/test/MainActivity.java \ $(LOCAL_PATH)/src/com/example/test/Demo1.java \ $(LOCAL_PATH)/src/com/example/test/Demo2.java
几个常用的获取源文件的方法:
$(call all-java-files-under, src)
:获取指定目录下的所有 Java 文件。
$(call all-c-files-under, src)
:获取指定目录下的所有 C 语言文件。
$(call all-Iaidl-files-under, src)
:获取指定目录下的所有 AIDL 文件。
$(call all-makefiles-under, folder)
:获取指定目录下的所有 Make 文件。 -
定义编译生成的模块名称
LOCAL_PACKAGE_NAME := TestMK
LOCAL_PACKAGE_NAME 变量必须定义且唯一,作为模块的标识,编译系统会自动产生合适的前缀和后缀。
-
编译的标签
LOCAL_MODULE_TAGS := optional
常用的有:debug, eng, user, development 或者 optional(默认)。
-
签名属性
LOCAL_CERTIFICATE := platform
常用的有:
platform:该 APK 完成一些系统的核心功能。经过对系统中存在的文件夹的访问测试。
shared:该APK需要和 home/contacts 进程共享数据。
media:该APK是 media/download 系统中的一环。
testkey:普通APK,默认情况下使用。 -
引用 jar 包
// 引用静态 jar 包LOCAL_STATIC_JAVA_LIBRARIES := jar1 jar2// 引用动态 jar 包LOCAL_JAVA_LIBRARIES := jar3
-
编译类型
// 编译 APKinclude $(BUILD_PACKAGE)// 编译成静态库include $(BUILD_STATIC_LIBRARY)// 编译成动态库include $(BUILD_SHARED_LIBRARY)// 编译成可执行程序include $(BUILD_EXECUTABLE)// 编译成Java静态库include $(BUILD_STATIC_JAVA_LIBRARY)
-
拷贝到本地编译
将 prebuild 定义的库拷到本地进行编译。
include $(BUILD_MULTI_PREBUILT)
-
指定生成目录
通过 LOCAL_MODULE_PATH 变量,可以指定生成的 apk 目录。
LOCAL_MODULE_PATH := $(TARGET_OUT)/
$(TARGET_OUT)
代表 /system , 后续路劲按需要补充完整。$(TARGET_OUT_DATA_APPS)
代表 data/app 目录。
Android.bp 描述的编译对象都是以模块为组织单位的,定义一个模块从模块的类型开始,模块有不同的类型,模块包含一些属性。
[module type] { name: "[name value]", [property1 name]:"[property1 value]", [property2 name]:"[property2 value]",}
1. 模块类型
cc_binary:编译二进制可执行文件。
android_app:编译APK。
cc_library_shared:编译动态库。
更多模块类型(build/soong/androidmk/androidmk/android.go):
var moduleTypes = map[string]string{ "BUILD_SHARED_LIBRARY": "cc_library_shared", "BUILD_STATIC_LIBRARY": "cc_library_static", "BUILD_HOST_SHARED_LIBRARY": "cc_library_host_shared", "BUILD_HOST_STATIC_LIBRARY": "cc_library_host_static", "BUILD_HEADER_LIBRARY": "cc_library_headers", "BUILD_EXECUTABLE": "cc_binary", "BUILD_HOST_EXECUTABLE": "cc_binary_host", "BUILD_NATIVE_TEST": "cc_test", "BUILD_HOST_NATIVE_TEST": "cc_test_host", "BUILD_NATIVE_BENCHMARK": "cc_benchmark", "BUILD_HOST_NATIVE_BENCHMARK": "cc_benchmark_host", "BUILD_JAVA_LIBRARY": "java_library_installable", // will be rewritten to java_library by bpfix "BUILD_STATIC_JAVA_LIBRARY": "java_library", "BUILD_HOST_JAVA_LIBRARY": "java_library_host", "BUILD_HOST_DALVIK_JAVA_LIBRARY": "java_library_host_dalvik", "BUILD_PACKAGE": "android_app", "BUILD_RRO_PACKAGE": "runtime_resource_overlay", "BUILD_CTS_EXECUTABLE": "cc_binary", // will be further massaged by bpfix depending on the output path "BUILD_CTS_SUPPORT_PACKAGE": "cts_support_package", // will be rewritten to android_test by bpfix "BUILD_CTS_PACKAGE": "cts_package", // will be rewritten to android_test by bpfix "BUILD_CTS_TARGET_JAVA_LIBRARY": "cts_target_java_library", // will be rewritten to java_library by bpfix "BUILD_CTS_HOST_JAVA_LIBRARY": "cts_host_java_library", // will be rewritten to java_library_host by bpfix}
soong 提供了一系列 xx_defaults 模块类型 (cc_defaults, java_defaults, doc_defaults, stub_defaults 等)。
模块类型为 xx_defaults 的模块提供了一组可由其它模块继承的属性。其它模块可以通过添加属性
defaults:[“
来指定继承 xx_defaults 类型的模块定义的属性。”]
cc_defaults { name: "gzip_defaults", shared_libs: ["libz"], stl: "none",} cc_binary { name: "gzip", defaults: ["gzip_defaults"], srcs: ["src/test/minigzip.c"],}
2. 模块属性
模块类型后面用大括号 { }
将模块的所有属性包裹起来。
每个属性的名字和值用中间用冒号连接起来, 属性值要用双引号 ” ”
包裹起来 (如果属性值是变量,变量不需要加双引号)。
如果属性被定义为数组,需要用中括号 [ ]
将数组的各元素包裹起来,每个元素中间用逗号 ,
连接。
属性可以使用列表数组的形式,也可以使用 unix 通配符,例如:*.java
。
每一条完整的属性定义语句加上逗号 ,
表示结束。
注释包括单行注释//
和多行注释
-
name:name 属性是必须的,内容必须是独一无二的。对应 Adroid.mk 的 LOCAL_PACKAGE_NAME 。
-
srcs:源码路径。对应 Adroid.mk 的 LOCAL_SRC_FILES。
-
resource_dirs:资源文件路径。对应 Adroid.mk 的 LOCAL_RESOURCE_DIR。
-
static_libs:以来的 java 库。对应 Adroid.mk 的 LOCAL_STATIC_JAVA_LIBRARIES 和 LOCAL_STATIC_LIBRARIES。
-
certificate:签名属性。对应 Adroid.mk 的 LOCAL_CERTIFICATE。
Google 提供了 androidmk 工具可以将 Android.mk 转换为 Android.bp。但是这个工具目前还不完善,不能处理 Android.mk 中的宏开关。
1. androidmk 介绍
androidmk 的源码在 build/soong/androidmk 目录下。
全编 Android 源码之后,可以使用 find . -name androdmk -type f
查找 androidmk 工具,他在 out/host/linux-x86/bin 目录。
2. androidmk 用法
androidmk 可以将 Android.mk 文件 转换为 Android.bp 文件。
androidmk Android.mk > Android.bp
3. 示例
1. 创建工程
在 Android Studio 中创建一个新的工程。工程名为 CompileTest。创建成功之后 Android Studio 会自动帮我们生成基本的代码框架。
通常情况下,我们创建的工程主要的实现逻辑和资源文件在 main 目录中。把这部分代码移动到 Android 源码中的 package/apps 目录,注意不要遗漏掉 AndroidManifest.xml 文件。
2. 编写编译文件
-
Android.mk
LOCAL_PATH := $(call my-dir)include $(CLEAR_VARS)LOCAL_PACKAGE_NAME := CompileTestLOCAL_CERTIFICATE := platformLOCAL_SRC_FILES := $(call all-subdir-java-files)LOCAL_RESOURCE_DIR := $(LOCAL_PATH)/resLOCAL_SDK_VERSION := currentLOCAL_STATIC_ANDROID_LIBRARIES := androidx.appcompat_appcompat // Theme Packageinclude $(BUILD_PACKAGE)
-
Android.bp
这里使用 androidmk 命令自动生成 Android.bp 文件。
androidmk Android.mk > Android.bp
生成的 Android.bp 文件。
android_app { name: "CompileTest", certificate: "platform", srcs: ["***.java"], sdk_version: "current", static_libs: ["androidx.appcompat_appcompat", "androidx-constraintlayout_constraintlayout", ],}
Android.mk 文件
LOCAL_PATH := $(call my-dir)include $(CLEAR_VARS)LOCAL_PACKAGE_NAME := CompileTestLOCAL_CERTIFICATE := platformLOCAL_SRC_FILES := $(call all-subdir-java-files)LOCAL_RESOURCE_DIR := $(LOCAL_PATH)/resLOCAL_SDK_VERSION := currentLOCAL_STATIC_ANDROID_LIBRARIES := androidx.appcompat_appcompat \ androidx-constraintlayout_constraintlayoutinclude $(BUILD_PACKAGE)
使用 Android.mk 编译会以下错误。
Attribute provider#androidx.startup.InitializationProvider@authorities value=(androidx.appcompat.androidx-startup) from AndroidManifest.xml:34:13-70 is also present at AndroidManifest.xml:19:13-84 value=(androidx.constraintlayout.widget.androidx-startup).Suggestion: add 'tools:replace="android:authorities"' to
element at AndroidManifest.xml.fixed:32:9-43:20 to override. 尝试在 AndroidManifest.xml 添加 tools:replace 属性。
<manifest xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" package="com.example.compiletest"> <application android:allowBackup="true" android:dataExtractionRules="@xml/data_extraction_rules" android:fullBackupContent="@xml/backup_rules" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:roundIcon="@mipmap/ic_launcher_round" android:supportsRtl="true" android:theme="@style/Theme.CompileTest" tools:targetApi="31" > <activity android:name=".MainActivity" android:exported="true" > <intent-filter> <action android:name="android.intent.action.MAIN" /> // Add tools:replace 属性<provider tools:replace="android:authorities" tools:ignore="WrongManifestParent"/> <category android:name="android.intent.category.LAUNCHER" /> intent-filter> <meta-data android:name="android.app.lib_name" android:value="" /> activity> application>manifest>
再次编译又会出现以下新的错误。
packages/apps/CompileTest/app/src/main/AndroidManifest.xml:22:21-23:61 Error:tools:replace specified at line:22 for attribute android:authorities, but no new value specifiedpackages/apps/CompileTest/app/src/main/AndroidManifest.xml Error:Validation failed, exiting
看 log 似乎是 android:authorities 属性没有值,这里不知道怎么给这个属性赋值。以后再补充。
来源地址:https://blog.csdn.net/qq_43880417/article/details/128311478