Android.bp file format

By design, Android.bp files are simple. They don't contain conditionals or control flow statements; all complexity is handled by build logic written in Go. When possible, the syntax and semantics of Android.bp files are similar to Bazel BUILD files.

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, except for the name property values in namespaces and prebuilt modules, which may repeat.

The srcs property specifies the source files used to build the module, as a list of strings. You can reference the output of other modules that produce source files, like genrule or filegroup, by using the module reference syntax ":<module-name>".

For a list of valid module types and their properties, see the Soong Modules Reference.

Types

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

  • Booleans (true or false)
  • Integers (int)
  • Strings ("string")
  • Lists of strings (["string1", "string2"])
  • Maps ({key1: "value1", key2: ["value2"]})

Maps may contain values of any type, including nested maps. Lists and maps may have trailing commas after the last value.

Globs

Properties that take a list of files, such as srcs, can also take glob patterns. Glob patterns can contain the normal UNIX wildcard *, for example *.java. Glob patterns can also contain a single ** wildcard as a path element, which matches zero or more path elements. For example, java/**/*.java matches both the java/Main.java and java/com/android/Main.java patterns.

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've been referenced.

Comments

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

Operators

Strings, lists of strings, and maps can be appended using the + operator. Integers can be summed up 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.

Conditionals

Soong doesn't 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 is 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"],
        },
    },
}

Formatter

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

bpfmt -w .

The canonical format includes four-space indents, new lines after every element of a multielement list, and a trailing comma in lists and maps.