Rules
- 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)
Produces Android application package files (.apk).
Implicit output targets
name.apk: An Android application package file signed with debug keys and zipaligned, it could be used to develop and debug your application. You cannot release your application when signed with the debug keys.name_unsigned.apk: An unsigned version of the above file that could be signed with the release keys before release to the public.name_deploy.jar: A Java archive containing the transitive closure of this target.The deploy jar contains all the classes that would be found by a classloader that searched the runtime classpath of this target from beginning to end.
name_proguard.jar: A Java archive containing the result of running ProGuard on thename_deploy.jar. This output is only produced if proguard_specs attribute is specified.name_proguard.map: A mapping file result of running ProGuard on thename_deploy.jar. This output is only produced if proguard_specs attribute is specified and proguard_generate_mapping or shrink_resources is set.
Examples
Examples of Android rules can be found in the examples/android directory of the
Bazel source tree.
Arguments
| Attributes | |
|---|---|
name |
A unique name for this target. |
deps
|
android_library,
java_library with android constraint and
cc_library wrapping or producing .so native libraries for the
Android target platform.
|
srcs
|
|
assets
|
glob of all files under the
assets directory. You can also reference other rules (any rule that produces
files) or exported files in the other packages, as long as all those files are under the
assets_dir directory in the corresponding package.
|
assets_dir
|
assets.
The pair assets and assets_dir describe packaged
assets and either both attributes should be provided or none of them.
|
crunch_png
|
|
custom_package
|
|
debug_key
|
WARNING: Do not use your production keys, they should be strictly safeguarded and not kept in your source tree. |
debug_signing_keys
|
WARNING: Do not use your production keys, they should be strictly safeguarded and not kept in your source tree. |
debug_signing_lineage_file
|
WARNING: Do not use your production keys, they should be strictly safeguarded and not kept in your source tree. |
densities
|
|
dex_shards
|
Note that each shard will result in at least one dex in the final app. For this reason, setting this to more than 1 is not recommended for release binaries. |
dexopts
|
|
enable_data_binding
|
To build an Android app with data binding, you must also do the following:
|
incremental_dexing
|
|
instruments
|
The If this attribute is set, this |
javacopts
|
These compiler options are passed to javac after the global compiler options. |
key_rotation_min_sdk
|
|
main_dex_list
|
android/support/multidex/MultiDex$V19.class
android/support/multidex/MultiDex.class
android/support/multidex/MultiDexApplication.class
com/google/common/base/Objects.class
Must be used with multidex="manual_main_dex".
|
main_dex_list_opts
|
|
main_dex_proguard_specs
|
multidex attribute is set to legacy.
|
manifest
|
AndroidManifest.xml.
Must be defined if resource_files or assets are defined.
|
manifest_values
|
|
multidex
|
Possible values:
|
nocompress_extensions
|
|
package_id
|
See AAPT2's |
plugins
|
java_plugin specified in
the plugins attribute will be run whenever
this target is built. Resources generated by
the plugin will be included in the result jar of
the target.
|
proguard_apply_dictionary
|
|
proguard_apply_mapping
|
proguard_generate_mapping to be
re-used to apply the same mapping to a new build.
|
proguard_generate_mapping
|
proguard_specs is
specified. This file will list the mapping between the original and
obfuscated class, method, and field names.
WARNING: If this attribute is used, the Proguard
specification should contain neither |
proguard_specs
|
|
resource_configuration_filters
|
en_XA and/or ar_XB pseudo-locales.
|
resource_files
|
glob of all files under the
res directory.
Generated files (from genrules) can be referenced by Label here as well. The only restriction is that the generated outputs must be under the same " res" directory as any other
resource files that are included.
|
shrink_resources
|
manifest and resource_files attributes) and requires ProGuard.
It operates in mostly the same manner as the Gradle resource shrinker
(https://developer.android.com/studio/build/shrink-code.html#shrink-resources).
Notable differences:
name_files/resource_shrinker.log
will also be generated, detailing the analysis and deletions performed.
Possible values:
|
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)
This rule allows the use of .aar files as libraries for
android_library and
android_binary rules.
Examples
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"],
)
Arguments
| Attributes | |
|---|---|
name |
A unique name for this target. |
aar
|
.aar file to provide to the Android targets that depend on this target.
|
exports
|
|
srcjar
|
|
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)
This rule compiles and archives its sources into a .jar file.
The Android runtime library android.jar is implicitly put on
the compilation class path.
Implicit output targets
libname.jar: A Java archive.libname-src.jar: An archive containing the sources ("source jar").name.aar: An android 'aar' bundle containing the java archive and resources of this target. It does not contain the transitive closure.
Examples
Examples of Android rules can be found in the examples/android directory of the
Bazel source tree.
The following example shows
how to set idl_import_root.
Let //java/bazel/helloandroid/BUILD contain:
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"],
)
Arguments
| Attributes | |
|---|---|
name |
A unique name for this target. |
deps
|
android_library,
java_library with android constraint and
cc_library wrapping or producing .so native libraries
for the Android target platform.
|
srcs
|
.java or .srcjar files that
are processed to create the target.
If |
assets
|
glob of all files under the
assets directory. You can also reference other rules (any rule that produces
files) or exported files in the other packages, as long as all those files are under the
assets_dir directory in the corresponding package.
|
assets_dir
|
assets.
The pair assets and assets_dir describe packaged
assets and either both attributes should be provided or none of them.
|
custom_package
|
|
enable_data_binding
|
To build an Android app with data binding, you must also do the following:
|
exported_plugins
|
java_plugins (e.g. annotation
processors) to export to libraries that directly depend on this library.
The specified list of |
exports
|
exports attributes
are considered direct dependencies of any rule that directly depends on the
target with exports.
The |
exports_manifest
|
android_binary targets
that depend on this target. uses-permissions attributes are never exported.
|
idl_import_root
|
This path will be used as the import root when processing idl sources that depend on this library. When See examples. |
idl_parcelables
|
android_library target that depends on this library, directly
or via its transitive closure, but will not be translated to Java
or compiled.
Only These files must be placed appropriately for the aidl compiler to find them. See the description of idl_import_root for information about what this means. |
idl_preprocessed
|
android_library target that depends on this library, directly
or via its transitive closure, but will not be translated to Java
or compiled.
Only preprocessed |
idl_srcs
|
srcs.
These files will be made available as imports for any
These files must be placed appropriately for the aidl compiler to find them. See the description of idl_import_root for information about what this means. |
javacopts
|
These compiler options are passed to javac after the global compiler options. |
manifest
|
AndroidManifest.xml.
Must be defined if resource_files or assets are defined.
|
neverlink
|
neverlink will not be used in
.apk creation. Useful if the library will be provided by the
runtime environment during execution.
|
plugins
|
java_plugin specified in
the plugins attribute will be run whenever
this target is built. Resources generated by
the plugin will be included in the result jar of
the target.
|
proguard_specs
|
android_binary target depending on this library.
The files included here must only have idempotent rules, namely -dontnote, -dontwarn,
assumenosideeffects, and rules that start with -keep. Other options can only appear in
android_binary's proguard_specs, to ensure non-tautological merges.
|
resource_files
|
glob of all files under the
res directory.
Generated files (from genrules) can be referenced by Label here as well. The only restriction is that the generated outputs must be under the same " res" directory as any other
resource files that are included.
|
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)
An android_instrumentation_test rule runs Android instrumentation tests. It will
start an emulator, install the application being tested, the test application, and
any other needed applications, and run the tests defined in the test package.
The test_app attribute specifies the
android_binary which contains the test. This android_binary in turn
specifies the android_binary application under test through its
instruments attribute.
Example
# 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",
)
Arguments
| Attributes | |
|---|---|
name |
A unique name for this target. |
support_apks
|
|
target_device
|
The android_device the test should run on. To run the test on an emulator that is already running or on a physical device, use
these arguments:
|
test_app
|
android_binary target must specify which target it is testing through
its instruments attribute.
|
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)
This rule is for unit testing android_library rules locally
(as opposed to on a device).
It works with the Android Robolectric testing framework.
See the Android Robolectric site for details about
writing Robolectric tests.
Implicit output targets
name.jar: A Java archive of the test.name-src.jar: An archive containing the sources ("source jar").name_deploy.jar: A Java deploy archive suitable for deployment (only built if explicitly requested).
Examples
To use Robolectric with android_local_test, add
Robolectric's
repository to your WORKSPACE file:
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()
This pulls in the maven_jar rules needed for Robolectric.
Then each android_local_test rule should depend on
@robolectric//bazel:robolectric. See example below.
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",
)
Arguments
| Attributes | |
|---|---|
name |
A unique name for this target. |
deps
|
The list of allowed rules in |
srcs
|
All other files are ignored, as long as there is at least one file of a file type described above. Otherwise an error is raised.
The |
custom_package
|
test_class as well.
|
densities
|
|
enable_data_binding
|
|
javacopts
|
These compiler options are passed to javac after the global compiler options. |
jvm_flags
|
The wrapper script for a Java binary includes a CLASSPATH definition
(to find all the dependent jars) and invokes the right Java interpreter.
The command line generated by the wrapper script includes the name of
the main class followed by a Note that this attribute has no effect on |
manifest
|
AndroidManifest.xml.
Must be defined if resource_files or assets are defined or if any of the manifests from
the libraries under test have a minSdkVersion tag in them.
|
manifest_values
|
applicationId, versionCode, versionName,
minSdkVersion, targetSdkVersion and
maxSdkVersion will also override the corresponding attributes
of the manifest and
uses-sdk tags. packageName will be ignored and will be set from either
applicationId if
specified or the package in the manifest.
It is not necessary to have a manifest on the rule in order to use manifest_values.
|
nocompress_extensions
|
|
plugins
|
java_plugin specified in this attribute will be run whenever this rule
is built. A library may also inherit plugins from dependencies that use
exported_plugins. Resources
generated by the plugin will be included in the resulting jar of this rule.
|
resource_configuration_filters
|
|
resource_jars
|
|
resource_strip_prefix
|
If specified, this path prefix is stripped from every file in the |
runtime_deps
|
deps, these will appear on the runtime classpath, but unlike
them, not on the compile-time classpath. Dependencies needed only at runtime should be
listed here. Dependency-analysis tools should ignore targets that appear in both
runtime_deps and deps.
|
stamp
|
Stamped binaries are not rebuilt unless their dependencies change. |
test_class
|
This attribute specifies the name of a Java class to be run by
this test. It is rare to need to set this. If this argument is omitted, the Java class
whose name corresponds to the |
use_launcher
|
If this attribute is set to false, the
launcher attribute and the related
|
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)
This rule creates an android emulator configured with the given specifications. This emulator may be started via a bazel run command or by executing the generated script directly. It is encouraged to depend on existing android_device rules rather than defining your own.
This rule is a suitable target for the --run_under flag to bazel test and blaze run. It starts an emulator, copies the target being tested/run to the emulator, and tests it or runs it as appropriate.
android_device supports creating KVM images if the underlying
system_image is X86 based and is
optimized for at most the I686 CPU architecture. To use KVM add
tags = ['requires-kvm'] to the android_device rule.
Implicit output targets
name_images/userdata.dat: Contains image files and snapshots to start the emulatorname_images/emulator-meta-data.pb: Contains serialized information necessary to pass on to the emulator to restart it.
Examples
The following example shows how to use android_device.
//java/android/helloandroid/BUILD contains
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 contains:
ro.product.brand=google ro.product.device=crespo ro.product.manufacturer=samsung ro.product.model=Nexus S ro.product.name=soju
This rule will generate images and a start script. You can start the emulator locally by executing bazel run :nexus_s -- --action=start. The script exposes the following flags:
- --adb_port: The port to expose adb on. If you wish to issue adb commands to the emulator this is the port you will issue adb connect to.
- --emulator_port: The port to expose the emulator's telnet management console on.
- --enable_display: Starts the emulator with a display if true (defaults to false).
- --action: Either start or kill.
- --apks_to_install: a list of apks to install on the emulator.
Arguments
| Attributes | |
|---|---|
name |
A unique name for this target. |
cache
|
|
default_properties
|
|
horizontal_resolution
|
|
platform_apks
|
|
ram
|
|
screen_density
|
|
system_image
|
|
vertical_resolution
|
|
vm_heap
|
|
android_ndk_repository
android_ndk_repository(name, api_level, path, repo_mapping)
Configures Bazel to use an Android NDK to support building Android targets with native code.
Note that building for Android also requires an android_sdk_repository rule in your
WORKSPACE file.
For more information, read the full documentation on using Android NDK with Bazel.
Examples
android_ndk_repository(
name = "androidndk",
)
The above example will locate your Android NDK from $ANDROID_NDK_HOME and detect
the highest API level that it supports.
android_ndk_repository(
name = "androidndk",
path = "./android-ndk-r20",
api_level = 24,
)
The above example will use the Android NDK located inside your workspace in
./android-ndk-r20. It will use the API level 24 libraries when compiling your JNI
code.
cpufeatures
The Android NDK contains the cpufeatures library which can be used to detect a device's CPU at runtime. The following example demonstrates how to use cpufeatures with Bazel.
# jni.cc #include "ndk/sources/android/cpufeatures/cpu-features.h" ...
# BUILD
cc_library(
name = "jni",
srcs = ["jni.cc"],
deps = ["@androidndk//:cpufeatures"],
)
Arguments
| Attributes | |
|---|---|
name |
A unique name for this target. |
api_level
|
|
path
|
$ANDROID_NDK_HOME environment variable must be set.
The Android NDK can be downloaded from the Android developer site . |
repo_mapping
|
For example, an entry |
android_sdk_repository
android_sdk_repository(name, api_level, build_tools_version, path, repo_mapping)
Configures Bazel to use a local Android SDK to support building Android targets.
Examples
The minimum to set up an Android SDK for Bazel is to put anandroid_sdk_repository rule
named "androidsdk" in your WORKSPACE file and set the $ANDROID_HOME
environment variable to the path of your Android SDK. Bazel will use the highest Android API level
and build tools version installed in the Android SDK by default.
android_sdk_repository(
name = "androidsdk",
)
To ensure reproducible builds, the path, api_level and
build_tools_version attributes can be set to specific values. The build will fail if
the Android SDK does not have the specified API level or build tools version installed.
android_sdk_repository(
name = "androidsdk",
path = "./sdk",
api_level = 19,
build_tools_version = "25.0.0",
)
The above example also demonstrates using a workspace-relative path to the Android SDK. This is useful if the Android SDK is part of your Bazel workspace (e.g. if it is checked into version control).
Support Libraries
The Support Libraries are available in the Android SDK Manager as "Android Support Repository".
This is a versioned set of common Android libraries, such as the Support and AppCompat libraries,
that is packaged as a local Maven repository. android_sdk_repository generates Bazel
targets for each of these libraries that can be used in the dependencies of
android_binary and android_library targets.
The names of the generated targets are derived from the Maven coordinates of the libraries in the
Android Support Repository, formatted as @androidsdk//${group}:${artifact}-${version}.
The following example shows how an android_library can depend on version 25.0.0 of the
v7 appcompat library.
android_library(
name = "lib",
srcs = glob(["*.java"]),
manifest = "AndroidManifest.xml",
resource_files = glob(["res/**"]),
deps = ["@androidsdk//com.android.support:appcompat-v7-25.0.0"],
)
Arguments
| Attributes | |
|---|---|
name |
A unique name for this target. |
api_level
|
The API level used for a given build can be overridden by the To view all |
build_tools_version
|
Bazel requires build tools version 30.0.0 or later. |
path
|
$ANDROID_HOME environment variable must be set.
The Android SDK can be downloaded from the Android developer site. |
repo_mapping
|
For example, an entry |