Add Android instrumentation test sample#688
Open
bc-lee wants to merge 3 commits into
Open
Conversation
Add a Bzlmod-only Android instrumentation testing sample that builds a small Java Android app and runs an AndroidX/JUnit4 instrumentation test on a connected local device. Add a small Starlark android_instrumentation_test rule that consumes rules_android's ApkInfo and AndroidInstrumentationInfo providers. The rule adds the target APK, instrumentation APK, Android SDK tools, and AndroidX Test host-side runner to runfiles, then leaves local device selection to the local_device Bazel config. Vendor AndroidX Test through a separate third_party/android-test Bazel module and repository-rule overlay. Keeping AndroidX Test in its own module avoids forcing the root sample module to carry AndroidX Test's dependency graph and overrides directly. Patch the generated AndroidX Test repository for local retail devices: make dalvik.vm.dexopt-flags updates best-effort because upstream assumes a rooted/userdebug device, and fall back to /data/anr/traces.txt when dalvik.vm.stack-trace-file is absent. The sample also uses @RunWith(AndroidJUnit4.class) so AndroidX Test's dex parser discovers JUnit4 methods without relying on legacy android.test APIs. Pass Bazel's Android SDK dexdump into the AndroidX Test host runner instead of using AndroidX Test's embedded Linux dexdump_annotations resource. The embedded binary does not run on macOS, which breaks local device test discovery before instrumentation starts. Overlay TestInfoRepository so the generated AndroidX Test repository uses modern SDK-compatible dexdump arguments, canonicalizes APK paths before invoking dexdump, and normalizes the modern annotation preamble back into the XML shape expected by AndroidX Test's legacy parser. Add a focused normalizer test that feeds the normalized output through DumpUtils.parseDexDump. This covers both JUnit4 annotation discovery and the dalvik.annotation.AnnotationDefault parser behavior needed after switching away from the embedded binary.
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bazel 9 removed Android instrumentation test support from Bazel itself, and the community outside Google is now left to build its own solutions.
I understand that, unlike other platforms,
rules_android, AndroidX Test (android-test), and related tooling are heavily integrated with google3, and that the current open source versions expose only a subset of the full internal capability. Still, to better support the broader Bazel community, we need a common baseline for important Android use cases such as running instrumentation tests.This example is intentionally narrow in scope. It does not manage Android emulators, so users must prepare a device or emulator before invoking
bazel test. It currently supports only a local device through adb. However, this sample should provide useful ground for future work, such as remote devices, emulator management, or other execution environments.This PR takes two main approaches:
Adds a small
android_instrumentation_testrule under the sample'sbazeldirectory to provide the Android instrumentation test capability that was removed from Bazel 9. The rule wires the target APK, instrumentation APK, Android SDK tools, and AndroidX Test host-side runner into a Bazel test.Vendors AndroidX Test support as a standalone Bazel module under
third_party/android-test. The module uses an overlay to make the upstream AndroidX Test source archive compatible with Bazel 9 and Bzlmod, and also carries the local-device adjustments needed for assumptions that work in Google's environment but not on typical community/retail-device setups.The overlay also avoids AndroidX Test's embedded Linux-only
dexdump_annotationsbinary by passing Bazel's Android SDKdexdumpinto the host runner and normalizing its modern output for AndroidX Test's legacy parser. This keeps the sample usable from both Linux and macOS hosts.The sample includes a small Java Android target, an AndroidX/JUnit4 instrumentation test, README instructions for
ANDROID_HOMEand.bazelrc.user, and alocal_deviceBazel configuration for running the test against a connected device.Tested on both Linux and macOS hosts with Bazel 9.1.0:
bazelisk build //app/... --verbose_failures bazelisk test //app/src/main:greeter_instrumentation_test \ --config=local_device \ --test_output=errors \ --verbose_failures \ --nocache_test_resultsAlso tested on Linux with Bazel 8.x, resolved by Bazelisk to Bazel 8.6.0:
USE_BAZEL_VERSION=8.x bazelisk build //app/... --verbose_failures USE_BAZEL_VERSION=8.x bazelisk test //app/src/main:greeter_instrumentation_test \ --config=local_device \ --test_output=errors \ --verbose_failures \ --nocache_test_results