They were added to workaround the problem of package-private versions
being added to the stubs, which prevented use of the annotations from
mainline modules.
Having them in the API leads to a different problem -- this version of
the nullability annotations have SOURCE retention. However in the stubs
build we want to have CLASS retention, so that kotlin can make use of
their presence.
This is arguably a much cleaner fix, since having a source-retention
annotation doesn't really make much sense.
Bug: 157010342
Test: m
Change-Id: Id78f00da5b6af2930224a82faa24cb8235362521
Merged-In: Id78f00da5b6af2930224a82faa24cb8235362521
Makes the javadocs more applicable to scenarios
where the client is receiving a non-null parameter
or returning a non-null value.
Bug: 150289352
Test: Not applicable.
Change-Id: If800dc9abcb20f00c1b73c71379465ea812b43ec
These two annotations are already in the public/system stubs,
but are re-written to be package private instead of public. This
makes them inaccessible to libs building against these stubs.
When setting sdk_version:<X>, the stubs of X will appear before any
other libraries on the classpath. This also makes it impossible for
modules to add Nullable annotations of their own when setting sdk_version.
Exposing these annotations as public in the module stubs makes it
possible for modules using these annotation to specify an sdk_version.
Bug: 146758669
Test: m
Test: downstream CLs using sdk_version:module_current
Change-Id: I71fb766d02f833ed9a1b3a7dbfbc1c8118882b30
The new annotation is android.compat.annotation.UnsupportedAppUsage.
Test: m
Bug: 145132366
Exempt-From-Owner-Approval: approved in internal
Change-Id: Ie12e28eee0ed20b5677ee3162143700813b7ab64
Merged-In: Ie12e28eee0ed20b5677ee3162143700813b7ab64
The new annotation is android.compat.annotation.UnsupportedAppUsage.
Test: m
Bug: 145132366
Exempt-From-Owner-Approval: previously approved change
Change-Id: Ie12e28eee0ed20b5677ee3162143700813b7ab64
- MODULE_APPS is considered to be too confusing, we're going to remove it, and
may revive it once ART is able to support runtime protection
- Change SYSTEM_SERVER to a "client".
Test: Build / treehugger
Bug: 148177503
Change-Id: Id847e29ab211c4c009c234a2e1e469575914e12e
This allows us to annotate a class as below:
/** @hide */
@SystemApi
@SystemApi(client=MODULE_APPS)
public class SomeClass {
/** @hide */ @SystemApi
public void foo() {...}
/** @hide */ @SystemApi(client=MODULE_APPS)
public void bar() {...}
}
SomeClass is already annotated as @SystemApi. And we want to make bar()
method in it as SystemApi(MODULE_APPS). To do so, the containing class
SomeClass has additionally to be annotated as SystemApi(MODULE_APPS),
resulting SystemApi annotation to be repeated.
Bug: N/A
Test: add @SystemApi(client=MODULE_APPS) to an hidden method of an
existing SystemApi class (e.g. SystemProperties.set()) and execute `m
updata-api`.
-> api/module-app-current.txt is updated while
api/system-current.txt is unchanged
Change-Id: Ifd4d32a6983cfc38f0dd13618652439f6162e0d3
Remove import of Context to allow this annotation
to be statically linked easily.
Bug: 142886292
Test: compiles
Change-Id: I74b02d562a9df1729e4046c7a1e6d5d8033f21e2
* changes:
Hide com.android.server package with @hide javadoc tag
Add more enums for the client and process attributes of SystemApi
SystemApi is parameterized
This is not a stable API surface, so modules shouldn't be building
against it. Compiling against core_platform also disables link-checking,
which can hide other problems.
Bug: 137191822
Test: m
Change-Id: I7ce7dad8c02b094c565daf8c178bc6f89bb610ef
Some internal changes are depending more strongly on annotations
being "leaves" which don't directly reference other parts of the OS,
so replace the direct import of Intent with a qualified javadoc
reference.
Bug: 144247087
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: I198d84a755b5e270a19b41328f6a6e152112c40a
Merged-In: I198d84a755b5e270a19b41328f6a6e152112c40a
The "core_platform" SDK technically includes non-stable APIs, so we
need to shift to "core_current" instead.
While we're here, tidy up some older @removed APIs that never shipped
and replace HexEncoding with a local implementation.
Since MediaProvider itself is free to use @hide APIs from its own
framework code in MediaStore.java, we can include all sources
from "framework-mediaprovider-sources" directly.
Also since the "framework-annotations" filegroup in Android.bp is
a very limited subset of leaf source code, it can't directly
reference Intent, so adjust the javadoc so we can drop the "import."
Bug: 144247087
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: I198d84a755b5e270a19b41328f6a6e152112c40a
For the client attribute, we have
- MODULE_APPS for representing APKs implementing modules which are
considered part of the platform
- MODULE_LIBRARIES for representing jars inside modules.
For the process attribute, we have
- SYSTEM_SERVER for representing the system_server process.
For example, @SystemApi(client=MODULE_LIBRARIES,process=ALL) actually
means that the API is meant to be available for classes in the
bootclasspath but not to the classes from the app classloader.
Bug: 140202860
Test: m
Exempt-From-Owner-Approval: cherry-picked from internal
Merged-In: Iba6a564a0967e4d109164849ee6d6500d46469de
(cherry picked from commit 88d5e494c4)
Change-Id: Iba6a564a0967e4d109164849ee6d6500d46469de
For the client attribute, we have
- MODULE_APPS for representing APKs implementing modules which are
considered part of the platform
- MODULE_LIBRARIES for representing jars inside modules.
For the process attribute, we have
- SYSTEM_SERVER for representing the system_server process.
For example, @SystemApi(client=MODULE_LIBRARIES,process=ALL) actually
means that the API is meant to be available for classes in the
bootclasspath but not to the classes from the app classloader.
Bug: 140202860
Test: m
Change-Id: Iba6a564a0967e4d109164849ee6d6500d46469de
We have decided to reuse the existing annotation @SystemApi for all Java
APIs regardless of whether they are for apps or platform internal
modules. This was because introducing new annotation types every time
when we have to create new API surfaces will only increase the confusion
without giving much benefit.
Instead, to differenciate the different API surfaces of @SystemApi, the
annotation type is parameterized. Specifically, it has to axises.
client: specifies the intended client of the API.
process: specifies the process(es) that the API is available.
The default for client and process are priv-apps and all, respectively,
which corresponds to the today's @SystemApi for privileged apps like
GMS.
Exempt-From-Owner-Approval: cherry-pick from internal
Bug: 140202860
Test: m
Merged-In: I3305b71e22970e80db95f3daf3d7713603c7d68d
(cherry picked from commit 119afc0695)
Change-Id: I3305b71e22970e80db95f3daf3d7713603c7d68d
We have decided to reuse the existing annotation @SystemApi for all Java
APIs regardless of whether they are for apps or platform internal
modules. This was because introducing new annotation types every time
when we have to create new API surfaces will only increase the confusion
without giving much benefit.
Instead, to differenciate the different API surfaces of @SystemApi, the
annotation type is parameterized. Specifically, it has to axises.
client: specifies the intended client of the API.
process: specifies the process(es) that the API is available.
The default for client and process are priv-apps and all, respectively,
which corresponds to the today's @SystemApi for privileged apps like
GMS.
Bug: 140202860
Test: m
Change-Id: I3305b71e22970e80db95f3daf3d7713603c7d68d
This change adds android.annotation.Hide class which can be used
to hide an API without using the @hide javadoc tag. This opens up the
possibility of running metalava over the compiled jar, which is expected
to be much faster than when ran with source files.
In the short-term, this will be only used inside services.jar and not for
framework.jar.
Bug: 139391334
Test: m
Exempt-From-Owner-Approval: cherry-pick from internal
Merged-In: I589f1deb63e621a96a76d2f613d283c2d3cdfd17
(cherry picked from commit 404b9b2cf2)
Change-Id: I589f1deb63e621a96a76d2f613d283c2d3cdfd17
This change adds android.annotation.Hide class which can be used
to hide an API without using the @hide javadoc tag. This opens up the
possibility of running metalava over the compiled jar, which is expected
to be much faster than when ran with source files.
In the short-term, this will be only used inside services.jar and not for
framework.jar.
Bug: 139391334
Test: m
Change-Id: I589f1deb63e621a96a76d2f613d283c2d3cdfd17
The property is currently set by the AIDL compiler to indicate the original
position of the annotation in the AIDL file. Use this position in
preference to the annotation position within Java code if it's present.
Also rework the tests to use the google compile-testing library rather than
my crufty javac library. This makes testing failure conditions much nicer.
Bug: 145120552
Test: atest unsupportedappusage-processor-test
Test: m framework-annotation-proc
Change-Id: Icaac9b40672dce028095b578c19950b688506c0d
Annotation for APIs that use context.getUser/getUserId to execute as other users
Bug:143738055
Test: -
Change-Id: Ieeb54812bcdc5ce0b8ee4a7cfd37aa692712efd6
The mention of P in the doc was unclear. Also, listing the specific
values allowed is a maintenance issue.
Test: None
Change-Id: I9c46eec353090ecd822f10a0a9e8433fa46246a0
Add a new field to UnsupportedAppUsage, to allow specifying public API
alternatives to hidden APIs. This change mirrors the one in libcore.
Bug: 130721457
Test: m
Change-Id: I12592db123fab1ced2d62fbf507c13cade0ef0ba
Initial efforts at cleaning up MediaStore docs, including deprecation
of crufty methods, and annotations to communicate stored units.
Bug: 120429729, 124013019
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I87828f19030b6b354472c1b3ce767de166f86134
Add some words aimed at app developers, to help ensure that devs are
aware of the implications of using annotated members. Also add a link
to the public info on non-SDK interfaces, which includes a feature
request link.
Also use the term "non-SDK interface" in the docs as this is what is
used externally in the blog posts.
Test: m
Change-Id: I936e53082e308f484dfd42ba56a3575b78b6d3aa
Allows the signature of implicit members, i.e. members that are added
by the compiler, e.g. enum values() and valueOf(String) methods or
default constructors to be specified per class. The UnsupportedAppUsage
can now be repeated on a class so as to specify multiple implicit
members.
Bug: 119861512
Test: atest class2greylisttest, m -j20 framework
Change-Id: I73c8402e9c2053e3a04ef0ff8875ce446593ec8f
This will be used by the runtime to limit access to APIs based on their
targetSdkVersion in the manifest.
When adding new maxTargetSdk values to non-SDK interfaces, we use the
SDK version of the latest major (i.e. new letter) release of Android
that has been made public. e.g. while Q is in development, we add new
maxTargetSdk values of 28 (Build.VERSION_CODES.P), even if a P MR1 has
already been released.
We do this because:
- It reduces the number of distinct SDK levels that have to be
considered and enforced in the runtime.
- Using past releases means that there is always a well established
value to use.
See go/hidden-api-annotations for more context.
Test: m
Bug: 110868826
Change-Id: Idbe78510acf538ce941a9a61a64fcc0bdc4de38e
This annotation will be added to existing hidden methods and fields that are
known to be used by apps.
These annotations will be used to replace the existing hard coded greylist
text files.
See go/hidden-api-annotations for more context.
Test: m
Bug: 110868826
Change-Id: I1b86ad8460525c2896fb84d7f1f95a521f582b9c
Certain APIs require that a device have a specific feature to operate
correctly, so start annotating them.
Test: builds, boots
Bug: 72284763
Change-Id: Ie2f30284bdfdb6acc4067f434eba3b5433837606
Exempt-From-Owner-Approval: simple annotations
SystemApi annotation is now retained at runtime in order for the
CtsSignatureTest to extract the list of System APIs from the device and
compare it with the known list of the APIs. Until now, the test only
ensured that the known list of the APIs exist in the device, but didn't
ensured the opposite. In order words, it was possible for device
manufacturers to revive the APIs that were once deleted. This will
become a problem when SystemAPIs will be allowed to non-system partitions
such as vendor. An apk in the vendor partition which is using the
revived-but-officially-deleted System API will break when the system
partition is replaced with the Generic System Image (GSI) built from
AOSP, which doesn't have the deleted API. (Running CTS on GSI is part of
the Treble compliance tests)
The overhead of retaining this annotation at runtime is small, because
the relationship from an entity (a class, a field, a member, etc) to the
annotation is recorded as a 4 byte offset field [1].
[1] https://source.android.com/devices/tech/dalvik/dex-format#annotations-directory
Bug: 70832217
Bug: 67891551
Test: measure the size increment before and after. framework.jar was
increased by 2964 byte.
Change-Id: I679b19ac5ce57d33ce59e32b3b1753f8a1962e11
