BazelCon 2022 findet vom 16. bis 17. November in New York und online statt.
Jetzt anmelden

Android-Regeln

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Regeln

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)

Erstellt Android-Anwendungspaketdateien (.apk).

Implizite Ausgabeziele

  • name.apk: Eine Paketdatei für eine Android-Anwendung, die mit Debug-Schlüsseln signiert und mit Zipalign versehen ist, kann zum Entwickeln und Debuggen deiner App verwendet werden. Sie können Ihre Anwendung nicht veröffentlichen, wenn sie mit den Fehlerbehebungsschlüsseln signiert sind.
  • name_unsigned.apk: Eine nicht signierte Version der obigen Datei, die vor der Veröffentlichung mit den Releaseschlüsseln signiert werden konnte.
  • name_deploy.jar: Ein Java-Archiv, das die vorübergehende Schließung dieses Ziels enthält.

    Die Bereitstellungs-JAR-Datei enthält alle Klassen, die von einem Classloader gefunden werden würden, der den Laufzeitklassenpfad dieses Ziels vom Anfang bis zum Ende durchsucht hat.

  • name_proguard.jar: Ein Java-Archiv mit dem Ergebnis der Ausführung von ProGuard auf der name_deploy.jar. Diese Ausgabe wird nur generiert, wenn das Attribut proguard_specs angegeben ist.
  • name_proguard.map: Ergebnis einer Zuordnungsdatei zum Ausführen von ProGuard auf name_deploy.jar. Diese Ausgabe wird nur generiert, wenn das Attribut proguard_specs angegeben und proguard_generate_mapping oder shrink_resources festgelegt ist.

Beispiele

Beispiele für Android-Regeln finden Sie im Verzeichnis examples/android der Bazel-Quellstruktur.

Argumente

Attribute
name

Name; required

Ein eindeutiger Name für dieses Ziel.

deps

List of labels; optional

Die Liste weiterer Bibliotheken, die mit dem binären Ziel verknüpft werden sollen. Zulässige Bibliothekstypen sind: android_library, java_library mit android-Einschränkung und cc_library-Wrapping oder -Erstellung von .so nativen Bibliotheken für die Android-Zielplattform.
srcs

List of labels; optional

Die Liste der Quelldateien, die zum Erstellen des Ziels verarbeitet werden.

srcs Datei des Typs „.java“ wurde kompiliert. Um die Lesbarkeit zu erhöhen, ist es nicht empfehlenswert, den Namen einer generierten .java-Quelldatei in den srcs aufzunehmen. Gib stattdessen den Namen der abhängigen Regel in srcs ein, wie unten beschrieben.

srcs Dateien des Typs .srcjar werden entpackt und kompiliert. Dies ist nützlich, wenn Sie eine Reihe von .java-Dateien mit einer Genrule oder Build-Erweiterung generieren müssen.

assets

List of labels; optional

Die Liste der zu packenden Assets. In der Regel ist dies eine glob aller Dateien im Verzeichnis assets. Du kannst auch in den anderen Paketen auf andere Regeln (alle Regel, die Dateien erzeugt) oder exportierte Dateien verweisen, solange sich diese Dateien im entsprechenden Paket im Verzeichnis assets_dir befinden.
assets_dir

String; optional

Der String, der den Pfad zu den Dateien in assets angibt. Das Paar assets und assets_dir beschreiben gepackte Assets. Es sollte entweder eines oder keins von beiden angegeben werden.
crunch_png

Boolean; optional; default is True

Mach das PNG-Cruming (oder nicht). Dies ist unabhängig von der Verarbeitung mit neun Patches, was immer erfolgt. Dies ist eine verworfene Lösung für einen aapt-Fehler, der in aapt2 behoben wurde.
custom_package

String; optional

Java-Paket, für das Java-Quellen generiert werden. Das Paket wird standardmäßig aus dem Verzeichnis abgeleitet, in dem sich die BUILD-Datei mit der Regel befindet. Sie können ein anderes Paket angeben. Dies wird jedoch dringend nicht empfohlen, da es Klassenpfadkonflikte mit anderen Bibliotheken verursachen kann, die nur zur Laufzeit erkannt werden.
debug_key

Label; optional; default is @bazel_tools//tools/android:debug_keystore

Datei mit dem Schlüsselspeicher zur Fehlerbehebung, der zum Signieren der Debug-APK verwendet werden soll. Normalerweise sollten Sie nur den Standardschlüssel verwenden. Daher sollte dieses Attribut weggelassen werden.

WARNUNG: Verwenden Sie keine Produktionsschlüssel, da sie streng geschützt und nicht in Ihrer Quellstruktur aufbewahrt werden sollten.

debug_signing_keys

List of labels; optional

Liste der Dateien, Schlüsselspeicher zur Fehlerbehebung, die zum Signieren der APK-Datei zur Fehlerbehebung verwendet werden sollen Normalerweise sollten Sie nur den Standardschlüssel verwenden. Daher sollte dieses Attribut weggelassen werden.

WARNUNG: Verwenden Sie keine Produktionsschlüssel, da sie streng geschützt und nicht in Ihrer Quellstruktur aufbewahrt werden sollten.

debug_signing_lineage_file

Label; optional

Datei mit der Signaturherkunft für debug_signing_keys. Normalerweise sollten Sie nur den Standardschlüssel verwenden. Daher sollte dieses Attribut weggelassen werden.

WARNUNG: Verwenden Sie keine Produktionsschlüssel, da sie streng geschützt und nicht in Ihrer Quellstruktur aufbewahrt werden sollten.

densities

List of strings; optional

Dichten, nach denen beim Erstellen des APK gefiltert werden soll Dadurch werden rasterfähige Ressourcen entfernt, die von einem Gerät mit den angegebenen Bildschirmdichten nicht geladen werden würden, um die APK-Größe zu reduzieren. Ein entsprechender Abschnitt mit kompatiblen Bildschirmen wird dem Manifest ebenfalls hinzugefügt, falls er keine Obermengenliste enthält.
dex_shards

Integer; optional; default is 1

Anzahl der Shard-Dexing-Vorgänge sollte aufgeteilt werden. Dadurch wird das Dexing auf Kosten der App-Installation und des Startvorgangs viel schneller. Je größer die Binärdatei, desto mehr Shards sollten verwendet werden. 25 ist ein guter Wert, um mit dem Experimentieren zu beginnen.

Beachten Sie, dass jeder Shard zu mindestens einem Dex in der endgültigen Anwendung führt. Daher wird es nicht empfohlen, diesen Wert auf mehr als 1 für Release-Binärprogramme festzulegen.

dexopts

List of strings; optional

Zusätzliche Befehlszeilen-Flags für das dx-Tool beim Generieren von class.dex. Unterliegt der Ersetzung der Variable und der Bourne-Shell-Tokenisierung.
enable_data_binding

Boolean; optional; default is False

Wenn der Wert „true“ ist, verarbeitet diese Regel Datenbindungsausdrücke in Layoutressourcen, die über das Attribut resource_files enthalten sind. Ohne diese Einstellung führen Datenbindungsausdrücke zu Build-Fehlern.

Um eine Android-App mit Datenbindung zu erstellen, müssen Sie außerdem Folgendes tun:

  1. Legen Sie dieses Attribut für alle Android-Regeln fest, die vorübergehend von dieser Regel abhängen. Das liegt daran, dass Abhängigkeiten durch Datenzusammenführung die Ausdrücke der Datenbindung der Regel übernehmen. Sie müssen also auch Datenbindungen zum Parsen dieser Ausdrücke erstellen.
  2. Fügen Sie allen Zielen, die dieses Attribut festlegen, einen deps =-Eintrag für die Datenbindungslaufzeitbibliothek hinzu. Der Speicherort dieser Bibliothek hängt von Ihrer Einrichtung des Depots ab.
incremental_dexing

Integer; optional; nonconfigurable; default is -1

Erzwingen, dass das Ziel mit oder ohne inkrementellen Dexing erstellt wird, wobei die Standardwerte und das Flag -- inkrementelleal_dexing überschrieben werden.
instruments

Label; optional

Das Ziel android_binary auf das Instrument.

Wenn dieses Attribut festgelegt ist, wird die android_binary als Testanwendung für Instrumentierungstests behandelt. Ein android_instrumentation_test-Ziel kann dieses Ziel dann im Attribut test_app angeben.

javacopts

List of strings; optional

Zusätzliche Compileroptionen für dieses Ziel. Unterliegt der Ersetzung der Variable und der Bourne-Shell-Tokenisierung.

Diese Compileroptionen werden nach den globalen Compileroptionen an Javac übergeben.

key_rotation_min_sdk

String; optional

Legt die Mindestversion der Android-Plattform (API-Level) fest, für die der rotierte Signaturschlüssel eines APKs verwendet werden sollte, um die Signatur des APKs zu erzeugen. Der ursprüngliche Signaturschlüssel für das APK wird für alle vorherigen Plattformversionen verwendet.
main_dex_list

Label; optional

Eine Textdatei enthält eine Liste der Klassendateinamen. Die von diesen Klassendateien definierten Klassen werden der primären Datei „classes.dex“ hinzugefügt. Beispiel:
          android/support/multidex/MultiDex$V19.class
          android/support/multidex/MultiDex.class
          android/support/multidex/MultiDexApplication.class
          com/google/common/base/Objects.class
                    
Muss mit multidex="manual_main_dex" verwendet werden.
main_dex_list_opts

List of strings; optional

Befehlszeilenoptionen zur Übergabe an das Haupt-Dex-Listen-Builder. Verwenden Sie diese Option, um die in der Haupt-Dex-Liste enthaltenen Klassen zu beeinflussen.
main_dex_proguard_specs

List of labels; optional

Dateien, die als ProGuard-Spezifikationen verwendet werden, um Klassen zu bestimmen, die im Hauptdex aufbewahrt werden müssen. Nur zulässig, wenn das Attribut multidex auf legacy gesetzt ist.
manifest

Label; required

Der Name der Android-Manifestdatei, normalerweise AndroidManifest.xml. Muss definiert werden, wenn resource_files oder Assets definiert sind.
manifest_values

Dictionary: String -> String; optional

Ein Wörterbuch mit Werten, die im Manifest überschrieben werden sollen. Jede Instanz von ${name} im Manifest wird durch den Wert ersetzt, der dem Namen in diesem Wörterbuch entspricht. applicationId, versionCode, versionName, minSdkVersion, targetSdkVersion und maxSdkVersion überschreiben auch die entsprechenden Attribute des Manifests und use-sdk-Tags. packageName wird ignoriert und entweder über die appId, falls angegeben, oder über das Paket im Manifest festgelegt. Wenn „manifest_merger“ auf „alt“ gesetzt ist, haben nur „applicationId“, „versionCode“ und „versionName“ Auswirkungen.
multidex

String; optional; default is "native"

Gibt an, ob Code in mehrere Dex-Dateien aufgeteilt werden soll.
Mögliche Werte:
  • native: Teilt Code in mehrere Dex-Dateien auf, wenn das Indexlimit von 64.000 Dex überschritten wird. Es wird davon ausgegangen, dass die native Plattformunterstützung das Laden von Multidex-Klassen zur Laufzeit unterstützt. Dies funktioniert nur mit Android L und höher.
  • legacy: Teilt Code in mehrere Dex-Dateien auf, wenn das Indexlimit von 64.000 Dex überschritten wird. Es wird davon ausgegangen, dass Multidex-Klassen über Anwendungscode geladen werden (d.h. keine native Plattformunterstützung).
  • manual_main_dex: Teilt Code in mehrere DEX-Dateien auf, wenn das Indexlimit für DEX 64K überschritten wird. Der Inhalt der Haupt-Dex-Datei muss angegeben werden. Stellen Sie dazu mithilfe des Attributs main_dex_list eine Liste der Klassen in einer Textdatei bereit.
  • off: Kompilieren Sie den gesamten Code zu einer einzigen DEX-Datei, auch wenn diese das Indexlimit überschreitet.
nocompress_extensions

List of strings; optional

Eine Liste der Dateiendungen, die nicht komprimiert werden sollen.
package_id

Integer; optional; default is 0

Paket-ID, die Ressourcen in diesem Binärprogramm zugewiesen werden soll.

Weitere Informationen findest du im --package-id-Argument von AAPT2. Dies kann (und sollte) in der Regel nicht festgelegt werden, was den Standardwert 127 (0x7F) ergibt.

plugins

List of labels; optional

Java-Compiler-Plug-ins, die zum Zeitpunkt der Kompilierung ausgeführt werden sollen. Alle im Attribut „plugins“ angegebenen java_plugin werden bei jeder Erstellung dieses Ziels ausgeführt. Die vom Plug-in generierten Ressourcen werden in die Ergebnis-JAR-Datei des Ziels aufgenommen.
proguard_apply_dictionary

Label; optional

Datei, die als Zuordnung für ProGuard verwendet werden soll. Eine zeilengetrennte Datei mit "words", die beim Umbenennen von Klassen und Mitgliedern während der Verschleierung abgerufen werden sollen.
proguard_apply_mapping

Label; optional

Datei, die als Zuordnung für ProGuard verwendet werden soll. Eine von proguard_generate_mapping generierte Zuordnungsdatei, die wiederverwendet werden kann, um dieselbe Zuordnung auf einen neuen Build anzuwenden.
proguard_generate_mapping

Boolean; optional; nonconfigurable; default is False

Gibt an, ob eine ProGuard-Zuordnungsdatei generiert werden soll. Die Zuordnungsdatei wird nur generiert, wenn proguard_specs angegeben ist. In dieser Datei wird die Zuordnung zwischen dem ursprünglichen und dem verschleierten Klassen-, Methoden- und Feldnamen aufgelistet.

WARNUNG: Wenn dieses Attribut verwendet wird, sollte die ProGuard-Spezifikation weder -dontobfuscate noch -printmapping enthalten.

proguard_specs

List of labels; optional

Dateien, die als ProGuard-Spezifikation verwendet werden sollen. Diese Datei enthält eine Beschreibung der Spezifikationen, die von ProGuard verwendet werden.
resource_configuration_filters

List of strings; optional

Eine Liste von Ressourcenkonfigurationsfiltern wie „#“ und „#39“, die die Ressourcen in der APK-Datei auf die Filter in der Konfiguration beschränken. Verwende zum Aktivieren der Pseudolokalisierung die Pseudosprachen en_XA und/oder ar_XB.
resource_files

List of labels; optional

Die Liste der zu packenden Ressourcen. In der Regel ist dies eine glob aller Dateien im Verzeichnis res.
Auf generierte Dateien (aus Genregeln) kann auch hier durch Label verwiesen werden. Die einzige Einschränkung besteht darin, dass sich die generierten Ausgaben im selben Verzeichnisres befinden wie alle anderen enthaltenen Ressourcendateien.
shrink_resources

Integer; optional; default is -1

Gibt an, ob die Ressourcenverkleinerung ausgeführt werden soll. Ressourcen, die nicht von der Binärdatei verwendet werden, werden aus dem APK entfernt. Dies wird nur für Regeln unterstützt, die lokale Ressourcen verwenden (d.h. die Attribute manifest und resource_files) und erfordert ProGuard. Sie funktioniert im Wesentlichen genauso wie der Gradle-Ressourcenschrumpf (https://developer.android.com/studio/build/shrink-code.html#shrink-resources).

Wichtige Unterschiede:

  • Ressourcen in values/ sowie dateibasierte Ressourcen werden entfernt
  • verwendet standardmäßig strict mode
  • Entfernen nicht verwendeter ID-Ressourcen wird nur mit aapt2 unterstützt
Wenn die Ressourcenverkleinerung aktiviert ist, wird auch name_files/resource_shrinker.log mit ausführlichen Analysen und Löschungen generiert.

Mögliche Werte:

  • shrink_resources = 1: Schaltet das Verkleinern von Android-Ressourcen ein
  • shrink_resources = 0: Deaktiviert die Verkleinerung der Android-Ressourcen
  • shrink_resources = -1: Das Verkleinern wird durch das Flag - --android_resource_shrinking gesteuert.

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)

Diese Regel ermöglicht die Verwendung von .aar-Dateien als Bibliotheken für die Regeln android_library und android_binary.

Beispiele

    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"],
    )

Argumente

Attribute
name

Name; required

Ein eindeutiger Name für dieses Ziel.

aar

Label; required

Die Datei .aar, die Android-Zielen bereitgestellt werden soll, die von diesem Ziel abhängen.
exports

List of labels; optional

Ziele für den Export in Regeln, die von dieser Regel abhängen. Siehe java_library.exports.
srcjar

Label; optional

Eine JAR-Datei, die Quellcode für die kompilierten JAR-Dateien in den AAE enthält.

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)

Diese Regel kompiliert und archiviert ihre Quellen in einer .jar-Datei. Die Android-Laufzeitbibliothek android.jar wird implizit auf den Pfad der Kompilierungsklasse gesetzt.

Implizite Ausgabeziele

  • libname.jar: Ein Java-Archiv.
  • libname-src.jar: Ein Archiv mit den Quellen ("source jar").
  • name.aar: Ein Android-Bundle mit dem Java-Archiv und den Ressourcen dieses Ziels. Sie enthält nicht die vorübergehende Schließung.

Beispiele

Beispiele für Android-Regeln finden Sie im Verzeichnis examples/android der Bazel-Quellstruktur.

Das folgende Beispiel zeigt, wie idl_import_root festgelegt wird. //java/bazel/helloandroid/BUILD darf Folgendes enthalten:

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"],
)

Argumente

Attribute
name

Name; required

Ein eindeutiger Name für dieses Ziel.

deps

List of labels; optional

Die Liste der anderen Bibliotheken, die verknüpft werden sollen. Zulässige Bibliothekstypen sind android_library, java_library mit android-Einschränkung und cc_library-Wrapping oder -Erstellung .so nativer Bibliotheken für die Android-Zielplattform.
srcs

List of labels; optional

Die Liste der .java- oder .srcjar-Dateien, die zum Erstellen des Ziels verarbeitet werden.

srcs Datei des Typs „.java“ wurde kompiliert. Um die Lesbarkeit zu erhöhen, ist es nicht empfehlenswert, den Namen einer generierten .java-Quelldatei in den srcs aufzunehmen. Gib stattdessen den Namen der abhängigen Regel in srcs ein, wie unten beschrieben.

srcs Dateien des Typs .srcjar werden entpackt und kompiliert. Dies ist nützlich, wenn Sie eine Reihe von .java-Dateien mit einer Genrule oder Build-Erweiterung generieren müssen.

Wenn srcs weggelassen wird, wird jede in deps angegebene Abhängigkeit aus dieser Regel exportiert. Weitere Informationen zum Exportieren von Abhängigkeiten finden Sie unter Exporte in Java-Bibliothek. Dieses Verhalten wird jedoch bald eingestellt. Verlassen Sie sich also nicht darauf.

assets

List of labels; optional

Die Liste der zu packenden Assets. In der Regel ist dies eine glob aller Dateien im Verzeichnis assets. Du kannst auch in den anderen Paketen auf andere Regeln (alle Regel, die Dateien erzeugt) oder exportierte Dateien verweisen, solange sich diese Dateien im entsprechenden Paket im Verzeichnis assets_dir befinden.
assets_dir

String; optional

Der String, der den Pfad zu den Dateien in assets angibt. Das Paar assets und assets_dir beschreiben gepackte Assets. Es sollte entweder eines oder keins von beiden angegeben werden.
custom_package

String; optional

Java-Paket, für das Java-Quellen generiert werden. Das Paket wird standardmäßig aus dem Verzeichnis abgeleitet, in dem sich die BUILD-Datei mit der Regel befindet. Sie können ein anderes Paket angeben. Dies wird jedoch dringend nicht empfohlen, da es Klassenpfadkonflikte mit anderen Bibliotheken verursachen kann, die nur zur Laufzeit erkannt werden.
enable_data_binding

Boolean; optional; default is False

Wenn der Wert „true“ ist, verarbeitet diese Regel Datenbindungsausdrücke in Layoutressourcen, die über das Attribut resource_files enthalten sind. Ohne diese Einstellung führen Datenbindungsausdrücke zu Build-Fehlern.

Um eine Android-App mit Datenbindung zu erstellen, müssen Sie außerdem Folgendes tun:

  1. Legen Sie dieses Attribut für alle Android-Regeln fest, die vorübergehend von dieser Regel abhängen. Das liegt daran, dass Abhängigkeiten durch Datenzusammenführung die Ausdrücke der Datenbindung der Regel übernehmen. Sie müssen also auch Datenbindungen zum Parsen dieser Ausdrücke erstellen.
  2. Fügen Sie allen Zielen, die dieses Attribut festlegen, einen deps =-Eintrag für die Datenbindungslaufzeitbibliothek hinzu. Der Speicherort dieser Bibliothek hängt von Ihrer Einrichtung des Depots ab.
exported_plugins

List of labels; optional

Die Liste der java_plugins (z.B. Annotationsprozessoren), die in Bibliotheken exportiert werden sollen, die direkt von dieser Bibliothek abhängen.

Die angegebene Liste von java_plugins wird auf jede Bibliothek angewendet, die direkt von dieser Bibliothek abhängt, so als ob diese Bibliothek diese Labels explizit in plugins deklariert hätte.

exports

List of labels; optional

Die Schließung aller Regeln, die über exports-Attribute erreicht werden, gilt als direkte Abhängigkeit einer Regel, die direkt vom Ziel mit exports abhängt.

Die exports sind keine direkten Regeln der Regel, zu der sie gehören.

exports_manifest

Integer; optional; default is 1

Gibt an, ob Manifesteinträge in android_binary-Ziele exportiert werden sollen, die von diesem Ziel abhängen. uses-permissions-Attribute werden nie exportiert.
idl_import_root

String; optional

Paketrelativer Pfad zum Stammverzeichnis der Java-Paketstruktur mit Idl-Quellen, die in dieser Bibliothek enthalten sind.

Dieser Pfad wird als Importstamm für die Verarbeitung von Idl-Quellen verwendet, die von dieser Bibliothek abhängen.

Wenn idl_import_root angegeben ist, müssen sich sowohl idl_parcelables als auch idl_srcs unter dem Pfad befinden, der im Java-Paket des Objekts angegeben ist, das sie unter idl_import_root darstellen. Wenn idl_import_root nicht angegeben ist, müssen sich sowohl idl_parcelables als auch idl_srcs unter dem Pfad befinden, der vom Paket unter einem Java-Stammverzeichnis angegeben wird.

Beispiele

idl_parcelables

List of labels; optional

Liste der Android-IDL-Definitionen, die als Importe bereitgestellt werden sollen. Diese Dateien werden als Importe für jedes android_library-Ziel bereitgestellt, das von dieser Bibliothek abhängig ist, entweder direkt oder über ihre vorübergehende Schließung, aber nicht in Java übersetzt oder kompiliert.

Es dürfen nur .aidl-Dateien enthalten sein, die direkt zu .java-Quellen in dieser Bibliothek gehören (z.B. benutzerdefinierte Implementierungen von Parcelable), andernfalls idl_srcs.

Diese Dateien müssen entsprechend platziert werden, damit der Hilfe-Compiler sie findet. Weitere Informationen dazu finden Sie in der Beschreibung von idl_import_root.

idl_preprocessed

List of labels; optional

Liste der vorverarbeiteten Android-IDL-Definitionen, die als Importe bereitgestellt werden sollen. Diese Dateien werden als Importe für jedes android_library-Ziel bereitgestellt, das von dieser Bibliothek abhängig ist, entweder direkt oder über ihre vorübergehende Schließung, aber nicht in Java übersetzt oder kompiliert.

Es dürfen nur vorverarbeitete .aidl-Dateien enthalten sein, die direkt .java-Quellen in dieser Bibliothek entsprechen (z. B. benutzerdefinierte Implementierungen von Parcelable). Verwende andernfalls idl_srcs für Android-IDL-Definitionen, die in Java-Schnittstellen übersetzt werden müssen, und idl_parcelable für nicht vorverarbeitete AIDL-Dateien.

idl_srcs

List of labels; optional

Liste der Android-IDL-Definitionen, die in Java-Schnittstellen umgewandelt werden sollen. Nachdem die Java-Schnittstellen generiert wurden, werden sie mit dem Inhalt von srcs kompiliert.

Diese Dateien werden als Importe für jedes android_library-Ziel zur Verfügung gestellt, das von dieser Bibliothek abhängig ist, entweder direkt oder über die vorübergehende Schließung.

Diese Dateien müssen entsprechend platziert werden, damit der Hilfe-Compiler sie findet. Weitere Informationen dazu finden Sie in der Beschreibung von idl_import_root.

javacopts

List of strings; optional

Zusätzliche Compileroptionen für dieses Ziel. Unterliegt der Ersetzung der Variable und der Bourne-Shell-Tokenisierung.

Diese Compileroptionen werden nach den globalen Compileroptionen an Javac übergeben.

manifest

Label; optional

Der Name der Android-Manifestdatei, normalerweise AndroidManifest.xml. Muss definiert werden, wenn resource_files oder Assets definiert sind.

Boolean; optional; default is False

Verwenden Sie diese Bibliothek nur für die Kompilierung und nicht zur Laufzeit. Die Ausgaben einer als neverlink markierten Regel werden beim Erstellen von .apk nicht verwendet. Dies ist nützlich, wenn die Bibliothek während der Ausführung von der Laufzeitumgebung bereitgestellt wird.
plugins

List of labels; optional

Java-Compiler-Plug-ins, die zum Zeitpunkt der Kompilierung ausgeführt werden sollen. Alle im Attribut „plugins“ angegebenen java_plugin werden bei jeder Erstellung dieses Ziels ausgeführt. Die vom Plug-in generierten Ressourcen werden in die Ergebnis-JAR-Datei des Ziels aufgenommen.
proguard_specs

List of labels; optional

Dateien, die als ProGuard-Spezifikation verwendet werden sollen. Hier werden die Spezifikationen beschrieben, die von ProGuard verwendet werden. Wenn angegeben, werden sie je nach Bibliothek jedem android_binary-Ziel hinzugefügt. Die hier enthaltenen Dateien dürfen nur idempotente Regeln haben, also „-dontnote“, „-dontwarn“, „acceptnosideeffects“ und Regeln, die mit „-keep“ beginnen. Andere Optionen können nur in den ProGuard-Spezifikationen von android_binary aufgeführt werden, um nicht-tutologische Zusammenführungen sicherzustellen.
resource_files

List of labels; optional

Die Liste der zu packenden Ressourcen. In der Regel ist dies eine glob aller Dateien im Verzeichnis res.
Auf generierte Dateien (aus Genregeln) kann auch hier durch Label verwiesen werden. Die einzige Einschränkung besteht darin, dass sich die generierten Ausgaben im selben Verzeichnisres befinden wie alle anderen enthaltenen Ressourcendateien.

Android_Instrumentierungstest

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)

Mit einer android_instrumentation_test-Regel werden Android-Instrumentierungstests ausgeführt. Er startet einen Emulator, installiert die getestete Anwendung, die Testanwendung und alle anderen erforderlichen Anwendungen und führt die im Testpaket definierten Tests aus.

Das Attribut test_app gibt die android_binary an, die den Test enthält. Diese android_binary wiederum gibt die zu testende android_binary-Anwendung über ihr instruments-Attribut an.

Beispiel

# 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",
)

Argumente

Attribute
name

Name; required

Ein eindeutiger Name für dieses Ziel.

support_apks

List of labels; optional

Andere APKs, die vor dem Instrumentierungstest auf dem Gerät installiert werden müssen.
target_device

Label; required

Das android_device, auf dem der Test ausgeführt werden soll.

Verwenden Sie die folgenden Argumente, um den Test auf einem Emulator auszuführen, der bereits ausgeführt wird, oder auf einem physischen Gerät: --test_output=streamed --test_arg=--device_broker_type=LOCAL_ADB_SERVER --test_arg=--device_serial_number=$device_identifier

test_app

Label; required

Das Ziel android_binary mit den Testklassen. Das Ziel android_binary muss über das Attribut instruments angeben, welches Ziel getestet wird.

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)

Diese Regel dient zum lokalen Testen von android_library-Regeln (statt auf einem Gerät). Es funktioniert mit dem Android Robolectric Test Framework. Weitere Informationen zum Verfassen von Robolectric-Tests finden Sie auf der Website Android Robolectric.

Implizite Ausgabeziele

  • name.jar: Ein Java-Archiv des Tests.
  • name-src.jar: Ein Archiv mit den Quellen ("source jar").
  • name_deploy.jar: Ein für die Bereitstellung geeignetes Java-Bereitstellungsarchiv (nur bei expliziter Anforderung erstellt).

Beispiele

Wenn du Robolectric mit android_local_test verwenden möchtest, füge der Datei WORKSPACE das Robolectric-Repository hinzu:

http_archive(
    name = "robolectric",
    urls = ["https://github.com/robolectric/robolectric/archive/<COMMIT>.tar.gz"],
    strip_prefix = "robolectric-<COMMIT>",
    sha256 = "<HASH>",
)
load("@robolectric//bazel:robolectric.bzl", "robolectric_repositories")
robolectric_repositories()
Dadurch werden die für Robolectric erforderlichen maven_jar-Regeln abgerufen. Dann sollte jede android_local_test-Regel von @robolectric//bazel:robolectric abhängen. Sehen Sie sich hierzu das Beispiel unten an.

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

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

Argumente

Attribute
name

Name; required

Ein eindeutiger Name für dieses Ziel.

deps

List of labels; optional

Die Liste der zu testenden Bibliotheken sowie zusätzliche Bibliotheken, die mit dem Ziel verknüpft werden sollen. Alle Ressourcen, Assets und Manifestdateien, die beim vorübergehenden Schließen dieses Attributs in den Android-Regeln angegeben wurden, werden im Test zur Verfügung gestellt.

Die Liste der zulässigen Regeln in deps ist android_library, aar_import, java_import, java_library und java_lite_proto_library.

srcs

List of labels; optional

Die Liste der Quelldateien, die zum Erstellen des Ziels verarbeitet werden. Erforderlich, außer im unten beschriebenen Sonderfall.

srcs Datei des Typs „.java“ wurde kompiliert. Um die Lesbarkeit zu erhöhen, ist es nicht empfehlenswert, den Namen einer generierten .java-Quelldatei in den srcs aufzunehmen. Gib stattdessen den Namen der abhängigen Regel in srcs ein, wie unten beschrieben.

srcs Dateien des Typs .srcjar werden entpackt und kompiliert. Dies ist nützlich, wenn Sie eine Reihe von .java-Dateien mit einer Genrule oder Build-Erweiterung generieren müssen.

Alle anderen Dateien werden ignoriert, solange mindestens eine Datei des oben beschriebenen Dateityps vorhanden ist. Andernfalls wird ein Fehler ausgegeben.

Das Attribut srcs ist erforderlich und darf nicht leer sein, es sei denn, runtime_deps ist angegeben.

custom_package

String; optional

Java-Paket, in dem die R-Klasse generiert wird. Das Paket wird standardmäßig aus dem Verzeichnis abgeleitet, in dem sich die BUILD-Datei mit der Regel befindet. Wenn Sie dieses Attribut verwenden, müssen Sie wahrscheinlich auch test_class verwenden.
densities

List of strings; optional

Dichten, nach denen beim Erstellen des APK gefiltert werden soll Dem Manifest wird außerdem ein entsprechender Abschnitt mit kompatiblen Bildschirmen hinzugefügt, wenn er noch keine überlagernde StarlarkListing-Datei enthält.
enable_data_binding

Boolean; optional; default is False

Wenn der Wert „true“ ist, verarbeitet diese Regel Verweise auf Datenbindungen, die in für diesen Test verwendeten Abhängigkeiten für die Datenbindung verwendet werden. Ohne diese Einstellung verfügen die Datenbindungsabhängigkeiten nicht über die erforderliche Codegenerierung auf binärer Ebene und können zu Build-Fehlern führen.
javacopts

List of strings; optional

Zusätzliche Compileroptionen für diese Bibliothek. Unterliegt der Ersetzung der Variable und der Bourne-Shell-Tokenisierung.

Diese Compileroptionen werden nach den globalen Compileroptionen an Javac übergeben.

jvm_flags

List of strings; optional

Eine Liste von Flags, die in das Wrapper-Skript eingebettet werden sollen, das zum Ausführen dieses Binärprogramms generiert wird. Unterliegt $(location) und "Make variable"-Ersetzung und Bourne-Shell-Tokenisierung.

Das Wrapper-Skript für ein Java-Binärprogramm enthält eine CLASSPATH-Definition (zum Ermitteln aller abhängigen JAR-Dateien) und ruft den richtigen Java-Interpreter auf. Die vom Wrapper-Skript generierte Befehlszeile enthält den Namen der Hauptklasse gefolgt von einem "$@", sodass Sie andere Argumente nach dem Klassennamen übergeben können. Argumente, die für das Parsen durch die JVM vorgesehen sind, müssen jedoch vor dem Klassennamen in der Befehlszeile angegeben werden. Der Inhalt von jvm_flags wird dem Wrapper-Skript hinzugefügt, bevor der Klassenname aufgeführt ist.

Dieses Attribut hat keine Auswirkungen auf *_deploy.jar-Ausgaben.

manifest

Label; optional

Der Name der Android-Manifestdatei, normalerweise AndroidManifest.xml. Muss definiert werden, wenn resource_files oder Assets definiert sind oder eines der Manifeste aus den zu testenden Bibliotheken das Tag minSdkVersion enthält.
manifest_values

Dictionary: String -> String; optional

Ein Wörterbuch mit Werten, die im Manifest überschrieben werden sollen. Jede Instanz von ${name} im Manifest wird durch den Wert ersetzt, der dem Namen in diesem Wörterbuch entspricht. applicationId, versionCode, versionName, minSdkVersion, targetSdkVersion und maxSdkVersion überschreiben auch die entsprechenden Attribute des Manifests und der Tags „uses-sdk“. packageName wird ignoriert und entweder über applicationId (sofern angegeben) oder über das Paket im Manifest festgelegt. Für die Verwendung von „manifest_values“ ist kein Manifest für die Regel erforderlich.
nocompress_extensions

List of strings; optional

Eine Liste der Dateiendungen, die in der Ressourcen-APK nicht komprimiert sind.
plugins

List of labels; optional

Java-Compiler-Plug-ins, die zum Zeitpunkt der Kompilierung ausgeführt werden sollen. Alle in diesem Attribut angegebenen java_plugin werden beim Erstellen dieser Regel ausgeführt. Eine Bibliothek kann auch Plug-ins von Abhängigkeiten übernehmen, die exported_plugins verwenden. Die vom Plug-in generierten Ressourcen werden in die resultierende JAR-Datei dieser Regel aufgenommen.
resource_configuration_filters

List of strings; optional

Eine Liste mit Filtern zur Ressourcenkonfiguration, z. B. „'en'“, die die Ressourcen in der APK-Datei auf die Filter in der Konfiguration beschränken.
resource_jars

List of labels; optional

Eingestellt: Verwenden Sie stattdessen java_import und deps oder runtime_deps.
resource_strip_prefix

String; optional

Das Pfadpräfix zum Entfernen aus Java-Ressourcen.

Wenn angegeben, wird dieses Pfadpräfix aus jeder Datei im Attribut resources entfernt. Es ist ein Fehler, dass eine Ressourcendatei nicht in diesem Verzeichnis enthalten ist. Falls nicht angegeben (Standardeinstellung), wird der Pfad der Ressourcendatei nach derselben Logik wie das Java-Paket der Quelldateien ermittelt. So wird beispielsweise eine Quelldatei unter stuff/java/foo/bar/a.txt unter foo/bar/a.txt gespeichert.

runtime_deps

List of labels; optional

Bibliotheken, die nur für die endgültige Binärdatei oder den Test zur Laufzeit verfügbar gemacht werden. Wie die normale deps werden sie auch im Klassenpfad der Laufzeit angezeigt, jedoch nicht im Klassenpfad zur Kompilierungszeit. Nur Abhängigkeiten, die zur Laufzeit benötigt werden, sollten hier aufgeführt sein. Tools zur Abhängigkeitsanalyse sollten Ziele ignorieren, die sowohl in runtime_deps als auch in deps enthalten sind.
stamp

Integer; optional; default is 0

Gibt an, ob Build-Informationen in das Binärprogramm codiert werden sollen. Mögliche Werte:
  • stamp = 1: Generieren Sie die Build-Informationen immer in das Binärsystem, auch in --nostamp-Builds. Diese Einstellung sollte vermieden werden, da dadurch möglicherweise das Remote-Caching für das Binärprogramm und alle davon abhängigen Downstream-Aktionen beendet wird.
  • stamp = 0: Build-Informationen immer durch konstante Werte ersetzen. Dies sorgt für gutes Caching von Build-Ergebnissen.
  • stamp = -1: Das Einbetten von Build-Informationen wird durch das Flag --[no]stamp gesteuert.

Gestempelte Binärdateien werden nur neu erstellt, wenn sich ihre Abhängigkeiten ändern.

test_class

String; optional

Die Java-Klasse, die vom Test-Runner geladen werden soll.

Dieses Attribut gibt den Namen einer Java-Klasse an, die bei diesem Test ausgeführt werden soll. Es ist nur selten erforderlich, dass Sie dies festlegen. Wird dieses Argument weggelassen, wird die Java-Klasse verwendet, deren Name der name dieser android_local_test-Regel entspricht. Die Testklasse muss mit org.junit.runner.RunWith annotiert werden.

use_launcher

Boolean; optional; default is True

Gibt an, ob für das Binärprogramm ein benutzerdefinierter Launcher verwendet werden soll.

Wenn dieses Attribut auf „false“ gesetzt ist, werden das Launcher-Attribut und das zugehörige Flag --java_launcher für dieses Ziel ignoriert.

Android-Gerät

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)

Diese Regel erstellt einen Android Emulator, der mit den angegebenen Spezifikationen konfiguriert ist. Dieser Emulator kann über einen Bazel-Befehl oder durch direkte Ausführung des generierten Skripts gestartet werden. Sie sollten sich stattdessen an die Regeln android_device halten und keine eigenen definieren.

Diese Regel ist ein geeignetes Ziel für das Flag --run_under, um Bazel-Test und -Blade-Ausführung auszuführen. Er startet einen Emulator, kopiert das getestete Ziel in den Emulator und testet es oder führt es nach Bedarf aus.

android_device unterstützt das Erstellen von KVM-Images, wenn das zugrunde liegende system_image auf X86 basiert und für die CPU-Architektur I686 optimiert ist. Fügen Sie der Regel android_device tags = ['requires-kvm'] hinzu, um KVM zu verwenden.

Implizite Ausgabeziele

  • name_images/userdata.dat: Enthält Bilddateien und Snapshots, um den Emulator zu starten
  • name_images/emulator-meta-data.pb: Enthält serialisierte Informationen, die an den Emulator übergeben werden müssen, um ihn neu zu starten.

Beispiele

Das folgende Beispiel zeigt die Verwendung von android_device. //java/android/helloandroid/BUILD enthält

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 enthält:

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

Diese Regel generiert Bilder und ein Startskript. Sie können den Emulator lokal starten, indem Sie Bazel „run :nexus_s -- --action=start“ ausführen. Das Skript macht die folgenden Flags verfügbar:

  • --adb_port: Der Port, an dem adb freigegeben wird. Wenn Sie ADB-Befehle an den Emulator senden möchten, ist dies der Port, zu dem Sie ADB-Verbindungen herstellen.
  • --emulator_port: Port, in dem die Telnet-Verwaltungskonsole des Emulators verfügbar gemacht werden soll.
  • --enable_display: Startet den Emulator mit einer Anzeige, wenn diese auf "true" gesetzt ist (standardmäßig auf "false").
  • --action: entweder starten oder beenden.
  • --apks_to_install: Eine Liste von APKs, die im Emulator installiert werden sollen.

Argumente

Attribute
name

Name; required

Ein eindeutiger Name für dieses Ziel.

cache

Integer; required

Die Größe der Cache-Partition des Emulators in Megabyte. Der Mindestwert beträgt 16 Megabyte.
default_properties

Label; optional

Eine einzelne Property-Datei, die im Verzeichnis „/default.prop“ im Emulator platziert wird. Dadurch kann der Autor der Regel den Emulator weiter so konfigurieren, dass er eher wie ein echtes Gerät aussieht (insbesondere, wenn er seine User-Agent-Strings steuert sowie andere Verhaltensweisen, die dazu führen können, dass sich eine Anwendung oder ein Server anders als ein bestimmtes Gerät verhält). Die Properties in dieser Datei überschreiben die schreibgeschützten Properties, die normalerweise vom Emulator festgelegt werden, z. B. ro.product.model.
horizontal_resolution

Integer; required

Die horizontale Bildschirmauflösung in Pixeln, die emuliert werden soll. Der Mindestwert ist 240.
platform_apks

List of labels; optional

Eine Liste von APKs, die beim Booten auf dem Gerät installiert werden sollen.
ram

Integer; required

Die RAM-Größe in Megabyte, die für das Gerät emuliert werden soll. Dies gilt für das gesamte Gerät und nicht nur für eine bestimmte App, die auf dem Gerät installiert ist. Der Mindestwert beträgt 64 Megabyte.
screen_density

Integer; required

Die Dichte des emulierten Bildschirms in Pixeln pro Zoll. Der Mindestwert beträgt 30 ppi.
system_image

Label; required

Eine Dateigruppe mit den folgenden Dateien:
  • system.img: Die Systempartition
  • kernel-qemu: Der Linux-Kernel, den der Emulator lädt
  • ramdisk.img: Initrd-Image, das beim Booten verwendet wird
  • userdata.img: Die erste Partition der Nutzerdaten
  • „source.properties“: Eine Property-Datei mit Informationen zu den Bildern
Diese Dateien sind Teil des Android SDK oder werden von Drittanbietern bereitgestellt (z. B. stellt Intel x86-Bilder bereit).
vertical_resolution

Integer; required

Die vertikale Bildschirmauflösung in Pixeln, die emuliert werden soll. Der Mindestwert ist 240.
vm_heap

Integer; required

Die Größe des VM-Heaps, den Android für jeden Prozess benötigt, in Megabyte. Der Mindestwert beträgt 16 Megabyte.

android_ndk_repository

android_ndk_repository(name, api_level, path, repo_mapping)

Konfiguriert Bazel so, dass ein Android-NDK zur Erstellung von Android-Zielen mit nativem Code verwendet wird.

Für das Erstellen von Android-Geräten ist in der Datei WORKSPACE außerdem die Regel android_sdk_repository erforderlich.

Weitere Informationen finden Sie in der vollständigen Dokumentation zur Verwendung von Android NDK mit Bazel.

Beispiele

android_ndk_repository(
    name = "androidndk",
)

Im obigen Beispiel wird dein Android-NDK von $ANDROID_NDK_HOME ermittelt und die höchste unterstützte API-Ebene erkannt.

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

Im Beispiel oben wird der Android-NDK in Ihrem Arbeitsbereich in ./android-ndk-r20 verwendet. Es verwendet die API-Level-24-Bibliotheken beim Kompilieren Ihres JNI-Codes.

CPU-Funktionen

Das Android-NDK enthält die cpufeatures-Bibliothek, mit der die CPU eines Geräts zur Laufzeit erkannt werden kann. Im folgenden Beispiel wird gezeigt, wie Sie CPU-Features mit Bazel verwenden.

# jni.cc
#include "ndk/sources/android/cpufeatures/cpu-features.h"
...
# BUILD
cc_library(
    name = "jni",
    srcs = ["jni.cc"],
    deps = ["@androidndk//:cpufeatures"],
)

Argumente

Attribute
name

Name; required

Ein eindeutiger Name für dieses Ziel.

api_level

Integer; optional; nonconfigurable; default is 0

Android-API-Level, auf dem die App erstellt werden kann. Wenn nicht angegeben, wird die höchste installierte API-Ebene verwendet.
path

String; optional; nonconfigurable

Ein absoluter oder relativer Pfad zu einem Android-NDK. Es muss entweder dieses Attribut oder die Umgebungsvariable $ANDROID_NDK_HOME festgelegt werden.

Du kannst den Android NDK von der Website für Android-Entwickler herunterladen.

repo_mapping

Dictionary: String -> String; optional

Ein Wörterbuch vom lokalen Repository-Namen zum globalen Repository-Namen. Dies ermöglicht die Kontrolle der Auflösung von Arbeitsbereichsabhängigkeiten für Abhängigkeiten dieses Repositorys.

Der Eintrag "@foo": "@bar" gibt beispielsweise an, dass diese Abhängigkeit für jedes Mal, wenn dieses Repository von "@foo" abhängt (z. B. eine Abhängigkeit von "@foo//some:target"), tatsächlich innerhalb der global deklarierten "@bar" ("@bar//some:target") aufgelöst werden soll.

Android SDK

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

Konfiguriert Bazel so, dass für die Erstellung von Android-Zielen ein lokales Android SDK verwendet wird.

Beispiele

Wenn Sie ein Android SDK für Bazel einrichten möchten, müssen Sie mindestens die Regel android_sdk_repository mit dem Namen „androidsdk&quot“ in die Datei WORKSPACE einfügen und die Umgebungsvariable $ANDROID_HOME auf den Pfad des Android SDK festlegen. Bazel verwendet standardmäßig die höchste Android API-Level- und Build-Tools-Version, die im Android SDK installiert ist.
android_sdk_repository(
    name = "androidsdk",
)

Um reproduzierbare Builds zu gewährleisten, können die Attribute path, api_level und build_tools_version auf bestimmte Werte gesetzt werden. Der Build schlägt fehl, wenn im Android SDK die angegebene API-Level- oder Build-Tools-Version nicht installiert ist.

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

Das Beispiel oben zeigt auch die Verwendung eines relativen relativen Arbeitsbereichs zum Android SDK. Dies ist nützlich, wenn das Android SDK Teil Ihres Bazel-Arbeitsbereichs ist (z.B. wenn es für die Versionsverwaltung eingecheckt ist).

Supportbibliotheken

Die Support-Bibliotheken sind im Android SDK Manager als Android Support Repository verfügbar. Dies ist ein versionierter Satz gängiger Android-Bibliotheken wie die Support- und AppCompat-Bibliotheken, die als lokales Maven-Repository verpackt sind. android_sdk_repository generiert Bazel-Ziele für jede dieser Bibliotheken, die in den Abhängigkeiten von android_binary- und android_library-Zielen verwendet werden können.

Die Namen der generierten Ziele werden von den Maven-Koordinaten der Bibliotheken im Android Support Repository abgeleitet, die als @androidsdk//${group}:${artifact}-${version} formatiert sind. Das folgende Beispiel zeigt, wie ein android_library von Version 25.0.0 der v7-Appcompat-Bibliothek abhängen kann.

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

Argumente

Attribute
name

Name; required

Ein eindeutiger Name für dieses Ziel.

api_level

Integer; optional; nonconfigurable; default is 0

Das Android-API-Level, auf dem standardmäßig ein Build erstellt werden soll. Wenn nicht angegeben, wird die höchste installierte API-Ebene verwendet.

Die für einen bestimmten Build verwendete API-Ebene kann mit dem Flag android_sdk überschrieben werden. android_sdk_repository erstellt ein android_sdk-Ziel für jede im SDK installierte API-Ebene mit dem Namen @androidsdk//:sdk-${level}, unabhängig davon, ob dieses Attribut angegeben ist oder nicht. Ein Beispiel für einen Build auf einer nicht standardmäßigen API-Ebene: bazel build --android_sdk=@androidsdk//:sdk-19 //java/com/example:app.

Wenn Sie alle von android_sdk_repository generierten android_sdk-Ziele ansehen möchten, können Sie bazel query "kind(android_sdk, @androidsdk//...)" ausführen.

build_tools_version

String; optional; nonconfigurable

Die Version der Android-Build-Tools, die im Android SDK verwendet werden kann. Wenn nicht angegeben, wird die neueste Version der Build-Tools verwendet.

Bazel erfordert Build-Tools, Version 30.0.0 oder höher.

path

String; optional; nonconfigurable

Ein absoluter oder relativer Pfad zu einem Android SDK. Es muss entweder dieses Attribut oder die Umgebungsvariable $ANDROID_HOME festgelegt werden.

Du kannst das Android SDK von der Website für Android-Entwickler herunterladen.

repo_mapping

Dictionary: String -> String; optional

Ein Wörterbuch vom lokalen Repository-Namen zum globalen Repository-Namen. Dies ermöglicht die Kontrolle der Auflösung von Arbeitsbereichsabhängigkeiten für Abhängigkeiten dieses Repositorys.

Der Eintrag "@foo": "@bar" gibt beispielsweise an, dass diese Abhängigkeit für jedes Mal, wenn dieses Repository von "@foo" abhängt (z. B. eine Abhängigkeit von "@foo//some:target"), tatsächlich innerhalb der global deklarierten "@bar" ("@bar//some:target") aufgelöst werden soll.