Mark test-suite-builder suites and related code as @AndroidIncompatible
.
#7632
+683
−289
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.
Mark test-suite-builder suites and related code as
@AndroidIncompatible
.(Along the way, break out
SynchronizedSetTest.TestSet
into a top-level typeLockHeldAssertingSet
, which should also make it easier to run each test in an individual build target someday.)(I did also sneak in one change to the backport copy of
IteratorsTest
. It resolve a diff that we accidentally introduced in cl/613629330.)Such code is already not run when we run our tests under Android emulators. (The Android JUnit 3 runner just ignores
suite()
methods, I want to say?) However, it's still built for them. Besides being a waste, this requires pulling in the whole suite-builder ecosystem, which is again causing problems when I try to bump various things related to Android version—quite possibly a sign that the Android runner starts actually usingsuite()
methods, whose large numbers of tests (at least incommon.collect
) are just too much for that environment? By adding@AndroidIncompatible
, I configure our Android test build to strip the code altogether.RELNOTES=n/a