This directory contains the core files to run studio-main tests using bazel.
Bazel has the concept of a workspace: the root of all your source files. For us, it is where we
repo init our source tree. For google3 vets, this is the “google3” directory. In this document we assume the current directory to be the workspace, but note that bazel can be run from anywhere in the tree.
Bazel is checked-in at
tools/base/bazel/bazel. To make things easy you might want to link it like this (assuming
~/bin is in
ln -s <workspace>/tools/base/bazel ~/bin/bazel
Then no matter where you are in the workspace, bazel will find the right platform-specific binary and run it.
macOS users:_ You may run into a clang error after reinstalling or updating XCode. To resolve this error, clear bazel of previous configurations with the following command:
$ bazel clean --expunge
The command to run all the bazel tests run by the PSQ is:
bazel test $(<tools/base/bazel/targets)
The test output is typically present in
To run all the tests found in
bazel test //tools/base/...
To run all the tests in the IntelliJ Android plugin:
bazel test //tools/adt/idea/android/...
Note: The file
tools/base/bazel/targetscontains the up-to-date list of test targets.
To build Studio without running the tests:
bazel build //tools/adt/idea/...
To run a single test:
# when test splitting is used, specify the $moduleName_tests__all target bazel test //tools/adt/idea/android:intellij.android.core.tests_tests__all --test_filter=AndroidLayoutDomTest --test_output=streamed
To debug a single test, which will open remote debugging:
bazel test //tools/adt/idea/android:intellij.android.core.tests_tests__all --test_filter=AndroidLayoutDomTest --java_debug
--nocache_test_resultsmay be required if you are trying to re-run a test without changing anything.
--test_filter=<TestName>to run a specific test (when test splits are not already in use)
We currently do not use the in-built Bazel coverage support.
To enable a test in coverage runs do the following:
java_test, then you need to replace it with
To build a coverage report do: ./tools/base/bazel/coverage/report.sh
BUILD files define a package with a set build and test rules. In order to support Android Studio we created a new kind of rule, that matches an IntelliJ module: the
Note that we modify these BUILD files manually, so whenever you make a change to an
.imlfile, its corresponding
BUILDfile will have to be changed. This should be done using
bazel run //tools/base/bazel:iml_to_build. If you create a new
.imlfile, you must create the corresponding (empty)
BUILDfile before running
iml_module(name, srcs, test_srcs, exclude, resources, test_resources, deps, test_runtime_deps, visibility, exports,javacopts, test_data, test_timeout, test_class, test_shard_count, tags)
This rule will generate the targets:
iml_module( name = "android", srcs = ["src/main/java"], resources = ["src/main/resources"], test_data = glob(["testData/**"]), test_resources = ["src/test/resources"], test_srcs = ["src/test/java"], deps = [ "//a/module/only/needed/in/tests:name[module, test]", "//a/standard/java/dependency:dep", "//path/to/libs:junit-4.12[test]", "//path/to/module:name[module]", ], )
|The name of the rule (usually matching Studio's module name).|
|A list of directories containing the sources. .java, .groovy, .kotlin and .form files are supported.|
|A list directories with the production resources.|
|A tag-enhanced list of dependencies, of the form |
|A list of directories with the test sources.|
|A list of directories with the test resources.|
|A list of files needed to run the test.|
|A list of files to be excluded from both src and test_srcs. This requires a change to tools/idea/.idea/compiler.xml|
|The timeout value of the test, see: blaze timeout|
A major difference with actual iml modules is that in bazel we must specify the files needed to run the tests. These files are known as runfiles and are specified via the
test_dataattribute. This is essential to determining which test targets need to be run when an arbitrary file has changed.
More details on the implementation of the
iml_module rule can be found in docs/iml-module.md.
Just don't. IntelliJ has support for circular dependencies of modules, but we do not use it in our code base.
In order to fetch new Maven artifacts into the local Maven repository under
//prebuilts/tools/common/m2/, follow these steps:
If the artifact is needed as a compile or runtime Java dependency in Bazel, then add it to
If the artifact will only be used in tests as data (i.e., passed into
maven_repository rules), then add it to
In order to use the new artifact, use
@maven//: prefix. If you added your artifact to
artifacts, then do not add the artifact version, if you added your artifact to
data, then use the artifact version. E.g.,
@maven//:com.google.guava.guava" (for artifacts) @maven//:com.google.guava.guava_30.1-jre` (for data).
@maven//prefix points to a dynamically generated Bazel-external repository. You can access the generated file at
Check-in your new artifact (and any new transitive dependencies) under
Check-in generated changes to the
toplevel.WORKSPACE file for examples on how to express non-jar dependency types and classifiers (e.g.,