# android-test: the AndroidX Test libraries and their Bazel support

> The android-test repository publishes the AndroidX Test libraries, including Espresso, and separately carries Bazel rules for android_instrumentation_test. The release notes and the artifacts themselves live elsewhere, which makes the repository confusing to read until you know which half you need.

**android/android-test** — An extensive framework for testing Android apps

- Repository: https://github.com/android/android-test
- Website: https://android.github.io/android-test
- Stars: 1,230 · Forks: 343
- Language: Java
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/android-android-test

## android-test hosts two separate things

The first thing to understand about this repository is that it is not a single product. The project documentation opens by saying it hosts two somewhat distinct projects: the AndroidX Test libraries, and Bazel support for android_instrumentation_test.

The first half is the one most Android developers eventually meet. It is described as an extensive framework for testing Android apps, providing APIs to build and run test code, including JUnit 4 tests and functional user interface tests, runnable from Android Studio or from the command line. The tests are written against the same public API that any app developer would consume, so the library is the reference implementation of the testing surface rather than a project with a command line of its own.

The second half is build tooling. It provides the repository rules needed to depend on android_test_support from a Bazel workspace, which matters for teams that have moved part of their build off Gradle and do not want to reimplement the instrumentation test target.

The audience is therefore two at once: Android application developers who hit a problem inside the test framework, and build engineers who need the Bazel integration. Reading the repository without knowing which of the two you want is the most common way to get lost in it.

## Espresso and the runner are the pieces you actually depend on

The libraries published from this repository are listed in the project documentation, and the list is short enough to be worth reading in full. It covers androidx.test:annotation, androidx.test:core, androidx.test.espresso with its variants, androidx.test.ext:junit, androidx.test:orchestrator, androidx.test:runner, androidx.test:rules and androidx.test:services.

The division of labour is worth spelling out. Espresso is the functional user interface testing library, the part that drives views inside the app under test. The runner is the piece that actually executes tests on a device. The rules and the services modules supply the JUnit rule scaffolding and the supporting services, annotation holds the custom annotation types, and orchestrator addresses the problem of running each test in its own process so that state does not leak between them.

Two adjacent libraries are explicitly not here. androidx.test.uiautomator and androidx.test.ext:junit-gtest are hosted on AOSP instead, in the platform support frameworks tree. That distinction matters when you are chasing a bug, because the source you need for a uiautomator problem is in a different repository with a different history and a different release process.

The official documentation for the framework lives at developers.android.com/testing rather than in this repository.

## Bazel users wire the repository through repo.bzl

The Bazel half is compact and self-contained. To depend on the repository, the project documentation gives a snippet to add to the WORKSPACE file:

```python
ATS_TAG = "<release-tag>"
http_archive(
    name = "android_test_support",
    sha256 = "<sha256 of release>",
    strip_prefix = "android-test-%s" % ATS_TAG,
    urls = ["https://github.com/android/android-test/archive/%s.tar.gz" % ATS_TAG],
)
load("@android_test_support//:repo.bzl", "android_test_repositories")
android_test_repositories()
```

The mechanics are conventional. The archive is fetched over HTTP by tag, verified against a checksum the caller supplies, and then a `load` pulls in the `repo.bzl` file that registers the repositories the test support needs. The two placeholders in the snippet are the tag and the checksum, which have to be filled in for a specific release.

The repository layout supports both worlds. Directories such as `api/`, `core/`, `espresso/`, `ext/`, `runner/`, `services/`, `ktx/`, `testapps/` and `tools/` correspond to the published modules, and files such as `repo.bzl`, `BUILD`, `six.BUILD`, `MODULE.bazel`, `WORKSPACE`, `.bazelrc` and `.bazelversion` are the Bazel side. There is also a `Dockerfile` and a `kokoro/` directory, which is the continuous integration system Google uses internally.

## The Dockerfile pins Bazel 3.5.0 and a command line tools archive

The container image in the repository is the clearest statement of the toolchain the project expects. It starts from a published Bazel image and pins the version explicitly:

```dockerfile
FROM l.gcr.io/google/bazel:3.5.0

ENV ANDROID_HOME /android-sdk
ENV PATH ${ANDROID_HOME}/tools:$ANDROID_HOME/platform-tools:$ANDROID_HOME/tools/bin:/bin:$PATH

RUN \
    rm -f /usr/local/lib/libc++.so && \
    apt-get -q update && \
    apt-get -q -y install maven \
    unzip \
    zip \
    wget && \
    wget -nv https://dl.google.com/android/repository/commandlinetools-linux-6609375_latest.zip && \
    unzip -q commandlinetools-linux-6609375_latest.zip -d $ANDROID_HOME && \
    yes | sdkmanager --install 'build-tools;30.0.2' 'platforms;android-31' --sdk_root=$ANDROID_HOME | grep -v = || true
```

Two details are worth noticing. The base image is Bazel 3.5.0, which is old, and the SDK is not taken from a system package but downloaded and unpacked by the build itself, with `build-tools;30.0.2` and `platforms;android-31` installed through sdkmanager. The removal of `/usr/local/lib/libc++.so` is there because it conflicts with aapt, and the file carries a note asking why the incompatibility exists, which tells you the workaround outlived the question.

The practical consequence is that the container reproduces a build environment of a specific vintage. It is useful for reproducing the project's own continuous integration, and it is not a template for a current Android build, where a much newer Bazel and a current platform would be expected.

## Release notes and artifacts live outside the repository

The maintenance picture is split across three places, and the project documentation is explicit about which is which. The canonical source for release notes is the AndroidX Test releases page on developer.android.com, and the release artifacts and source snapshots are hosted on maven.google.com. The repository itself carries the changelog template used to write those notes, in CHANGELOG_TEMPLATE.md, but the notes themselves are published elsewhere.

That arrangement is normal for a Google-owned library that ships to maven.google.com, and it has a practical effect: someone browsing the repository for a changelog will not find one in the usual place. The release tags in the repository are dated by the AndroidX Test release naming scheme, and the most recent ones listed are axt_06_26_2024 and axt_06_24_2024, both published on 2024-06-26, with axt_2024_05_30, a release candidate, on 2024-05-30.

The repository itself is not archived, and the last push was on 2026-10-19, so commits continue to land in the tree. The gap between that commit activity and the tag dates in the release list is the signal to read: day to day work continues, and the tagged stable points in the list are older than the tree. The licence is Apache-2.0, which permits use and modification in commercial products with attribution and preservation of the licence and NOTICE file, and that matters here because the library ships inside applications rather than beside them.

## UIAutomator and the native test bridge are where this stops

The clearest limit on this repository is that it does not contain everything the AndroidX Test family covers. The uiautomator library and the native JUnit bridge for GoogleTest are hosted on AOSP, so a project that needs those pieces is assembling its test stack from at least two source trees, with different release cadences and different contribution processes.

The second limit is about debugging rather than adoption. This is library source code, not a service, and there is no support channel beyond a GitHub issue tracker, an AndroidX Test Discuss mailing list for general questions, and Stack Overflow for specific ones. The contributing guide is the entry point for anything else. For a developer whose Espresso test fails, that is usually enough, but for a team trying to decide whether to run their entire instrumented test suite on this repository, there is no compatibility matrix or support statement in the documentation to lean on.

A third limit follows from the Bazel integration being tied to WORKSPACE. The snippet in the project documentation is written for the WORKSPACE file, and the repository also contains a MODULE.bazel, but the documented path is the older one. Teams that have moved to Bzlmod would be reading the documentation's snippet and inferring the shape of the equivalent, which the project does not spell out.

## Espresso or uiautomator is a design decision, not a preference

The meaningful alternative to this framework is not another test library but a different scope of test, and the choice changes the whole setup.

Espresso, which is published from this repository, tests inside your own app process. It can reach views and application objects directly, which makes assertions precise and failures readable, and it is the right tool for the majority of UI behaviour in an app you own. UIAutomator, hosted on AOSP, drives the device from the outside through the accessibility layer, so it can interact with other applications, the system dialogs, and the notification shade. That outside-in reach is exactly what Espresso does not have, and it is also what makes UIAutomator slower and its failures harder to interpret.

The practical difference is scope versus clarity. A team with a single app and a large surface of UI behaviour will get more from Espresso and less flakiness. A team testing a flow that crosses into the camera app, a permission prompt or a system share sheet needs UIAutomator or an orchestrated mix of the two. The cost of mixing is the dependency surface, since the pieces come from different repositories, and the difference in debugging experience, since an out-of-process failure gives a much thinner stack trace.

## Conclusion

android-test is the right place to look if you are debugging a test build, want to read how the AndroidX Test libraries are assembled, or need the Bazel rules rather than the Gradle ones. It is the wrong place to find release notes, to find the uiautomator or junit-gtest sources, or to get a quick start. Verify first that the artifact you depend on is one of the modules published from this repository rather than one hosted on AOSP, and read the release notes at the AndroidX Test releases page before assuming the version in the repository is the version you have.

## FAQ

### Which libraries are published from the android-test repository?

The repository hosts androidx.test:annotation, androidx.test:core, androidx.test.espresso and its variants, androidx.test.ext:junit, androidx.test:orchestrator, androidx.test:runner, androidx.test:rules and androidx.test:services. androidx.test.uiautomator and androidx.test.ext:junit-gtest are hosted on AOSP instead.

### How do I add android-test to a Bazel WORKSPACE file?

Declare an http_archive named android_test_support with the release tag and its sha256, then load `android_test_repositories` from `@android_test_support//:repo.bzl` and call it. The snippet is given in the project documentation with the tag and checksum left as placeholders.

### Where can I find the release notes and artifacts for AndroidX Test?

The canonical source for release notes is the AndroidX Test releases page on developer.android.com, and the release artifacts and source snapshots are on maven.google.com. The repository holds the changelog template rather than the published notes.

### Should I use Espresso or UIAutomator for my Android UI tests?

Espresso tests inside your own app process and gives precise assertions on your own views, while UIAutomator drives the device from outside and can reach other applications and system dialogs. Espresso ships from this repository and UIAutomator ships from AOSP, so a mixed setup draws on two source trees.

## Sources

- [android/android-test on GitHub](https://github.com/android/android-test)
- [License: Apache-2.0](https://github.com/android/android-test/blob/main/LICENSE)
- [Project website](https://android.github.io/android-test)
- [README](https://github.com/android/android-test/blob/main/README.md)
- [Releases](https://github.com/android/android-test/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/android-android-test