Android testing is broken with Bazel 4.2.1

[meteorcloudy]

https://buildkite.com/bazel/android-testing/builds/1621#cb6c258b-3b33-4421-8f99-d46a2118eece

(00:19:04) ERROR: /workdir/ui/espresso/IntentsAdvancedSample/BUILD.bazel:29:16: Building ui/espresso/IntentsAdvancedSample/libIntentsAdvancedSampleTestLib.jar (2 source files) failed: (Exit 1): java failed: error executing command
  (cd /var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/ec321eb2cc2d0f8f91b676b6d4c66c29/execroot/__main__ && \
  exec env - \
    LC_CTYPE=en_US.UTF-8 \
    PATH=/var/lib/buildkite-agent/.cache/bazelisk/downloads/bazelbuild/bazel-4.2.1-linux-x86_64/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
  external/remotejdk11_linux/bin/java -XX:+UseParallelOldGC -XX:-CompactStrings '--patch-module=java.compiler=external/remote_java_tools_linux/java_tools/java_compiler.jar' '--patch-module=jdk.compiler=external/remote_java_tools_linux/java_tools/jdk_compiler.jar' '--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED' '--add-opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED' '--add-opens=java.base/java.nio=ALL-UNNAMED' '--add-opens=java.base/java.lang=ALL-UNNAMED' -jar external/remote_java_tools_linux/java_tools/JavaBuilder_deploy.jar @bazel-out/android-armeabi-v7a-fastbuild/bin/ui/espresso/IntentsAdvancedSample/libIntentsAdvancedSampleTestLib.jar-0.params @bazel-out/android-armeabi-v7a-fastbuild/bin/ui/espresso/IntentsAdvancedSample/libIntentsAdvancedSampleTestLib.jar-1.params)
Execution platform: @local_config_platform//:host
ui/espresso/IntentsAdvancedSample/app/src/androidTest/java/com/example/android/testing/espresso/intents/AdvancedSample/ImageViewHasDrawableMatcher.java:19: error: cannot find symbol
import androidx.test.espresso.matcher.BoundedDiagnosingMatcher;
                                     ^
  symbol:   class BoundedDiagnosingMatcher
  location: package androidx.test.espresso.matcher
ui/espresso/IntentsAdvancedSample/app/src/androidTest/java/com/example/android/testing/espresso/intents/AdvancedSample/ImageViewHasDrawableMatcher.java:32: error: cannot find symbol
        return new BoundedDiagnosingMatcher<View, ImageView>(ImageView.class) {
                   ^
  symbol:   class BoundedDiagnosingMatcher
  location: class ImageViewHasDrawableMatcher
ui/espresso/IntentsAdvancedSample/app/src/androidTest/java/com/example/android/testing/espresso/intents/AdvancedSample/ImageViewHasDrawableMatcher.java:33: error: method does not override or implement a method from a supertype
            @Override
            ^
ui/espresso/IntentsAdvancedSample/app/src/androidTest/java/com/example/android/testing/espresso/intents/AdvancedSample/ImageViewHasDrawableMatcher.java:38: error: method does not override or implement a method from a supertype
            @Override
            ^

Since Android Testing is broken with Bazel 4.2.1 for a long time, I'll disable it in Bazel downstream. Android testing will no longer get any test coverage with Bazel@HEAD, but we can re-enable it in downstream when this issue is fixed.

[meteorcloudy]

/cc @brettchabot @jin

[mrk-han]

All of the bazel builds are still failing every day -- we can either make a ticket to address these if we find Bazel Experimental Support still worth showing people how to do, or we can disable the automatic trigger + remove from the readme (maybe a product decision perhaps?)

https://buildkite.com/bazel/android-testing/builds?branch=main

[brettchabot]

@jin @ahumesky should we just disable bazel support in this project for now?

[ahumesky]

We're currently open sourcing a starlark version of android_instrumentation_test, so I think that as part of that project we can (and should) fix up the example here both to a) work and b) use the starlark version of android_instrumentation_test. For now I think disabling the tests sounds right, since there's no sense in repeatedly running tests that will always fail. As we open source the starlark version of android_instrumenation_test over the next few months I think we can also use these to test the rule.

[mrk-han]

It'd be awesome to see this repo test the new starlark version of android_instrumentation_test.

Disabling sounds great, especially if y'all can add a task to fix these examples as part of starlark's open source acceptance criteria IMHO