Use --revert-annotation instead of --hide-annotation
Use of `--hide-annotation android.annotation.FlaggedApi` was always an intermediate solution until the required semantics for `@FlaggedApi` was determined. The `--revert-annotation` option provides those semantics. When the `@FlaggedApi` is applied to an existing API, e.g. because it has moved from system to public, or because it has changed in some way, e.g. modifiers, then the correct semantics for when that API is not required is not to hide the API but to revert it to what it was before the change necessitating the `@FlaggedApi` annotation was made. Use --revert-annotation instead of --hide-annotation Use of `--hide-annotation android.annotation.FlaggedApi` was always an intermediate solution until the required semantics for `@FlaggedApi` was determined. The `--revert-annotation` option provides those semantics. When the `@FlaggedApi` is applied to an existing API, e.g. because it has moved from system to public, or because it has changed in some way, e.g. modifiers, then the correct semantics for when that API is not required is not to hide the API but to revert it to what it was before the change necessitating the `@FlaggedApi` annotation was made. Use --revert-annotation instead of --hide-annotation Use of `--hide-annotation android.annotation.FlaggedApi` was always an intermediate solution until the required semantics for `@FlaggedApi` was determined. The `--revert-annotation` option provides those semantics. When the `@FlaggedApi` is applied to an existing API, e.g. because it has moved from system to public, or because it has changed in some way, e.g. modifiers, then the correct semantics for when that API is not required is not to hide the API but to revert it to what it was before the change necessitating the `@FlaggedApi` annotation was made. Bug: 314196587 Test: ./gradlew Change-Id: Ic97f29dd2b9f598ba0851f5f622c2a2724f18037
Loading
Please register or sign in to comment