Internal @AndroidIncompatible docs:

- It's not for prod APIs.
- It works through a special MOE config.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=153202986

guava-tests/test/com/google/common/base/AndroidIncompatible.java

@@ -32,35 +32,37 @@
  * Google-internal Android suite generators. Note that those generators also suppress any test
  * annotated with MediumTest or LargeTest.
  *
+ *
  * <p>Why use a custom annotation instead of {@code android.test.suitebuilder.annotation.Suppress}?
  * I'm not completely sure that this is the right choice, but it has various advantages:
  *
  * <ul>
- * <li>An annotation named just "Suppress" might someday be treated by a non-Android tool as a
- * suppression. This would follow the precedent of many of our annotation processors, which look for
- * any annotation named, e.g., "GwtIncompatible," regardless of package.
- * <li>An annotation named just "Suppress" might suggest to users that the test is suppressed under
- * all environments. We could fight this by fully qualifying the annotation, but the result will be
- * verbose and attention-grabbing.
- * <li>We need to be careful about how we suppress {@code suite()} methods in {@code common.io}. The
- * generated suite for {@code FooTest} ends up containing {@code FooTest} itself plus some other
- * tests. We want to exclude the other tests (which Android can't handle) while continuing to run
- * {@code FooTest} itself. This is exactly what happens with {@code AndroidIncompatible}. But I'm
- * not sure what would happen if we annotated the {@code suite()} method with {@code Suppress}.
- * Would {@code FooTest} itself be suppressed, too?
- * <li>In at least one case, a use of {@code sun.misc.FpUtils}, the test will not even
- * <i>compile</i> against Android. Now, this might be an artifact of our build system, one that we
- * could probably work around. Or we could manually strip the test from open-source Guava while
- * continuing to run it internally, as we do with many other tests. This would suffice because we
- * our Android users and tests are using the open-source version, which would no longer have the
- * problematic test. But why bother when we can instead strip it with a more precisely named
- * annotation?
- * <li>While a dependency on Android ought to be easy if it's for annotations only, it will probably
- * require adding the dep to various whitelists, license files, and Proguard configurations, and
- * there's always the potential that something will go wrong. It <i>probably</i> won't, since the
- * deps are needed only in tests (and maybe someday in testlib), but why bother?
- * <li>Stripping code entirely might help us keep under the method limit someday. Even if it never
- * comes to that, it may at least help with build and startup times.
+ *   <li>An annotation named just "Suppress" might someday be treated by a non-Android tool as a
+ *       suppression. This would follow the precedent of many of our annotation processors, which
+ *       look for any annotation named, e.g., "GwtIncompatible," regardless of package.
+ *   <li>An annotation named just "Suppress" might suggest to users that the test is suppressed
+ *       under all environments. We could fight this by fully qualifying the annotation, but the
+ *       result will be verbose and attention-grabbing.
+ *   <li>We need to be careful about how we suppress {@code suite()} methods in {@code common.io}.
+ *       The generated suite for {@code FooTest} ends up containing {@code FooTest} itself plus some
+ *       other tests. We want to exclude the other tests (which Android can't handle) while
+ *       continuing to run {@code FooTest} itself. This is exactly what happens with {@code
+ *       AndroidIncompatible}. But I'm not sure what would happen if we annotated the {@code
+ *       suite()} method with {@code Suppress}. Would {@code FooTest} itself be suppressed, too?
+ *   <li>In at least one case, a use of {@code sun.misc.FpUtils}, the test will not even
+ *       <i>compile</i> against Android. Now, this might be an artifact of our build system, one
+ *       that we could probably work around. Or we could manually strip the test from open-source
+ *       Guava while continuing to run it internally, as we do with many other tests. This would
+ *       suffice because we our Android users and tests are using the open-source version, which
+ *       would no longer have the problematic test. But why bother when we can instead strip it with
+ *       a more precisely named annotation?
+ *   <li>While a dependency on Android ought to be easy if it's for annotations only, it will
+ *       probably require adding the dep to various whitelists, license files, and Proguard
+ *       configurations, and there's always the potential that something will go wrong. It
+ *       <i>probably</i> won't, since the deps are needed only in tests (and maybe someday in
+ *       testlib), but why bother?
+ *   <li>Stripping code entirely might help us keep under the method limit someday. Even if it never
+ *       comes to that, it may at least help with build and startup times.
  * </ul>
  */
 @Retention(CLASS)