Android 编译系统之Android.bp

从Android 7.0 (N)开始, Google开始逐步使用Android.bp代替原来的Android.mk进行编译.
Google称之为soong, 具体可以参考:
https://android.googlesource.com/platform/build/soong

使用Android.bp编译时, 目前还存在一些问题:
1.对C/C++代码, 如果需要使用宏开关时, 由于android整个编译系统还没完全切换过来, 导致 在项目mk文件定义的开关, 还不能生效.
2.对于条件编译, 需要添加go文件进行控制.

对于问题1, 一是通过export命令, 把相应的开关设置到环境变量, go文件就能读取到了.
二是, 把开关集中放到某一个文件中, 然后在go文件中直接读取这个文件.
对于问题2, 下面会通过例子给出一个说明.
下面是一个libsysutils模块Android.bp的内容: libsysutils_defaults以上及相关内容是新添加关键部分, 用来支持go文件进行条件编译. 如果想让TLV_FEATURE_ENABLED起作用, 需要export TLV_FEATURE_ENABLED=yes.

Android.bp:

bootstrap_go_package {
    name: "soong-libsysutils",
    pkgPath: "android/soong/system/core/libsysutils",
    deps: [
        "blueprint",
        "blueprint-pathtools",
        "soong",
        "soong-android",
        "soong-cc",
        "soong-genrule",
    ],
    srcs: [
        "libsysutils.go",
    ],
    pluginFor: ["soong_build"],
}

libsysutils_defaults {
    name: "libsysutils_defaults",
}
cc_library_shared {
    name: "libsysutils",
    vendor_available: true,

    defaults: [
        "libsysutils_defaults",
    ],

    srcs: [
        "src/SocketListener.cpp",
        "src/FrameworkListener.cpp",
        "src/NetlinkListener.cpp",
        "src/NetlinkEvent.cpp",
        "src/FrameworkCommand.cpp",
        "src/SocketClient.cpp",
        "src/ServiceManager.cpp",
    ],

    logtags: ["EventLogTags.logtags"],

    cflags: ["-Werror"],

    shared_libs: [
        "libbase",
        "libcutils",
        "liblog",
        "libnl",
    ],

    export_include_dirs: ["include"],
}

下面是对应的libsysutils.go文件内容, fmt模块是用来调试的, 完成之后可以删除.

package libsysutils

import (
    "android/soong/android"
    "android/soong/cc"
    "github.com/google/blueprint"
    "fmt"
)

func globalDefaults(ctx android.BaseContext) ([]string) {
    var cflags []string

    fmt.Println("TLV_FEATURE_ENABLED:", 
        ctx.AConfig().IsEnvTrue("TLV_FEATURE_ENABLED"))
    if ctx.AConfig().IsEnvTrue("TLV_FEATURE_ENABLED") {
            cflags = append(cflags, "-DTLV_FEATURE_ENABLED")
    }

    return cflags
}

func libsysutilsDefaults(ctx android.LoadHookContext) {
    type props struct {
    Cflags []string
    }
   p := &props{}
   p.Cflags = globalDefaults(ctx)
   ctx.AppendProperties(p)
}

func init() {
    fmt.Println("libsysutils: init")
    android.RegisterModuleType("libsysutils_defaults", 
        libsysutilsDefaultsFactory)
}

func libsysutilsDefaultsFactory() (blueprint.Module, []interface{}) {
    module, props := cc.DefaultsFactory()
    android.AddLoadHook(module, libsysutilsDefaults)
    fmt.Println("libsysutils: libsysutilsDefaultsFactory")
    return module, props
}

有些同学可能不能访问google网站, 把内容附在了下面:
Soong

Soong is the replacement for the old Android make-based build system. It replaces Android.mk files with Android.bp files, which are JSON-like simple declarative descriptions of modules to build.

Android.bp file format

By design, Android.bp files are very simple. There are no conditionals or control flow statements - any complexity is handled in build logic written in Go. The syntax and semantics of Android.bp files are intentionally similar to Bazel BUILD files when possible.

Modules

A module in an Android.bp file starts with a module type, followed by a set of properties in name: value, format:

cc_binary {
name: “gzip”,
srcs: [“src/test/minigzip.c”],
shared_libs: [“libz”],
stl: “none”,
}
Every module must have a name property, and the value must be unique across all Android.bp files.

For a list of valid module types and their properties see $OUT_DIR/soong/.bootstrap/docs/soong_build.html.

Variables

An Android.bp file may contain top-level variable assignments:

gzip_srcs = [“src/test/minigzip.c”],

cc_binary {
name: “gzip”,
srcs: gzip_srcs,
shared_libs: [“libz”],
stl: “none”,
}
Variables are scoped to the remainder of the file they are declared in, as well as any child blueprint files. Variables are immutable with one exception - they can be appended to with a += assignment, but only before they have been referenced.

Comments

Android.bp files can contain C-style multiline /* */ and C++ style single-line // comments.

Types

Variables and properties are strongly typed, variables dynamically based on the first assignment, and properties statically by the module type. The supported types are:

Bool (true or false)
Strings (“string”)
Lists of strings ([“string1”, “string2”])
Maps ({key1: “value1”, key2: [“value2”]})
Maps may values of any type, including nested maps. Lists and maps may have trailing commas after the last value.

Operators

Strings, lists of strings, and maps can be appended using the + operator. Appending a map produces the union of keys in both maps, appending the values of any keys that are present in both maps.

Defaults modules

A defaults module can be used to repeat the same properties in multiple modules. For example:

cc_defaults {
name: “gzip_defaults”,
shared_libs: [“libz”],
stl: “none”,
}

cc_binary {
name: “gzip”,
defaults: [“gzip_defaults”],
srcs: [“src/test/minigzip.c”],
}
Formatter

Soong includes a canonical formatter for blueprint files, similar to gofmt. To recursively reformat all Android.bp files in the current directory:

bpfmt -w .
The canonical format includes 4 space indents, newlines after every element of a multi-element list, and always includes a trailing comma in lists and maps.

Convert Android.mk files

Soong includes a tool perform a first pass at converting Android.mk files to Android.bp files:

androidmk Android.mk > Android.bp
The tool converts variables, modules, comments, and some conditionals, but any custom Makefile rules, complex conditionals or extra includes must be converted by hand.

Differences between Android.mk and Android.bp

Android.mk files often have multiple modules with the same name (for example for static and shared version of a library, or for host and device versions). Android.bp files require unique names for every module, but a single module can be built in multiple variants, for example by adding host_supported: true. The androidmk converter will produce multiple conflicting modules, which must be resolved by hand to a single module with any differences inside target: { android: { }, host: { } } blocks.
Build logic

The build logic is written in Go using the blueprint framework. Build logic receives module definitions parsed into Go structures using reflection and produces build rules. The build rules are collected by blueprint and written to a ninja build file.

FAQ

How do I write conditionals?

Soong deliberately does not support conditionals in Android.bp files. Instead, complexity in build rules that would require conditionals are handled in Go, where high level language features can be used and implicit dependencies introduced by conditionals can be tracked. Most conditionals are converted to a map property, where one of the values in the map will be selected and appended to the top level properties.

For example, to support architecture specific files:

cc_library {
…
srcs: [“generic.cpp”],
arch: {
arm: {
srcs: [“arm.cpp”],
},
x86: {
srcs: [“x86.cpp”],
},
},
}
See art/build/art.go or external/llvm/soong/llvm.go for examples of more complex conditionals on product variables or environment variables.