Merge "Doc updates for #apex and #systemapi" am: 357ebe5e6d am: 61734dfbb6

Original change: https://android-review.googlesource.com/c/platform/build/soong/+/2407675

Change-Id: Ide9a8b81ff2b0689d7c488bb7df67cba5324aec2
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
This commit is contained in:
Spandan Das 2023-02-01 02:48:49 +00:00 committed by Automerger Merge Worker
commit b0c62e6c9f

View file

@ -148,9 +148,24 @@ from access via `dlsym`, but this is not always possible.
### systemapi
This is a synonym of the `apex` tag. It should be used to clarify that the API
is an API exposed by the system for an APEX, whereas `apex` should be used for
APIs exposed by an APEX to the platform or another APEX.
Indicates that the symbol is exposed by the platform for an apex. Whereas `apex`
should be used for APIs exposed by an APEX to the platform or another APEX.
May be used in combination with `llndk` if the symbol is exposed to both APEX
and the LL-NDK.
Since a single library can be installed ether in platform or an apex, but not
both, a single map.txt file should not contain _both_ # apex and # systemapi symbols.
The granularity between # apex and # systemapi exists to help the API review
process (b/191371676). These two symbols have very similar lifetime "in
practice". A #systemapi symbol can be dropped from the next release if we are
confident that no one is using it. Similarily, #apex can be dropped if we are
sure that the old platform which used the symbol has reached EOL and thus is no
longer accepting new APEX updates. Unlike the APIs for apps where we have zero
control over how APIs are used, we are in a much more controllable environment
when talking about #systemapi and #apex symbols. So, we have some flexibility
here when determining the lifetime of a symbol.
### var