2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
Android.bp ファイル形式
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Android.bp
ファイルの設計はシンプルです。条件文または制御フロー文は含まれません。すべての複雑性は、Go で記述されたビルドロジックによって処理されます。Android.bp
ファイルの構文とセマンティクスは、可能な範囲で Bazel BUILD ファイル を模倣しています。
モジュール
Android.bp
ファイル内のモジュールは、最初がモジュール タイプで、次に name: "value",
形式のプロパティのセットが続きます。
cc_binary {
name: "gzip",
srcs: ["src/test/minigzip.c"],
shared_libs: ["libz"],
stl: "none",
}
すべてのモジュールには name
プロパティが必要であり、値はすべての Android.bp
ファイル全体で一意でなければなりません。ただし、名前空間と事前ビルド済みモジュールの name
プロパティ値は例外です(繰り返し可能です)。
srcs
プロパティでは、モジュールのビルドに使用するソースファイルを文字列のリストとして指定します。モジュールの参照構文 ":<module-name>"
を使用することで、ソースファイルを生成する他のモジュール(genrule
や filegroup
など)の出力を参照できます。
有効なモジュール タイプとそのプロパティのリストについては、Soong モジュール リファレンスをご覧ください。
型
変数とプロパティは厳格に型付けされます。変数は最初の割り当てに基づいて動的に型付けされ、プロパティはモジュール タイプによって静的に設定されます。サポートされる型は次のとおりです。
- ブール値(
true
または false
)
- 整数(
int
)
- 文字列(
"string"
)
- 文字列のリスト(
["string1", "string2"]
)
- マップ(
{key1: "value1", key2: ["value2"]}
)
マップには、ネストされたマップを含む、任意の型の値を含めることが可能です。リストとマップでは、最後の値の後にカンマが付くことがあります。
glob
ファイルのリストを取得するプロパティ(srcs
など)は glob パターンも取得できます。glob パターンには、通常の UNIX ワイルドカード *
を使用できます(例: *.java
)。glob パターンには、パス要素として単一の **
ワイルドカードを指定できます。これはゼロ個以上のパス要素に一致します。たとえば、java/**/*.java
は java/Main.java
と java/com/android/Main.java
の両方のパターンに一致します。
変数
Android.bp
ファイルには、以下のように最上位の変数割り当てが含まれる場合があります。
gzip_srcs = ["src/test/minigzip.c"],
cc_binary {
name: "gzip",
srcs: gzip_srcs,
shared_libs: ["libz"],
stl: "none",
}
変数のスコープは、変数が宣言されたファイルの残りの部分と、子ブループリント ファイルに限定されます。変数は 1 つの例外を除いて不変です。その例外とは、変数が参照される前に限り、+=
による代入を使用して変数を先頭に付加できる場合です。
Android.bp
ファイルには、C スタイルの複数行コメント(/* */
)と C++ スタイルの単一行コメント(//
)を記述できます。
演算子
+ 演算子を使用して、文字列、文字列のリスト、マップを先頭に付加できます。
また、+
演算子を使用して、整数を加算できます。マップを先頭に付加すると両方のマップのキーが結合され、両方のマップに存在するすべてのキーの値が先頭に付加されます。
条件文
Soong は、Android.bp
ファイルの条件文をサポートしていません。代わりに、条件文を必要とするビルドルールの複雑性は Go で処理されます。Go では高度な言語機能を使用でき、条件文によって導入される暗黙的な依存関係をトラッキングできます。ほとんどの条件文は map プロパティに変換され、マップ内の値の 1 つが選択され、最上位のプロパティの先頭に付加されます。
たとえば、アーキテクチャ固有のファイルをサポートするには、次のようにします。
cc_library {
...
srcs: ["generic.cpp"],
arch: {
arm: {
srcs: ["arm.cpp"],
},
x86: {
srcs: ["x86.cpp"],
},
},
}
Soong には、gofmt に似たブループリント ファイル用の正規フォーマッタが含まれています。現在のディレクトリ内の Android.bp
ファイルをすべて再帰的に再フォーマットするには、次のコマンドを実行します。
bpfmt -w .
正規フォーマットには、4 個のスペースのインデント、複数要素リストの各要素の後の改行、リストとマップの末尾のカンマなどがあります。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-04-09 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-04-09 UTC。"],[],[],null,["# Android.bp file format\n\nBy design, `Android.bp` files are simple. They don't contain conditionals or\ncontrol flow statements; all complexity is handled by build logic written in\nGo. When possible, the syntax and semantics of `Android.bp` files are similar to\n[Bazel BUILD files](https://bazel.build/reference/be/overview).\n\n### Modules\n\nA module in an `Android.bp` file starts with a\n[module type](https://ci.android.com/builds/latest/branches/aosp-build-tools/targets/linux/view/soong_build.html)\nfollowed by a set of properties in `name: \"value\",` format: \n\n cc_binary {\n name: \"gzip\",\n srcs: [\"src/test/minigzip.c\"],\n shared_libs: [\"libz\"],\n stl: \"none\",\n }\n\nEvery module must have a `name` property, and the value must be unique across\nall `Android.bp` files, except for the `name` property values in\nnamespaces and prebuilt modules, which may repeat.\n\nThe `srcs` property specifies the source files used to build the module, as a\nlist of strings. You can reference the output of other modules that produce\nsource files, like `genrule` or `filegroup`, by using the module reference\nsyntax `\":\u003cmodule-name\u003e\"`.\n\nFor a list of valid module types and their properties, see the\n[Soong Modules Reference](https://ci.android.com/builds/latest/branches/aosp-build-tools/targets/linux/view/soong_build.html).\n\n### Types\n\nVariables and properties are strongly typed, with variables dynamically based on\nthe first assignment, and properties set statically by the module type. The\nsupported types are:\n\n- Booleans (`true` or `false`)\n- Integers (`int`)\n- Strings (`\"string\"`)\n- Lists of strings (`[\"string1\", \"string2\"]`)\n- Maps (`{key1: \"value1\", key2: [\"value2\"]}`)\n\nMaps may contain values of any type, including nested maps. Lists and maps may\nhave trailing commas after the last value.\n\n### Globs\n\nProperties that take a list of files, such as `srcs`, can also take glob\npatterns. Glob patterns can contain the normal UNIX wildcard `*`, for example\n`*.java`. Glob patterns can also contain a single `**` wildcard as a path\nelement, which matches zero or more path elements. For example,\n`java/**/*.java` matches both the `java/Main.java` and\n`java/com/android/Main.java` patterns.\n\n### Variables\n\nAn `Android.bp` file may contain top-level variable assignments: \n\n gzip_srcs = [\"src/test/minigzip.c\"],\n cc_binary {\n name: \"gzip\",\n srcs: gzip_srcs,\n shared_libs: [\"libz\"],\n stl: \"none\",\n }\n\nVariables are scoped to the remainder of the file they are declared in, as well\nas any child Blueprint files. Variables are immutable with one exception: they\ncan be appended to with a `+=` assignment, but only before they've been\nreferenced.\n\n### Comments\n\n`Android.bp` files can contain C-style multiline `/* */` and C++ style\nsingle-line `//` comments.\n\n### Operators\n\nStrings, lists of strings, and maps can be appended using the + operator.\nIntegers can be summed up using the `+` operator. Appending a map produces the\nunion of keys in both maps, appending the values of any keys that are present in\nboth maps.\n\n### Conditionals\n\nSoong doesn't support conditionals in `Android.bp` files. Instead,\ncomplexity in build rules that would require conditionals are handled in Go,\nwhere high-level language features can be used, and implicit dependencies\nintroduced by conditionals can be tracked. Most conditionals are converted to a\nmap property, where one of the values in the map is selected and appended\nto the top-level properties.\n\nFor example, to support architecture-specific files: \n\n cc_library {\n ...\n srcs: [\"generic.cpp\"],\n arch: {\n arm: {\n srcs: [\"arm.cpp\"],\n },\n x86: {\n srcs: [\"x86.cpp\"],\n },\n },\n }\n\n### Formatter\n\nSoong includes a canonical formatter for Blueprint files, similar to\n[gofmt](https://golang.org/cmd/gofmt/). To recursively reformat all\n`Android.bp` files in the current directory, run: \n\n bpfmt -w .\n\nThe canonical format includes four-space indents, new lines after every element\nof a multielement list, and a trailing comma in lists and maps."]]