tree: a6bb1406dfd5109b6128cfa73c5682768a8c72f1 [path history] [tgz]
  1. foundry/
  2. native/
  3. sdk/
  4. src/
  5. test/
  6. testSrc/
  7. agent_coverage_reports.py
  8. android.bzl
  9. android.sdktools.base.bazel.iml
  10. antlr.bzl
  11. bazel
  12. bazel.bzl
  13. bazel.cmd
  14. BUILD
  15. common.bazel.rc
  16. coverage.bzl
  17. coverage.py
  18. coverage_report.bzl
  19. darwin.bazel.rc
  20. diff.bzl
  21. emulator.bzl
  22. functions.bzl
  23. gradle.bzl
  24. groovy.bzl
  25. jacoco_to_lcov.py
  26. jasmin.bzl
  27. kotlin.bzl
  28. linux.bazel.rc
  29. maven.bzl
  30. merge_archives.bzl
  31. proto.bzl
  32. qa_emu_setup.py
  33. README.md
  34. repositories.bzl
  35. stats.sh
  36. studio_coverage.sh
  37. studio_linux.sh
  38. studio_mac.sh
  39. studio_win.cmd
  40. targets
  41. targets.coverage
  42. targets.coverage.instrumentation
  43. targets.coverage.psq
  44. targets.win
  45. test_studio.sh
  46. toplevel.WORKSPACE
  47. utils.bzl
  48. windows.bazel.rc
bazel/README.md

Building and Testing with Bazel

This directory contains the core files to run studio-master-dev tests using bazel.

Running 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 $PATH)

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

Running all the tests

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 bazel-testlogs/pkg/target/test.xml (or test.log)

To run all the tests found in tools/base:

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/targets contains 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:

bazel test //tools/adt/idea/android/... --test_filter=AndroidLayoutDomTest --test_output=streamed

To debug a single test, which will open remote debugging:

bazel test //tools/adt/idea/android/... --test_filter=AndroidLayoutDomTest --java_debug

Useful Bazel options

  • --nocache_test_results may be required if you are trying to re-run a test without changing anything.
  • --test_filter=<TestName> to run a specific test

Running with coverage

We currently do not use the in-built Bazel coverage support.

To gather coverage from tests define agent_coverage=true, e.g.

bazel test --define agent_coverage=true //tools/...

To create the coverage reports (xml and html) from those test logs run

tools/base/bazel/agent_coverage_reports.py

The reports will be output to out/agent-coverage/

BUILD files

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 iml_module rule.

Note that we modify these BUILD files manually, so whenever you make a change to an .iml file, its corresponding BUILD file will have to be changed. This should be done using bazel run //tools/base/bazel:iml_to_build. If you create a new .iml file, you must create the corresponding (empty) BUILD file before running iml_to_build.

iml_module

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:

  • name: The production library for this module.
  • name_testlib: The test library for this module.
  • name_tests: The test target to run this module's tests.

Example

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]",
    ],
)
AttributeDescription
nameThe name of the rule (usually matching Studio's module name).
srcsA list of directories containing the sources. .java, .groovy, .kotlin and .form files are supported.
resourcesA list directories with the production resources.
depsA tag-enhanced list of dependencies, of the form //label[tag1,tag2,...]. Supported tags are: module, for iml_module dependencies, and test for test only dependencies.
test_srcsA list of directories with the test sources.
test_resourcesA list of directories with the test resources.
test_dataA list of files needed to run the test.
excludeA list of files to be excluded from both src and test_srcs. This requires a change to tools/idea/.idea/compiler.xml
test_timeoutThe 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_data attribute. This is essential to determining which test targets need to be run when an arbitrary file has changed.

Circular Dependencies

Just don't. IntelliJ has support for circular dependencies of modules, but we do not use it in our code base.

Additional tools

There are several other tools in this package that can be used to manage dependencies in prebuilts.

third_party_build_generator

Used to generate //tools/base/third_party/BUILD. Computes effective versions of all necessary dependencies and creates a java_library rule for each one of them. It will also download missing jars into //prebuilts/tools/common/m2/repository.

Invoked by running:

bazel run //tools/base/bazel:third_party_build_generator

The tool looks for names and versions of libraries in //tools/buildSrc/base/dependencies.properties. The same file is read by our Gradle scripts, to keep the set of dependencies consistent between the two.

add_dependency

Can be used to download one or more Maven artifacts (JARs, AARs or APKs) into prebuilts, including all transitive dependencies.

Invoked by running:

bazel run //tools/base/bazel:add_dependency com.example:foo:1.0 com.example:android-lib:aar:1.0

You can also use it to download protoc binaries, like this:

bazel run //tools/base/bazel:add_dependency com.google.protobuf:protoc:exe:linux-x86_64:3.0.0

The tool by default uses Maven Central, JCenter and the Google Maven repository. You can add more (like a staging repository for libraries to be pushed to maven.google.com) using a flag:

bazel run //tools/base/bazel:add_dependency -- --repo=https://example.com/m2 com.example:foo:1.0

java_import_generator

Creates a BUILD file for every POM file in the prebuilts maven repo. Both of the binaries above do the same, but this can be useful if prebuilts was modified using Gradle's cloneArtifacts tasks or manually.

Invoked by running:

bazel run //tools/base/bazel:java_import_generator