Android のルール

問題を報告 ソースを表示 夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

ルール

• android_binary
• aar_import
• android_library
• android_instrumentation_test
• android_local_test
• android_device
• android_ndk_repository
• android_sdk_repository

android_binary

ルールのソースを表示

android_binary(name, deps, srcs, assets, assets_dir, compatible_with, crunch_png, custom_package, debug_key, debug_signing_keys, debug_signing_lineage_file, densities, deprecation, dex_shards, dexopts, distribs, enable_data_binding, exec_compatible_with, exec_properties, features, incremental_dexing, instruments, javacopts, key_rotation_min_sdk, licenses, main_dex_list, main_dex_list_opts, main_dex_proguard_specs, manifest, manifest_values, multidex, nocompress_extensions, package_id, plugins, proguard_apply_dictionary, proguard_apply_mapping, proguard_generate_mapping, proguard_specs, resource_configuration_filters, resource_files, restricted_to, shrink_resources, tags, target_compatible_with, testonly, visibility)

Android アプリ パッケージ ファイル（.apk）を生成します。

暗黙的な出力ターゲット

• name.apk: Android アプリ 署名付きのパッケージ ファイルです。 zipaligned しているため、アプリの開発とデバッグに使用できます。 デバッグキーで署名されたアプリはリリースできません。
• name_unsigned.apk: ファイルの署名なしバージョン リリースキーで署名できる上記のファイルを 公開されています。
• name_deploy.jar: ファイルを含む Java アーカイブ ターゲットの推移的クロージング

  deploy jar には、Deployment によって見つかる このターゲットのランタイム クラスパスを検索したクラスローダー サポートします

• name_proguard.jar: 次を含む Java アーカイブ で ProGuard を実行した結果を name_deploy.jar。 この出力は、次の場合にのみ生成されます。 proguard_specs 属性が あります。
• name_proguard.map: マッピング ファイルの結果。 name_deploy.jar で ProGuard を実行する。 この出力は、次の場合にのみ生成されます。 proguard_specs 属性が 指定され、 proguard_generate_mapping または shrink_resources が設定されている。

例

Android のルールの例は、Android アプリの examples/android ディレクトリにあります。 Bazel ソースツリー。

引数

属性
name	名前:必須 このターゲットの一意の名前。
deps	ラベルのリスト。デフォルトは [] です バイナリ ターゲットにリンクする他のライブラリのリスト。 許可されるライブラリ タイプ: android_library、 java_library（android 制約あり）と cc_library のラッピングまたは .so ネイティブ ライブラリの作成 Android ターゲット プラットフォーム。
srcs	ラベルのリスト。デフォルトは [] です ターゲットを作成するために処理されるソースファイルのリスト。 .java タイプの srcs ファイルがコンパイルされます。 読みやすくするために、名前は付けないでください。 生成された .java ソースファイルを srcs に読み込みます。 代わりに、次のように、依存するルール名を srcs に入れます。 以下で説明します。 .srcjar タイプの srcs ファイルが解凍され、 コンパイルします。（これは、同じ名前で .java ファイルを生成し、 genrule または build 拡張機能）。
assets	ラベルのリスト。デフォルトは [] です パッケージ化するアセットのリスト。 これは通常、組織内の全ファイルの glob です。 assets ディレクトリ。また、他のルール（特定の文字列を生成する 他のパッケージにエクスポートされたファイルなど、それらのファイルはすべて 対応するパッケージの assets_dir ディレクトリ。
assets_dir	String;デフォルトは "" です。 assets 内のファイルへのパスを指定する文字列。 assets と assets_dir のペアは、パッケージ化された記述を示します。 両方の属性を指定するか、いずれも指定しないかのどちらかです。
crunch_png	ブール値デフォルトは True です。 PNG 自動最適化を行う（またはしない）。これは、常に実行される 9-patch 処理とは無関係です。 できます。これはサポートが終了した aapt バグ aapt2 で修正されました。
custom_package	String;デフォルトは "" です。 Java ソースが生成される Java パッケージ。 デフォルトでは、パッケージは BUILD ファイルが格納されているディレクトリから推測されます。 表示されます。別のパッケージを指定することもできますが、 他のリソースとクラスパスの競合が発生する可能性があるため、推奨されません。 実行時にのみ検出されるライブラリが含まれています。
debug_key	ラベル:デフォルトは "@bazel_tools//tools/android:debug_keystore" です デバッグ APK の署名に使用されるデバッグ キーストアを含むファイル。通常は デフォルトの鍵以外の鍵を使用する場合は、この属性を省略します。 警告: 本番環境のキーは使用しないでください。使用するのは、 厳格に保護され、ソースツリーに保持されません。
debug_signing_keys	ラベルのリスト。デフォルトは [] です ファイルのリスト、デバッグ APK の署名に使用されるデバッグ キーストア。通常は デフォルトの鍵以外の鍵を使用する場合は、この属性を省略します。 警告: 本番環境のキーは使用しないでください。使用するのは、 厳格に保護され、ソースツリーに保持されません。
debug_signing_lineage_file	ラベル:デフォルトは None です debug_signing_keys の署名リネージを含むファイル。通常は デフォルトの鍵以外の鍵を使用する場合は、この属性を省略します。 警告: 本番環境のキーは使用しないでください。使用するのは、 厳格に保護され、ソースツリーに保持されません。
densities	文字列のリスト。デフォルトは [] です。 APK のビルド時にフィルタする密度。 これにより、次の要件を満たすデバイスでは読み込めないラスター ドローアブル リソースが削除されます。 APK のサイズを小さくするために、指定した画面密度に応じて調整します。対応する対応画面 セクションがまだスーパーセットが含まれていない場合は、マニフェストにも追加されます 表示されます。
dex_shards	整数デフォルトは 1 です。 dex 変換を分解する必要があるシャードの数。 これにより、dex 変換が非常に高速になりますが、アプリのインストール時間と起動時間が犠牲になります。「 バイナリが大きいほど、より多くのシャードを使用する必要があります。最初は 25 がおすすめです あります。 最終的なアプリでは、シャードごとに少なくとも 1 つの dex が生成されます。このため、 リリース バイナリでは、この値を 1 より大きい値に設定することはおすすめしません。
dexopts	文字列のリスト。デフォルトは [] です。 class.dex の生成時の dx ツールの追加コマンドライン フラグ。 「変数を作成」による置換を適用し、 Bourne シェルのトークン化。
enable_data_binding	ブール値デフォルトは False です。 true の場合、このルールは データ バインディング式をレイアウト リソースに resource_files 属性を使用します。これなし 設定すると、データ バインディング式はビルドエラーになります。 データ バインディングを使用して Android アプリを作成するには、次のことも行う必要があります。 この属性に推移的に依存するすべての Android ルールに、この属性を設定します。 これは、依存者がリソースを通じてルールのデータ バインディング式を継承するためです。 行います。そのため、データ バインディングを使用してこれらの式を解析する必要もあります。 データ バインディング ランタイム ライブラリの deps = エントリをすべてのターゲットに追加する 必要があります。このライブラリの場所は、デポの設定によって異なります。
incremental_dexing	整数設定不可デフォルトは -1 です 増分 dex 変換の有無にかかわらずターゲットを強制的にビルドし、デフォルトのオーバーライドを行う 「--incremental_dexing」フラグを指定します。
instruments	ラベル:デフォルトは None です 計測する android_binary ターゲット。 この属性が設定されている場合、この android_binary がテストとして扱われます インストルメンテーション テスト用のアプリです。android_instrumentation_test 作成されたら、そのターゲットを test_app 属性。
javacopts	文字列のリスト。デフォルトは [] です。 このターゲット用の追加のコンパイラ オプション。 「変数を作成」による置換を適用し、 Bourne シェルのトークン化。 これらのコンパイラ オプションは、グローバル コンパイラ オプションの後に javac に渡されます。
key_rotation_min_sdk	String;デフォルトは "" です。 APK のローテーションされた署名の対象となる Android プラットフォームの最小バージョン（API レベル）を設定します 鍵を使用して APK の署名を生成する必要があります。APK の元の署名鍵 以前のすべてのプラットフォーム バージョンで使用されます。
main_dex_list	ラベル:デフォルトは None です テキスト ファイルには、クラスファイル名のリストが含まれています。これらのクラスファイルで定義されたクラスは、 宣言します。e.g.: android/support/multidex/MultiDex$V19.class android/support/multidex/MultiDex.class android/support/multidex/MultiDexApplication.class com/google/common/base/Objects.class multidex="manual_main_dex" と併用する必要があります。
main_dex_list_opts	文字列のリスト。デフォルトは [] です。 メインの dex リストビルダーに渡すコマンドライン オプション。 このオプションを使用すると、メインの dex リストに含まれるクラスに影響します。
main_dex_proguard_specs	ラベルのリスト。デフォルトは [] です 保持する必要があるクラスを決定するために ProGuard の仕様として使用されるファイル 必要があります。 multidex 属性が legacy に設定されている場合にのみ許可されます。
manifest	ラベル:必須 Android マニフェスト ファイルの名前（通常は AndroidManifest.xml）。 resource_files または assets が定義されている場合は定義する必要があります。
manifest_values	辞書: 文字列 ->String;デフォルトは {} です。 マニフェストでオーバーライドされる値のディクショナリ。 マニフェスト内の ${name} のインスタンスはすべて、次の値に置き換えられます。 対応する単語リストが返されます。 applicationId さん、versionCode さん、versionName さん、 minSdkVersion、targetSdkVersion、 maxSdkVersion は、マニフェスト内の対応する属性もオーバーライドします と uses-sdk タグを使用します。 packageName は無視され、次のいずれかから設定されます applicationId（指定されている場合）、またはマニフェスト内のパッケージ。 manifest_merger が legacy に設定されている場合: applicationId、versionCode、versionName のアクション 影響します。
multidex	String;デフォルトは "native" です。 コードを複数の dex ファイルに分割するかどうか。 可能な値: native: dex 64K のインデックス制限がある場合に、コードを複数の dex ファイルに分割 超えています。実行時に multidex クラスを読み込むためのネイティブ プラットフォーム サポートを前提とします。 この機能は Android L 以降でのみ動作します。 legacy: dex 64K のインデックス制限がある場合に、コードを複数の dex ファイルに分割 超えています。multidex クラスはアプリケーション コードを介して読み込まれる（つまり ネイティブ プラットフォームのサポート）。 manual_main_dex: dex 64K が dex 64K の場合に、コードを複数の dex ファイルに分割 インデックスの上限を超えています。メインの dex ファイルのコンテンツは、 main_dex_list 属性。 off: すべてのコードを 1 つの dex ファイルにコンパイルします。ファイル インデックス上限。
nocompress_extensions	文字列のリスト。デフォルトは [] です。 apk に圧縮しないファイル拡張子のリスト。
package_id	整数デフォルトは 0 です。 このバイナリ内のリソースに割り当てるパッケージ ID。 詳しくは、AAPT2 の --package-id 引数をご覧ください。これにより、 未設定のままにすると、通常はデフォルト値の 127 になります。 （0x7F）。
plugins	ラベルのリスト。デフォルトは [] です コンパイル時に実行する Java コンパイラ プラグイン。 期間指定 java_plugin ごと プラグイン属性が実行時に 作成されます。生成するリソース プラグインは terraform.tfvars.json、 ターゲットです。
proguard_apply_dictionary	ラベル:デフォルトは None です ProGuard のマッピングとして使用するファイル。 「単語」の行区切りファイルクラスやメンバーの名前を変更する際に pull できる 難読化されています。
proguard_apply_mapping	ラベル:デフォルトは None です ProGuard のマッピングとして使用するファイル。 proguard_generate_mapping によって生成されたマッピング ファイル。 新しいビルドに同じマッピングを適用するために再利用されます。
proguard_generate_mapping	ブール値設定不可デフォルトは False です ProGuard マッピング ファイルを生成するかどうか。 マッピング ファイルは、proguard_specs が次の場合にのみ生成されます。 あります。このファイルには、元のバージョンと 難読化されたクラス、メソッド、フィールド名。 警告: この属性を使用すると、ProGuard は 仕様には、-dontobfuscate と -printmapping。
proguard_specs	ラベルのリスト。デフォルトは [] です ProGuard 仕様として使用されるファイル。 このファイルには、Proguard で使用される一連の仕様を記述します。
resource_configuration_filters	文字列のリスト。デフォルトは [] です。 リソース構成フィルタのリスト（「en」など）クラスタ内のリソースを制限することで 「en」のできます。疑似ローカライズを有効にするには、 en_XA および/または ar_XB 架空言語
resource_files	ラベルのリスト。デフォルトは [] です パッケージ化するリソースのリスト。 これは通常、組織内の全ファイルの glob です。 res ディレクトリ。 （genrules から）生成されたファイルは、次によって参照できます: ここでもラベルを付けます。唯一の制限は 生成された出力は同じ「res」の下に存在する必要があります他のディレクトリと同様に、 リソース ファイルが含まれます。
shrink_resources	整数デフォルトは -1 です。 リソース圧縮を実行するかどうか。バイナリで使用されていないリソースには APK から削除しました。これは、ローカル リソース（ manifest 属性や resource_files 属性など）があり、ProGuard が必要です。 Gradle リソース圧縮ツールとほぼ同じように動作する (https://developer.android.com/studio/build/shrink-code.html#shrink-resources). 主な違い: values/ のリソースとファイルベースのリソースが削除されます リソース デフォルトで strict mode を使用 未使用の ID リソースの削除は aapt2 でのみサポートされています リソース圧縮が有効になっている場合は、name_files/resource_shrinker.log 実行された分析と削除の詳細が示されます。 可能な値: shrink_resources = 1: Android リソースの圧縮を有効にします shrink_resources = 0: Android リソースの圧縮を無効にします。 shrink_resources = -1: 圧縮は --android_resource_shrinking フラグも追加しています。

aar_import

ルールのソースを表示

aar_import(name, deps, data, aar, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, licenses, restricted_to, srcjar, tags, target_compatible_with, testonly, visibility)

このルールでは、.aar ファイルを次のライブラリとして使用できます。 android_library と android_binary 個のルール。

例

    aar_import(
        name = "google-vr-sdk",
        aar = "gvr-android-sdk/libraries/sdk-common-1.10.0.aar",
    )

    android_binary(
        name = "app",
        manifest = "AndroidManifest.xml",
        srcs = glob(["**.java"]),
        deps = [":google-vr-sdk"],
    )

引数

属性
name	名前:必須 このターゲットの一意の名前。
aar	ラベル:必須 このターゲットに依存する Android ターゲットに提供する .aar ファイル。
exports	ラベルのリスト。デフォルトは [] です このルールに依存するルールにエクスポートするターゲット。 詳細については、java_library.exports.
srcjar	ラベル:デフォルトは None です AAR 内のコンパイル済み JAR ファイルのソースコードを含む JAR ファイル。

android_library

ルールのソースを表示

android_library(name, deps, srcs, data, assets, assets_dir, compatible_with, custom_package, deprecation, distribs, enable_data_binding, exec_compatible_with, exec_properties, exported_plugins, exports, exports_manifest, features, idl_import_root, idl_parcelables, idl_preprocessed, idl_srcs, javacopts, licenses, manifest, neverlink, plugins, proguard_specs, resource_files, restricted_to, tags, target_compatible_with, testonly, visibility)

このルールは、ソースを .jar ファイルにコンパイルしてアーカイブします。 Android ランタイム ライブラリ android.jar が暗黙的に配置される コンパイル クラスパスを指定します。

暗黙的な出力ターゲット

• libname.jar: Java アーカイブ。
• libname-src.jar: ソース（「ソース JAR」）を入力します。
• name.aar: Android の「aar」Java アーカイブを含むバンドル リソースを管理できます。推移的クロージャは含まれていない。

例

Android のルールの例は、Android アプリの examples/android ディレクトリにあります。 Bazel ソースツリー。

以下の例は、 idl_import_root の設定方法 //java/bazel/helloandroid/BUILD に以下を含めます。

android_library(
    name = "parcelable",
    srcs = ["MyParcelable.java"], # bazel.helloandroid.MyParcelable

    # MyParcelable.aidl will be used as import for other .aidl
    # files that depend on it, but will not be compiled.
    idl_parcelables = ["MyParcelable.aidl"] # bazel.helloandroid.MyParcelable

    # We don't need to specify idl_import_root since the aidl file
    # which declares bazel.helloandroid.MyParcelable
    # is present at java/bazel/helloandroid/MyParcelable.aidl
    # underneath a java root (java/).
)

android_library(
    name = "foreign_parcelable",
    srcs = ["src/android/helloandroid/OtherParcelable.java"], # android.helloandroid.OtherParcelable
    idl_parcelables = [
        "src/android/helloandroid/OtherParcelable.aidl" # android.helloandroid.OtherParcelable
    ],

    # We need to specify idl_import_root because the aidl file which
    # declares android.helloandroid.OtherParcelable is not positioned
    # at android/helloandroid/OtherParcelable.aidl under a normal java root.
    # Setting idl_import_root to "src" in //java/bazel/helloandroid
    # adds java/bazel/helloandroid/src to the list of roots
    # the aidl compiler will search for imported types.
    idl_import_root = "src",
)

# Here, OtherInterface.aidl has an "import android.helloandroid.CallbackInterface;" statement.
android_library(
    name = "foreign_interface",
    idl_srcs = [
        "src/android/helloandroid/OtherInterface.aidl" # android.helloandroid.OtherInterface
        "src/android/helloandroid/CallbackInterface.aidl" # android.helloandroid.CallbackInterface
    ],

    # As above, idl_srcs which are not correctly positioned under a java root
    # must have idl_import_root set. Otherwise, OtherInterface (or any other
    # interface in a library which depends on this one) will not be able
    # to find CallbackInterface when it is imported.
    idl_import_root = "src",
)

# MyParcelable.aidl is imported by MyInterface.aidl, so the generated
# MyInterface.java requires MyParcelable.class at compile time.
# Depending on :parcelable ensures that aidl compilation of MyInterface.aidl
# specifies the correct import roots and can access MyParcelable.aidl, and
# makes MyParcelable.class available to Java compilation of MyInterface.java
# as usual.
android_library(
    name = "idl",
    idl_srcs = ["MyInterface.aidl"],
    deps = [":parcelable"],
)

# Here, ServiceParcelable uses and thus depends on ParcelableService,
# when it's compiled, but ParcelableService also uses ServiceParcelable,
# which creates a circular dependency.
# As a result, these files must be compiled together, in the same android_library.
android_library(
    name = "circular_dependencies",
    srcs = ["ServiceParcelable.java"],
    idl_srcs = ["ParcelableService.aidl"],
    idl_parcelables = ["ServiceParcelable.aidl"],
)

引数

属性
name	名前:必須 このターゲットの一意の名前。
deps	ラベルのリスト。デフォルトは [] です リンクする他のライブラリのリスト。 許可されるライブラリ タイプ: android_library、 java_library（android 制約あり）と cc_library のラップまたは .so ネイティブ ライブラリの生成 実装することをおすすめします
srcs	ラベルのリスト。デフォルトは [] です 次の .java ファイルまたは .srcjar ファイルのリスト。 ターゲットが作成されます。 .java タイプの srcs ファイルがコンパイルされます。 読みやすくするために、名前は付けないでください。 生成された .java ソースファイルを srcs に読み込みます。 代わりに、次のように、依存するルール名を srcs に入れます。 以下で説明します。 .srcjar タイプの srcs ファイルが解凍され、 コンパイルします。（これは、同じ名前で .java ファイルを生成し、 genrule または build 拡張機能）。 srcs を省略すると、 このルールから depsがエクスポートされます（ 詳細については、java_library の書き出しをご覧ください。 依存関係のエクスポートに関する情報をご覧ください）。ただし この動作は まもなくサポート終了となります。頼らないことをおすすめします
assets	ラベルのリスト。デフォルトは [] です パッケージ化するアセットのリスト。 これは通常、組織内の全ファイルの glob です。 assets ディレクトリ。また、他のルール（特定の文字列を生成する 他のパッケージにエクスポートされたファイルなど、それらのファイルはすべて 対応するパッケージの assets_dir ディレクトリ。
assets_dir	String;デフォルトは "" です。 assets 内のファイルへのパスを指定する文字列。 assets と assets_dir のペアは、パッケージ化された記述を示します。 両方の属性を指定するか、いずれも指定しないかのどちらかです。
custom_package	String;デフォルトは "" です。 Java ソースが生成される Java パッケージ。 デフォルトでは、パッケージは BUILD ファイルが格納されているディレクトリから推測されます。 表示されます。別のパッケージを指定することもできますが、 他のリソースとクラスパスの競合が発生する可能性があるため、推奨されません。 実行時にのみ検出されるライブラリが含まれています。
enable_data_binding	ブール値デフォルトは False です。 true の場合、このルールは データ バインディング式をレイアウト リソースに resource_files 属性を使用します。これなし 設定すると、データ バインディング式はビルドエラーになります。 データ バインディングを使用して Android アプリを作成するには、次のことも行う必要があります。 この属性に推移的に依存するすべての Android ルールに、この属性を設定します。 これは、依存者がリソースを通じてルールのデータ バインディング式を継承するためです。 行います。そのため、データ バインディングを使用してこれらの式を解析する必要もあります。 データ バインディング ランタイム ライブラリの deps = エントリをすべてのターゲットに追加する 必要があります。このライブラリの場所は、デポの設定によって異なります。
exported_plugins	ラベルのリスト。デフォルトは [] です java_plugin のリスト（アノテーション このライブラリに直接依存するライブラリにエクスポートできます。 指定した java_plugin のリストは、次を実行するライブラリに適用されます。 このライブラリがこれらのライブラリを明示的に宣言しているかのように、 plugins のラベル。
exports	ラベルのリスト。デフォルトは [] です exports 属性で到達したすべてのルールの閉鎖 ルールの直接的な依存関係と見なされます。この制約は、 exports でターゲットを設定します。 exports は、所属するルールの直接の依存関係ではありません。
exports_manifest	整数デフォルトは 1 です。 マニフェスト エントリを android_binary ターゲットにエクスポートするかどうか 依存関係があります。uses-permissions 属性はエクスポートされません。
idl_import_root	String;デフォルトは "" です。 IDl を含む Java パッケージ ツリーのルートへのパッケージ相対パス ソースが表示されます。 このパスは、IDL ソースを処理するときにインポート ルートとして使用されます。 このライブラリに依存します idl_import_root を指定すると、idl_parcelables と idl_srcs は、オブジェクトの Java パッケージで指定されたパスに存在する必要があります。 idl_import_root 以下を表します。idl_import_root が次と一致する場合 指定しない場合は、idl_parcelables と idl_srcs は両方とも Java ルートの下にパッケージによって指定されたパスです。 <ph type="x-smartling-placeholder"></ph>をご覧ください。 例をご覧ください。
idl_parcelables	ラベルのリスト。デフォルトは [] です インポートとして提供する Android IDL 定義のリスト。 これらのファイルは、任意のプラットフォームで このライブラリに依存する android_library ターゲットを直接指定します Java には変換されません。ただし、Java には変換されません。 定義できます。 直接対応する .aidl ファイルのみ このライブラリの .java ソースをインクルードする必要があります（カスタム Parcelable の実装など）、それ以外の場合は idl_srcs を 分析できます これらのファイルは、aidl コンパイラが見つけられるよう適切に配置する必要があります。 idl_import_root の説明をご覧ください。 をご覧ください。
idl_preprocessed	ラベルのリスト。デフォルトは [] です インポートとして提供する、前処理済みの Android IDL 定義のリスト。 これらのファイルは、任意のプラットフォームで このライブラリに依存する android_library ターゲットを直接指定します Java には変換されません。ただし、Java には変換されません。 定義できます。 直接対応する .aidl ファイルのみを前処理しました。 このライブラリの .java ソースをインクルードする必要があります（カスタム Parcelable の実装）、それ以外の場合は idl_srcs を使用 Java インターフェースおよびコードに変換する必要のある Android IDL 定義 idl_parcelable を使用する 未処理の AIDL ファイルの場合は をご覧ください。
idl_srcs	ラベルのリスト。デフォルトは [] です Java インターフェースに変換する Android IDL 定義のリスト。 Java インターフェースの生成後、それらは一緒にコンパイルされます。 srcs の内容に置き換えます。 これらのファイルは、任意のプラットフォームで このライブラリに依存する android_library ターゲットを直接指定します その推移的クロージャによって行われます。 これらのファイルは、aidl コンパイラが見つけられるよう適切に配置する必要があります。 idl_import_root の説明をご覧ください。 をご覧ください。
javacopts	文字列のリスト。デフォルトは [] です。 このターゲット用の追加のコンパイラ オプション。 「変数を作成」による置換を適用し、 Bourne シェルのトークン化。 これらのコンパイラ オプションは、グローバル コンパイラ オプションの後に javac に渡されます。
manifest	ラベル:デフォルトは None です Android マニフェスト ファイルの名前（通常は AndroidManifest.xml）。 resource_files または assets が定義されている場合は定義する必要があります。
neverlink	ブール値デフォルトは False です。 このライブラリは、実行時ではなくコンパイル時のみに使用してください。 neverlink とマークされたルールの出力は、次では使用されません .apk の作成。ライブラリを提供する場合に便利 実行時の状態にします。
plugins	ラベルのリスト。デフォルトは [] です コンパイル時に実行する Java コンパイラ プラグイン。 期間指定 java_plugin ごと プラグイン属性が実行時に 作成されます。生成するリソース プラグインは terraform.tfvars.json、 ターゲットです。
proguard_specs	ラベルのリスト。デフォルトは [] です ProGuard 仕様として使用されるファイル。 ここでは、Proguard で使用される一連の仕様について説明します。指定すると、 このライブラリに応じて、任意の android_binary ターゲットに追加されます。 ここに含めるファイルには、べき等ルール（-dontnote、-dontwarn、 -keep で始まるルールを定義します。その他のオプションは android_binary の proguard_specs: tautological 以外のマージを保証します。
resource_files	ラベルのリスト。デフォルトは [] です パッケージ化するリソースのリスト。 これは通常、組織内の全ファイルの glob です。 res ディレクトリ。 （genrules から）生成されたファイルは、次によって参照できます: ここでもラベルを付けます。唯一の制限は 生成された出力は同じ「res」の下に存在する必要があります他のディレクトリと同様に、 リソース ファイルが含まれます。

android_instrumentation_test

ルールのソースを表示

android_instrumentation_test(name, data, args, compatible_with, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, licenses, local, restricted_to, shard_count, size, support_apks, tags, target_compatible_with, target_device, test_app, testonly, timeout, toolchains, visibility)

android_instrumentation_test ルールは、Android インストルメンテーション テストを実行します。動作 エミュレータを起動し、テスト対象のアプリケーションとテスト アプリケーションをインストールする テスト パッケージで定義されたテストを実行します。

test_app 属性は、 テストを含む android_binary。次にこのandroid_binaryが テスト対象の android_binary アプリを、 instruments 属性。

例

# java/com/samples/hello_world/BUILD

android_library(
    name = "hello_world_lib",
    srcs = ["Lib.java"],
    manifest = "LibraryManifest.xml",
    resource_files = glob(["res/**"]),
)

# The app under test
android_binary(
    name = "hello_world_app",
    manifest = "AndroidManifest.xml",
    deps = [":hello_world_lib"],
)

# javatests/com/samples/hello_world/BUILD

android_library(
    name = "hello_world_test_lib",
    srcs = ["Tests.java"],
    deps = [
      "//java/com/samples/hello_world:hello_world_lib",
      ...  # test dependencies such as Espresso and Mockito
    ],
)

# The test app
android_binary(
    name = "hello_world_test_app",
    instruments = "//java/com/samples/hello_world:hello_world_app",
    manifest = "AndroidManifest.xml",
    deps = [":hello_world_test_lib"],
)

android_instrumentation_test(
    name = "hello_world_uiinstrumentation_tests",
    target_device = ":some_target_device",
    test_app = ":hello_world_test_app",
)

引数

属性
name	名前:必須 このターゲットの一意の名前。
support_apks	ラベルのリスト。デフォルトは [] です インストルメンテーション テストの開始前にデバイスにインストールするその他の APK。
target_device	ラベル:必須 テストを実行する android_device。 すでに実行中のエミュレータまたは実機でテストを実行するには、次のコマンドを使用します。 これらの引数を使用します。 --test_output=streamed --test_arg=--device_broker_type=LOCAL_ADB_SERVER --test_arg=--device_serial_number=$device_identifier
test_app	ラベル:必須 テストクラスを含む android_binary ターゲット。 android_binary ターゲットには、テストに使用するターゲットを指定する必要があります その instruments 属性。

android_local_test

ルールのソースを表示

android_local_test(name, deps, srcs, data, args, compatible_with, custom_package, densities, deprecation, enable_data_binding, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, licenses, local, manifest, manifest_values, nocompress_extensions, plugins, resource_configuration_filters, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, visibility)

このルールは、android_library ルールをローカルで単体テストするためのものです 。 Android Robolectric テスト フレームワークと連携して動作します。 詳細については、Android Robolectric サイトをご覧ください。 Robolectric テストの作成に関するコースです。

暗黙的な出力ターゲット

• name.jar: テストの Java アーカイブ。
• name-src.jar: ソースを含むアーカイブ （「ソース JAR」）。
• name_deploy.jar: 適切な Java デプロイ アーカイブ （明示的にリクエストされた場合にのみビルドされます）。

例

android_local_test で Robolectric を使用するには、以下を追加します。 Robolectric の リポジトリを WORKSPACE ファイルに追加します。

http_archive(
    name = "robolectric",
    urls = ["https://github.com/robolectric/robolectric-bazel/archive/<COMMIT>.tar.gz"],
    strip_prefix = "robolectric-bazel-<COMMIT>",
    sha256 = "<HASH>",
)
load("@robolectric//bazel:robolectric.bzl", "robolectric_repositories")
robolectric_repositories()

これにより、Robolectric に必要な maven_jar ルールが取得されます。 この場合、各 android_local_test ルールは、 @robolectric//bazel:robolectric。下記の例をご覧ください。

android_local_test(
    name = "SampleTest",
    srcs = [
        "SampleTest.java",
    ],
    manifest = "LibManifest.xml",
    deps = [
        ":sample_test_lib",
        "@robolectric//bazel:android-all",
    ],
)

android_library(
    name = "sample_test_lib",
    srcs = [
         "Lib.java",
    ],
    resource_files = glob(["res/**"]),
    manifest = "AndroidManifest.xml",
)

引数

属性
name	名前:必須 このターゲットの一意の名前。
deps	ラベルのリスト。デフォルトは [] です テスト対象のライブラリのリストとリンクするその他のライブラリ 必要があります。 推移的ルールの Android ルールで宣言されているすべてのリソース、アセット、マニフェスト ファイル テストで利用できます。 deps で許可されるルールのリストは android_library です。 aar_import、java_import、java_library、 および java_lite_proto_library。
srcs	ラベルのリスト。デフォルトは [] です ターゲットを作成するために処理されるソースファイルのリスト。 以下で説明する特殊なケースを除き必須です。 .java タイプの srcs ファイルがコンパイルされます。 読みやすくするために、名前は付けないでください。 生成された .java ソースファイルを srcs に読み込みます。 代わりに、次のように、依存するルール名を srcs に入れます。 以下で説明します。 .srcjar タイプの srcs ファイルが解凍され、 コンパイルします。（これは、同じ名前で .java ファイルを生成し、 genrule または build 拡張機能）。 他のファイルはすべて無視され、 上記のファイル形式のファイルが少なくとも 1 つある。それ以外の場合 エラーが発生します。 srcs 属性は必須であり、空にすることはできません。ただし、次の場合を除きます。 runtime_deps が指定されている。
custom_package	String;デフォルトは "" です。 R クラスが生成される Java パッケージ。デフォルトでは、パッケージは そのルールを含む BUILD ファイルがあるディレクトリから移動します。この属性を使用すると、 通常は test_class も使用する必要があります。
densities	文字列のリスト。デフォルトは [] です。 APK のビルド時にフィルタする密度。対応する対応画面 セクションがマニフェストにまだ追加されていない場合は、自動的にマニフェストに追加されます スーパーセットの StarlarkListing です。
enable_data_binding	ブール値デフォルトは False です。 true の場合、このルールは データ データ バインディングで使用されているバインディングの参照のうち、このテストで使用された依存関係が有効になっている必要があります。なし この設定では、データ バインディングの依存関係には必要なバイナリレベルのコード生成が行われません。 ビルドエラーが発生することがあります
javacopts	文字列のリスト。デフォルトは [] です。 このライブラリの追加のコンパイラ オプション。 「変数を作成」による置換を適用し、 Bourne シェルのトークン化。 これらのコンパイラ オプションは、グローバル コンパイラ オプションの後に javac に渡されます。
jvm_flags	文字列のリスト。デフォルトは [] です。 このバイナリを実行するために生成されたラッパー スクリプトに埋め込むフラグのリスト。 $(location) と [変数を作成] で置換する Bourne シェルのトークン化。 Java バイナリのラッパー スクリプトに CLASSPATH 定義が含まれている （依存する jar をすべて見つけるため）、適切な Java インタープリタを呼び出します。 ラッパー スクリプトによって生成されたコマンドラインには、 メインクラスの後に "$@" を付け、他のクラスを渡せるようにします。 クラス名の後に引数を指定します。ただし、解析対象の引数は コマンドのクラス名の前に指定する必要があります。 追加します。jvm_flags の内容がラッパーに追加される スクリプトを書き留めてください。 この属性は *_deploy.jar には作用しないことに注意してください。 出力です。
manifest	ラベル:デフォルトは None です Android マニフェスト ファイルの名前（通常は AndroidManifest.xml）。 resource_files または assets が定義されている場合、または テスト対象のライブラリには minSdkVersion タグが含まれています。
manifest_values	辞書: 文字列 ->String;デフォルトは {} です。 マニフェストでオーバーライドされる値のディクショナリ。${name} の は、このディクショナリ内の名前に対応する値に置き換えられます。 applicationId さん、versionCode さん、versionName さん、 minSdkVersion、targetSdkVersion、 maxSdkVersion は、対応する属性もオーバーライドします マニフェスト ファイルと use-sdk タグを使用します。packageName は無視され、次のいずれかから設定されます 次の場合は applicationId パッケージを指定または変更できます。 manifest_values を使用するために、ルールにマニフェストは必要ありません。
nocompress_extensions	文字列のリスト。デフォルトは [] です。 リソース apk に圧縮しないファイル拡張子のリスト。
plugins	ラベルのリスト。デフォルトは [] です コンパイル時に実行する Java コンパイラ プラグイン。 このルールでは、この属性で指定されたすべての java_plugin が実行されます。 構築します。ライブラリは、使用する依存関係からプラグインを継承し、 exported_plugins。リソース 生成 AI は、このルールの生成される jar に含められます。
resource_configuration_filters	文字列のリスト。デフォルトは [] です。 リソース構成フィルタのリスト（「en」など）クラスタ内のリソースを制限することで 「en」のできます。
resource_jars	ラベルのリスト。デフォルトは [] です 非推奨: 代わりに java_import と deps または runtime_deps を使用してください。
resource_strip_prefix	String;デフォルトは "" です。 Java リソースから削除するパス接頭辞。 指定すると、このパス接頭辞が resources 内のすべてのファイルから削除されます 属性です。リソース ファイルがこのディレクトリにない場合はエラーになります。回答が「いいえ」の場合 が指定された場合（デフォルト）、リソース ファイルのパスは、 などのロジックをソースファイルの Java パッケージとして使用します。たとえば、 stuff/java/foo/bar/a.txt の所在地は foo/bar/a.txt です。
runtime_deps	ラベルのリスト。デフォルトは [] です 最終バイナリまたは実行時にのみテストで使用できるようにするライブラリ。 通常の deps と同様に、これらはランタイム クラスパスに表示されますが、 コンパイル時のクラスパスではなく、実行時にのみ必要な依存関係は、 表示されます。依存関係分析ツールは、両方に出現するターゲットを無視する runtime_deps と deps。
stamp	整数デフォルトは 0 です。 ビルド情報をバイナリにエンコードするかどうか。可能な値: stamp = 1: ビルド情報を常にバイナリにスタンプします。これは、 --nostamp ビルド。この 設定しないでください。この設定を行うと、インスタンスのリモート キャッシュが強制終了される バイナリとそれに依存するダウンストリーム アクションが含まれます。 stamp = 0: ビルド情報を常に定数値に置き換えます。この 適切なビルド結果キャッシュを提供します。 stamp = -1: ビルド情報の埋め込みは、 --[no]stamp フラグ。 スタンプされたバイナリは、依存関係が変更されない限り再ビルドされません。
test_class	String;デフォルトは "" です。 テストランナーによって読み込まれる Java クラス。 この属性は、実行する Java クラスの名前を指定します。 このテストを実行します。この設定が必要になることはほとんどありません。この引数を省略すると、Java クラスは 対応する名前が、このアプリケーションの name android_local_test 個のルールが使用されます。 テストクラスには org.junit.runner.RunWith アノテーションを付ける必要があります。
use_launcher	ブール値デフォルトは True です。 バイナリがカスタム ランチャーを使用するかどうか。 この属性を false に設定すると、 launcher 属性と関連 --java_launcher フラグ このターゲットでは無視されます。

android_device

ルールのソースを表示

android_device(name, cache, compatible_with, default_properties, deprecation, distribs, exec_compatible_with, exec_properties, features, horizontal_resolution, licenses, platform_apks, ram, restricted_to, screen_density, system_image, tags, target_compatible_with, testonly, vertical_resolution, visibility, vm_heap)

このルールにより、指定されたデバイスで構成された Android Emulator が作成されます。 仕様。このエミュレータは bazel 実行経由で起動できます 生成されたスクリプトを直接実行することもできます。推奨されるのは、 既存の android_device ルールに基づいて実装することをおすすめします。

このルールは、Bazel テストと Blaze に対する --run_under フラグのターゲットとして あります。エミュレータを起動し、テストまたは実行しているターゲットをエミュレータにコピーします。 必要に応じてテストまたは実行します

android_device は、基盤となる KVM が system_image は X86 ベースで、 最大 I686 CPU アーキテクチャ向けに最適化されています。KVM を使用するには、以下を追加します tags = ['requires-kvm'] を android_device ルールに追加します。

暗黙的な出力ターゲット

• name_images/userdata.dat: エミュレータを起動するための画像ファイルとスナップショットが含まれています
• name_images/emulator-meta-data.pb: エミュレータに渡すために必要なシリアル化された情報が含まれています。 再起動する必要があります。

例

次の例は、android_device を使用する方法を示しています。 //java/android/helloandroid/BUILDに含まれる:

android_device(
    name = "nexus_s",
    cache = 32,
    default_properties = "nexus_s.properties",
    horizontal_resolution = 480,
    ram = 512,
    screen_density = 233,
    system_image = ":emulator_images_android_16_x86",
    vertical_resolution = 800,
    vm_heap = 32,
)

filegroup(
    name = "emulator_images_android_16_x86",
    srcs = glob(["androidsdk/system-images/android-16/**"]),
)

//java/android/helloandroid/nexus_s.properties には以下が含まれます。

ro.product.brand=google
ro.product.device=crespo
ro.product.manufacturer=samsung
ro.product.model=Nexus S
ro.product.name=soju

このルールにより、画像と起動スクリプトが生成されます。エミュレータで bazel run :nexus_s -- --action=start を ローカルで実行する必要がありますこのスクリプトは、 次のフラグを指定します。

• --adb_port: adb を公開するポート。adb を発行する場合 これは、adb connect を発行するポートです。 できます。
• --emulator_port: エミュレータの Telnet 管理を公開するポート オンにします。
• --enable_display: true の場合にエミュレータをディスプレイで起動します（デフォルト false に設定します）。
• --action: start または kill のいずれか。
• --apks_to_install: エミュレータにインストールする APK のリスト。

引数

属性
name	名前:必須 このターゲットの一意の名前。
cache	整数必須 エミュレータのキャッシュ パーティションのサイズ（MB 単位）。 この最小値は 16 MB です。
default_properties	ラベル:デフォルトは None です エミュレータの /default.prop に配置する単一のプロパティ ファイル。 これにより、ルールの作成者はエミュレータを 実際のデバイス（具体的には、UserAgent 文字列やその他の アプリケーションやサーバーの動作を 。このファイルのプロパティは読み取り専用で ro.product.model などのエミュレータによって設定されるプロパティです。
horizontal_resolution	整数必須 エミュレートする水平方向の画面解像度（ピクセル単位）。 最小値は 240 です。
platform_apks	ラベルのリスト。デフォルトは [] です 起動時にデバイスにインストールされる APK のリスト。
ram	整数必須 デバイスに対してエミュレートする RAM の量（MB）。 デバイスにインストールされている特定のアプリだけでなく、デバイス全体が対象です。「 最小値は 64MB です
screen_density	整数必須 エミュレートされた画面の密度（1 インチあたりのピクセル数）。 最小値は 30 ppi です。
system_image	ラベル:必須 次のファイルを含むファイル グループ: system.img: システム パーティション kernel-qemu: エミュレータが読み込む Linux カーネル ramdisk.img: 起動時に使用する initrd イメージ userdata.img: 最初のユーザーデータ パーティション source.properties: 属性に関する情報を含むプロパティ ファイル 画像 これらのファイルは Android SDK の一部であるか、サードパーティ（ Intel は x86 イメージを提供しています）。
vertical_resolution	整数必須 エミュレートする垂直画面の解像度（ピクセル単位）。 最小値は 240 です。
vm_heap	整数必須 Android が各プロセスで使用する仮想マシンヒープのサイズ（MB 単位）。 最小値は 16 MB です。

android_ndk_repository

ルールのソースを表示

android_ndk_repository(name, api_level, path, repo_mapping)

Android NDK を使用してネイティブでの Android ターゲットのビルドをサポートするように Bazel を構成します。 できます。

なお、この android_ndk_repository の実装は、 Starlark での実装。バージョン 25 以降を含む今後のバージョンの NDK のサポートは、 android_ndk_repository の Starlark バージョンに実装されています。詳しくは、 rules_android_ndk（Starlark 用） できます。

なお、Android 向けのビルドでは、android_sdk_repository ルールも WORKSPACE ファイル。

詳しくは、 Android NDK と Bazel の使用に関するドキュメント全文をご覧ください。

例

android_ndk_repository(
    name = "androidndk",
)

上記の例では、$ANDROID_NDK_HOME から Android NDK を探し、 API レベルを指定します。

android_ndk_repository(
    name = "androidndk",
    path = "./android-ndk-r20",
    api_level = 24,
)

上記の例では、ワークスペース内の Android NDK を使用します。 ./android-ndk-r20。JNI のコンパイル時に API レベル 24 のライブラリが使用されます。 できます。

cpufeatures

Android NDK には、 cpufeatures ライブラリ 実行時にデバイスの CPU を検出するために使用できます。次の例は、BigQuery の Bazel による cpufeatures。

# jni.cc
#include "ndk/sources/android/cpufeatures/cpu-features.h"
...

# BUILD
cc_library(
    name = "jni",
    srcs = ["jni.cc"],
    deps = ["@androidndk//:cpufeatures"],
)

引数

属性
name	名前:必須 このターゲットの一意の名前。
api_level	整数設定不可デフォルトは 0 です ビルド対象の Android API レベル。指定しない場合、インストールされている API レベルが最も高い 使用されます。
path	String;設定不可デフォルトは "" です Android NDK への絶対パスまたは相対パス。この属性または $ANDROID_NDK_HOME 環境変数を設定する必要があります。 Android NDK は次の場所からダウンロードできます。 Android デベロッパー サイト 。
repo_mapping	辞書: 文字列 ->String;デフォルトは {} です。 ローカル リポジトリ名からグローバル リポジトリ名への辞書。これにより このリポジトリの依存関係を解決できます。 たとえば、エントリ "@foo": "@bar" は、このインスタンスが リポジトリが "@foo" に依存している（ "@foo//some:target" など）を宣言すると、その依存関係は グローバルに宣言された "@bar"（"@bar//some:target"）。

android_sdk_repository

ルールのソースを表示

android_sdk_repository(name, api_level, build_tools_version, path, repo_mapping)

Android ターゲットのビルドをサポートするローカル Android SDK を使用するように Bazel を構成します。

例

Bazel 用の Android SDK をセットアップするために最低限必要なのは、android_sdk_repository ルールを設定することです。 「androidsdk」という名前のWORKSPACE ファイルで $ANDROID_HOME を Android SDK のパスに環境変数を設定します。Bazel は最も高い Android API レベルを使用します Android SDK にデフォルトでインストールされるビルドツールのバージョン。

android_sdk_repository(
    name = "androidsdk",
)

ビルドを再現できるように、path、api_level、 build_tools_version 属性は特定の値に設定できます。次の場合、ビルドは失敗します。 指定された API レベルまたはビルドツール バージョンが Android SDK にインストールされていません。

android_sdk_repository(
    name = "androidsdk",
    path = "./sdk",
    api_level = 19,
    build_tools_version = "25.0.0",
)

上記の例では、Android SDK へのワークスペース相対パスも使用しています。これは、 Android SDK が Bazel ワークスペースの一部である場合（例: バージョンにチェックインしている場合）に有用 設定されます。

サポート ライブラリ

サポート ライブラリは、Android SDK Manager で「Android Support Repository」として入手できます。 Support ライブラリや AppCompat ライブラリなど、一般的な Android ライブラリのバージョン管理されたセットです。 ローカルの Maven リポジトリとしてパッケージ化されていますandroid_sdk_repository が Bazel を生成します 各ライブラリのターゲットを使用でき、依存関係の android_binary ターゲットと android_library ターゲット。

生成されるターゲットの名前は、 Android Support Repository（@androidsdk//${group}:${artifact}-${version} 形式）。 次の例は、android_library がアプリケーションのバージョン 25.0.0 にどのように依存するかを示しています。 v7 appcompat ライブラリを使用します。

android_library(
    name = "lib",
    srcs = glob(["*.java"]),
    manifest = "AndroidManifest.xml",
    resource_files = glob(["res/**"]),
    deps = ["@androidsdk//com.android.support:appcompat-v7-25.0.0"],
)

引数

属性
name	名前:必須 このターゲットの一意の名前。
api_level	整数設定不可デフォルトは 0 です デフォルトでビルドする Android API レベル。指定しない場合、最大の API レベル 使用されます。 特定のビルドに使用される API レベルは、android_sdk でオーバーライドできます 設定されます。android_sdk_repository は次の場所の android_sdk ターゲットを作成します。 @androidsdk//:sdk-${level} という名前の SDK にインストールされている各 API レベル 指定する必要があります。たとえば、デフォルト以外の API でビルドする場合は、 レベル: bazel build --android_sdk=@androidsdk//:sdk-19 //java/com/example:app。 android_sdk_repository によって生成されたすべての android_sdk ターゲットを表示するには、bazel query "kind(android_sdk, @androidsdk//...)" を実行します。
build_tools_version	String;設定不可デフォルトは "" です Android SDK 内から使用する Android ビルドツールのバージョン。指定しない場合、 インストールされている最新のビルドツール バージョンが使用されます。 Bazel には、バージョン 30.0.0 以降のビルドツールが必要です。
path	String;設定不可デフォルトは "" です Android SDK への絶対パスまたは相対パス。この属性または $ANDROID_HOME 環境変数を設定する必要があります。 Android SDK は次の場所からダウンロードできます。 Android デベロッパー サイトをご覧ください。
repo_mapping	辞書: 文字列 ->String;デフォルトは {} です。 ローカル リポジトリ名からグローバル リポジトリ名への辞書。これにより このリポジトリの依存関係を解決できます。 たとえば、エントリ "@foo": "@bar" は、このインスタンスが リポジトリが "@foo" に依存している（ "@foo//some:target" など）を宣言すると、その依存関係は グローバルに宣言された "@bar"（"@bar//some:target"）。