Skip to main content

Rules

android_binary

View rule sourceopen_in_new
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 the name_deploy.jar. This output is only produced if proguard_specs attribute is specified.
  • name_proguard.map: A mapping file result of running ProGuard on the name_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

aar_import

View rule sourceopen_in_new
This rule allows the use of .aar files as libraries for android_library and android_binary rules.

Examples

Arguments

android_library

View rule sourceopen_in_new
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:

Arguments

android_instrumentation_test

View rule sourceopen_in_new
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

Arguments

android_local_test

View rule sourceopen_in_new
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:
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.

Arguments

android_device

View rule sourceopen_in_new
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 emulator
  • name_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
//java/android/helloandroid/nexus_s.properties contains:
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

android_ndk_repository

View rule sourceopen_in_new
Configures Bazel to use an Android NDK to support building Android targets with native code. Note that this implementation of android_ndk_repository is being replaced by an implementation in Starlark. Support for future versions of the NDK including version 25 and up will be implemented in the Starlark version of android_ndk_repository. See rules_android_ndk for the Starlark version. 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

The above example will locate your Android NDK from $ANDROID_NDK_HOME and detect the highest API level that it supports.
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.

Arguments

android_sdk_repository

View rule sourceopen_in_new
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 an android_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.
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.
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.

Arguments