Android.bp学习笔记

一、概述

Android.bp是Android构建系统（Android Build System）中的核心配置文件，用于定义模块（Module）及其依赖关系，以及模块的构建配置选项。从Android 7.0（Nougat）开始，Android希望用Android.bp替换Android.mk，以提供更加灵活和高效的模块管理方式。从Android 8.0（Oreo）开始，Android.bp默认开启，成为主要的构建配置文件。

二、基本结构

在Android的构建系统中，Android.bp 文件是 Blueprint 构建系统配置文件的一种，用于定义Android平台上的构建模块。Blueprint 是Google为了提升Android构建速度和灵活性而开发的一种新的构建系统，旨在替代旧的Makefile和Android.mk系统。

2.1. 基本结构

Android.bp 文件通过定义不同的模块（如可执行文件、库等）来组织构建逻辑。每个模块定义通常包含以下部分：

• 模块类型函数：如 cc_binary, cc_library, java_library 等，用于指定模块的类型。
• 模块名称：每个模块都必须有一个唯一的名称，通常使用 name 属性来指定。
• 源文件和资源：指定构建该模块所需的源文件、头文件、资源文件等。例如，srcs 属性用于指定C/C++源文件。
• 构建标志和选项：包括编译器标志（如 cflags）、链接器标志（如 ldflags）等，用于控制构建过程。
• 依赖关系：指定当前模块依赖的其他模块或库。

2.2. 示例

1. C/C++ 二进制文件：

cc_binary {  
    name: "my_binary",  
    srcs: ["main.cpp"],  
    cflags: ["-Wall"],  
    shared_libs: ["liblog", "libcutils"],  
}

在这个例子中，定义了一个名为 my_binary 的C/C++二进制模块，它包含了一个源文件 main.cpp，使用了 -Wall 编译器标志来开启所有警告，并依赖于 liblog 和 libcutils 这两个共享库。

2. C/C++ 库：

cc_library {  
    name: "my_library",  
    srcs: ["lib.cpp", "helper.cpp"],  
    shared_libs: ["libutils"],  
    static_libs: ["libbase"],  
    stl: "none",  
}

这里定义了一个名为 my_library 的C/C++库，它由 lib.cpp 和 helper.cpp 两个源文件组成，依赖于 libutils 共享库和 libbase 静态库，并指定不使用STL（标准模板库）。

3. Java 库：

java_library {  
    name: "my_java_library",  
    srcs: ["src/**/*.java"],  
    resource_dirs: ["res"],  
    static_deps: ["//other/package:other_java_library"],  
}

这个示例定义了一个Java库 my_java_library，它包含了 src 目录下的所有Java源文件，并指定了一个资源目录 res。它还依赖于另一个Java库 other_java_library。

Android.bp 文件通过模块化的方式组织构建逻辑，每个模块都有明确的类型、源文件、构建选项和依赖关系。这种结构使得构建过程更加清晰和可管理，同时也提高了构建速度和灵活性。

三、常用属性

在Android的Soong构建系统（通过Android.bp文件）中，常用属性可以帮助构建系统了解如何编译和链接模块。

• name：这是模块的唯一标识符。在构建系统中，每个模块都必须有一个唯一的名称，以便可以引用它。
• srcs：指定模块的源文件列表。这可以是一个或多个文件的路径，它们将被编译成模块的一部分。对于C++模块，这通常是.cpp文件；对于Java模块，则可能是.java文件。
• cflags：这些是传递给编译器的标志（flags），用于控制编译过程。例如，-Wall用于启用所有警告，-Werror用于将警告视为错误。这些标志将应用于模块的所有源文件。
• shared_libs：指定模块依赖的动态库（共享库）列表。这些库在运行时被加载，并且模块中的代码可以调用这些库中的函数。在Android上，这通常包括系统库（如liblog、libcutils）或自己构建的其他共享库。
• static_libs：指定模块依赖的静态库列表。与共享库不同，静态库在编译时被直接链接到模块中，因此它们的代码和数据成为模块二进制文件的一部分。这通常用于库之间的内部依赖，或者当需要将库完全嵌入到应用程序中时。
• include_dirs：指定编译器在搜索头文件时应包含的目录列表。这对于找到模块依赖的其他库的头文件特别有用。如果模块的头文件位于非标准位置，或者模块依赖于其他模块的头文件，则需要使用此属性。
• target：这个属性可能不直接对应于Android.bp文件中的一个标准属性，因为它更多地与构建系统的目标或变体（variants）相关。然而，在Android构建系统中，可能会遇到针对不同目标平台或架构（如arm64-v8a、x86）的特定编译配置。这通常通过定义不同的模块变体或在构建配置中设置条件来实现，而不是通过单一的target属性。

对于针对不同目标平台或架构的编译，Android构建系统使用产品变量（product variables）和蓝图（Blueprint）语言中的条件语句来管理不同的构建配置。

请注意，Android.bp文件的语法和可用属性可能会随着Android版本和构建系统的更新而发生变化。因此，建议查阅最新的Android官方文档以获取最准确的信息。

四、高级功能

在Android的Blueprint构建系统中，高级功能如条件编译、变量定义与使用以及模块继承为构建过程提供了更大的灵活性和可重用性。

4.1 条件编译

条件编译允许根据不同的目标环境（如不同的CPU架构、操作系统版本等）来编译不同的代码或配置不同的编译选项。在Android.bp文件中，可以通过target关键字来定义针对特定目标的配置。

示例：

cc_binary {  
    name: "my_binary",  
    srcs: ["main.cpp"],  
    cflags: ["-Wall"],  
    target: {  
        android_arm: {  
            cflags: ["-DANDROID_ARM"],  
        },  
        android_x86: {  
            cflags: ["-DANDROID_X86"],  
        },  
        // 可以添加更多目标配置  
    },  
}

在这个例子中，根据目标平台（android_arm或android_x86），编译器会分别定义ANDROID_ARM或ANDROID_X86宏。这允许在代码中根据这些宏进行条件编译。

4.2 变量定义与使用

在Android.bp文件中定义变量可以减少重复配置，使得构建文件更加简洁和易于维护。可以定义变量来存储常见的配置（如编译标志、源文件列表等），然后在需要的地方引用这些变量。

示例：

my_flags = ["-Wall", "-Werror"]  
cc_binary {  
    name: "my_binary",  
    srcs: ["main.cpp"],  
    cflags: my_flags,  
}

在这个例子中，my_flags变量被定义并包含了两个编译标志。然后，在定义cc_binary模块时，cflags属性引用了这个变量。

4.3 模块继承

模块继承允许定义一个或多个包含公共配置的cc_defaults模块，其他模块可以通过defaults属性继承这些配置。这有助于减少配置重复，使构建文件更加模块化和可维护。

示例：

cc_defaults {  
    name: "common_settings",  
    cflags: ["-Wall"],  
    static_libs: ["libcommon"],  
}  
  
cc_library {  
    name: "libexample1",  
    defaults: ["common_settings"],  
    srcs: ["example1.cpp"],  
}  
  
cc_library {  
    name: "libexample2",  
    defaults: ["common_settings"],  
    srcs: ["example2.cpp"],  
}

在这个例子中，common_settings模块定义了所有需要libcommon静态库和-Wall编译标志的C/C++库所共有的配置。然后，libexample1和libexample2通过defaults属性继承了这些配置，并分别指定了它们自己的源文件。这样，如果将来需要更改这些公共配置，只需在common_settings中更新它们，而无需在每个单独的模块中进行更改。

五、工具与转换

在Android构建系统中，bpfmt和androidmk是两个重要的工具，它们分别用于Blueprint文件的格式化和Android.mk到Android.bp的转换。

5.1. bpfmt：Blueprint文件格式化工具

• 功能描述：bpfmt是一个用于格式化Blueprint文件的工具，它的作用类似于Go语言的gofmt工具。Blueprint是Android构建系统中用于解析Android.bp文件的语言，而bpfmt确保这些文件的格式保持一致性和可读性。
• 使用方法：使用bpfmt可以递归地格式化当前目录及其子目录下的所有Blueprint文件。通常，开发者会在编写或修改Android.bp文件后运行bpfmt，以确保文件的格式符合规范。
• 示例命令：格式化当前目录下的所有Blueprint文件：bpfmt -w .

5.2. androidmk：Android.mk到Android.bp的转换工具

• 功能描述：androidmk是一个转换工具，用于将基于Makefile的Android.mk文件转换为基于Blueprint的Android.bp文件。这个工具对于需要将旧项目迁移到新的Soong构建系统的开发者来说非常有用。
• 注意事项：然而，需要注意的是，androidmk的转换过程可能不是完全自动化的。对于包含复杂控制逻辑（如条件编译、循环等）的Android.mk文件，转换后可能需要手动调整Android.bp文件以确保其正确性和完整性。
• 使用方法：通常，androidmk工具会在Android源代码树的构建环境中提供。开发者需要先设置好Android源代码树的构建环境，然后通过命令行运行androidmk并指定要转换的Android.mk文件。
• 示例命令：假设Android.mk文件位于当前目录下，则可以使用类似androidmk Android.mk > Android.bp的命令来生成Android.bp文件。但请注意，这只是一个示例命令，实际使用时需要根据具体情况进行调整。

bpfmt和androidmk是Android构建系统中两个重要的工具，它们分别用于Blueprint文件的格式化和Android.mk到Android.bp的转换。通过这两个工具，开发者可以更方便地管理和迁移项目构建配置，从而提高开发效率。

六、编译流程

Android.bp文件的编译流程是Android构建系统中的一个关键环节，它涉及从Blueprint和Soong的解析到Ninja构建系统的执行。以下是详细的编译流程。

6.1. Blueprint和Soong解析

• Android.bp文件：这是Android构建系统（Blueprint + Soong）的配置文件，用于定义模块的构建规则。它包含了模块的名称、源文件、依赖关系、编译选项等信息。
• Blueprint：Blueprint是Soong中的一个配置语言，用于解析Android.bp文件。它定义了构建过程中的规则和约束条件，使得构建系统能够理解和处理这些文件。
• Soong：Soong是Android构建系统的一个组件，它取代了旧有的Android.mk构建系统。Soong使用Blueprint来解析Android.bp文件，并将其转换为Ninja的构建规则文件（通常是.ninja文件）。

6.2. 生成Ninja构建文件

• 在Soong解析完Android.bp文件后，它会生成Ninja的构建规则文件。这些文件包含了Ninja构建系统所需的所有信息，如构建命令、依赖关系、输出文件等。
• Ninja构建文件（如build.ninja）是Ninja构建系统的输入，它定义了构建过程中需要执行的具体任务和这些任务之间的依赖关系。

6.3. Ninja构建系统执行

• Ninja：Ninja是一个小型而高效的构建系统，由Google员工Evan Martin开发。它专注于构建速度，并设计为尽可能快地运行构建。
• 执行构建：在Ninja构建系统获取到构建规则文件后，它会根据这些文件来执行构建任务。Ninja会处理模块之间的依赖关系，确保以正确的顺序构建每个模块。
• 编译和链接：在构建过程中，Ninja会调用编译器（如GCC、Clang）和链接器（如ld）来编译源代码和链接库文件。这些操作会生成最终的可执行文件、库文件或APK文件。

6.4. 输出结果

• 构建完成后，Ninja会在指定的输出目录下生成构建结果。这些结果可能包括APK文件、系统镜像、库文件等。
• 开发人员可以在输出目录中找到这些文件，并进行进一步的测试或分发。

Android.bp文件的编译流程是一个从Blueprint和Soong解析到Ninja构建系统执行的过程。这个流程通过定义模块的构建规则、生成Ninja构建文件和执行构建任务来构建Android系统或应用程序。整个过程旨在提高构建速度和灵活性，同时保持构建过程的清晰和可维护性。

七、总结

Android.bp文件在Android构建系统中确实扮演着至关重要的角色。它作为Blueprint和Soong构建系统的一部分，提供了一种灵活且高效的模块定义和管理方式。通过Android.bp文件，开发者能够清晰地定义每个模块的源代码、依赖关系、编译选项等，从而实现对项目构建过程的精细控制。

这种模块化的管理方式带来了多个显著优势：

• 提高构建效率：通过明确定义模块之间的依赖关系，构建系统能够智能地决定哪些模块需要被重新编译，从而避免了不必要的重复编译，提高了构建效率。
• 增强代码可维护性：Android.bp文件将构建配置与源代码分离，使得代码更加清晰和易于维护。同时，模块化的设计也使得项目结构更加合理，便于团队成员之间的协作。
• 支持多平台构建：Android.bp文件支持条件编译和平台特定的配置，使得同一个项目能够轻松适配不同的Android设备和平台，降低了跨平台开发的复杂性和成本。
• 集成新特性和改进：随着Android编译系统的不断演进，Android.bp文件格式和Blueprint/Soong构建系统本身也在不断完善和优化。这使得Android.bp文件能够更好地支持新特性和改进，满足日益复杂的Android应用和系统构建需求。

综上所述，Android.bp文件是Android构建系统中不可或缺的一部分，它通过提供灵活且高效的模块管理方式，为开发者带来了诸多便利和优势。随着Android技术的不断发展，我们可以期待Android.bp文件格式和构建系统的进一步演进和完善。