Great question! If you’ve spent time working with the old Android Makefile system, you know how unwieldy it could get for large, complex projects. Soong was built to fix that—let’s break down how it works and what those Android.bp files are all about.

一、Soong的工作原理 #

Soong is Google’s custom build system tailored specifically for Android, designed to replace the legacy Makefile-based system. Here’s a step-by-step breakdown of its workflow:

• Core Dependencies: It relies on two key tools:
  • Blueprint: A domain-specific language (DSL) used to write build configurations (that’s where Android.bp comes in).
  • Ninja: A fast, lightweight build executor that handles the actual compilation tasks. Soong doesn’t compile code directly—it generates optimized Ninja build scripts.
• Build Flow:
  1. Parse Configuration: Soong scans your project for Android.bp files, parses their Blueprint DSL syntax, and builds a graph of all modules (libraries, binaries, APKs, etc.) and their dependencies.
  2. Generate Ninja Scripts: Using the module graph, Soong generates a set of Ninja files that define exactly how to compile each module, handle dependencies, and manage incremental builds.
  3. Execute Build: Finally, Ninja runs the generated scripts, leveraging its speed at parallel execution and incremental builds to compile the project efficiently.
• Key Advantages Over Makefiles:
  • Better support for Android’s multi-architecture builds (arm, x86, etc.)
  • Cleaner, more modular configuration syntax
  • Faster incremental builds (Ninja excels at this)
  • Built-in support for modern Android components like APEX modules and Android App Bundles

二、Android.bp文件的具体含义与作用 #

Android.bp is the heart of Soong’s configuration—think of it as the modern replacement for Android.mk. Here’s what you need to know:

What it is #

It’s a text file written in Blueprint’s concise DSL, used to define build modules and their properties. Each module represents a single build target (a shared library, executable, APK, etc.).

Core Roles #

• Define Build Targets: Every Android.bp file declares one or more modules, specifying what type of artifact to build (e.g., cc_library for a C/C++ shared library, android_app for an APK).
• Specify Dependencies: You list other modules (libraries, frameworks) that your target depends on, so Soong knows to build those first.
• Configure Compilation: Set parameters like source files, include paths, compiler flags, output directories, and architecture-specific settings.
• Modularize Configuration: Unlike Makefiles, which could get tangled with conditional logic, Blueprint lets you use templates, variables, and conditional blocks to keep configurations clean and reusable.

Example Android.bp File #

Here’s a simple example of a C/C++ shared library definition:

cc_library {
    name: "libmyutils",
    srcs: ["src/utils.c", "src/logger.c"],
    includes: ["include/"],
    shared_libs: ["liblog"],
    cflags: ["-Wall", "-Wextra"],
    target: {
        android: {
            cflags: ["-DANDROID_BUILD"],
        },
    },
}

Let’s break down the key fields:

• name: The unique identifier for the module (other modules will reference this name to declare dependencies).
• srcs: List of source files to compile for the module.
• includes: Paths to header directories needed for compilation.
• shared_libs: Shared libraries this module depends on (in this case, Android’s logging library).
• cflags: Compiler flags to pass to the C/C++ compiler.
• target.android: Architecture/OS-specific overrides (here, adding a define for Android builds).

Bonus: Advanced Features #

• Variables: Define reusable values at the top of the file, like common_srcs = ["src/common.c"], then reference them in modules.
• Templates: Create reusable module templates with default properties, then extend them in other modules (using template: "mytemplate").
• Conditional Logic: Use if/else blocks to adjust configurations based on build variables (e.g., if (target.os == "android")).

内容的提问来源于stack exchange，提问作者Midhun PM