Android Rules

android_binary

android_binary(name, deps, srcs, aapt_version, assets, assets_dir, compatible_with, crunch_png, custom_package, debug_key, densities, deprecation, dex_shards, dexopts, distribs, enable_data_binding, exec_compatible_with, exec_properties, features, incremental_dexing, instruments, javacopts, licenses, main_dex_list, main_dex_list_opts, main_dex_proguard_specs, manifest, manifest_values, multidex, nocompress_extensions, plugins, proguard_apply_dictionary, proguard_apply_mapping, proguard_generate_mapping, proguard_specs, resource_configuration_filters, resource_files, restricted_to, shrink_resources, tags, 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 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

          android/support/multidex/MultiDex$V19.class
          android/support/multidex/MultiDex.class
          android/support/multidex/MultiDexApplication.class
          com/google/common/base/Objects.class
                    

aar_import

aar_import(name, deps, data, aar, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, licenses, restricted_to, srcjar, tags, 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

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, 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

android_instrumentation_test

android_instrumentation_test(name, data, args, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, flaky, licenses, local, restricted_to, shard_count, size, support_apks, tags, 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

android_local_test

android_local_test(name, deps, srcs, data, aapt_version, args, compatible_with, custom_package, deprecation, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, licenses, local, manifest, manifest_values, nocompress_extensions, plugins, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, test_class, testonly, timeout, toolchains, 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()

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

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, 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 bazel 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

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

android_ndk_repository

android_ndk_repository(name, api_level, path)

Configures Bazel to use an Android NDK to support building Android targets with native code. NDK versions 10 up to 16 are currently supported.

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-r12b",
    api_level = 24,
)

The above example will use the Android NDK located inside your workspace in ./android-ndk-r12b. 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

android_sdk_repository

android_sdk_repository(name, api_level, build_tools_version, path)

Configures Bazel to use a local Android SDK to support building Android targets.

Examples

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