Add systemapi as an APEX synonym for stub maps.
The apex tag is currently used for platform-to-APEX, APEX-to-APEX, and APEX-to-platform, and it's difficult to tell when reviewing the map files. Add a synonym so authors can be explicit about platform-to-APEX since those have different stability rules. Test: pytest Test: mypy Test: pylint Test: treehugger Bug: None Change-Id: I0aee679a05b1b2d3749307434c19486bf4c7fe52
This commit is contained in:
parent
ead21552ee
commit
56f52de8bd
4 changed files with 49 additions and 5 deletions
|
@ -108,7 +108,14 @@ def parse_args() -> argparse.Namespace:
|
|||
parser.add_argument(
|
||||
'--llndk', action='store_true', help='Use the LLNDK variant.')
|
||||
parser.add_argument(
|
||||
'--apex', action='store_true', help='Use the APEX variant.')
|
||||
'--apex',
|
||||
action='store_true',
|
||||
help='Use the APEX variant. Note: equivalent to --system-api.')
|
||||
parser.add_argument(
|
||||
'--system-api',
|
||||
action='store_true',
|
||||
dest='apex',
|
||||
help='Use the SystemAPI variant. Note: equivalent to --apex.')
|
||||
|
||||
parser.add_argument('--api-map',
|
||||
type=resolved_path,
|
||||
|
|
|
@ -83,7 +83,7 @@ class Tags:
|
|||
@property
|
||||
def has_apex_tags(self) -> bool:
|
||||
"""Returns True if any APEX tags are set."""
|
||||
return 'apex' in self.tags
|
||||
return 'apex' in self.tags or 'systemapi' in self.tags
|
||||
|
||||
@property
|
||||
def has_llndk_tags(self) -> bool:
|
||||
|
|
|
@ -253,6 +253,21 @@ class OmitVersionTest(unittest.TestCase):
|
|||
symbolfile.Version('foo', None, Tags.from_strs(['apex']), []),
|
||||
Arch('arm'), 9, False, True))
|
||||
|
||||
def test_omit_systemapi(self) -> None:
|
||||
self.assertTrue(
|
||||
symbolfile.should_omit_version(
|
||||
symbolfile.Version('foo', None, Tags.from_strs(['systemapi']),
|
||||
[]), Arch('arm'), 9, False, False))
|
||||
|
||||
self.assertFalse(
|
||||
symbolfile.should_omit_version(
|
||||
symbolfile.Version('foo', None, Tags(), []), Arch('arm'), 9,
|
||||
False, True))
|
||||
self.assertFalse(
|
||||
symbolfile.should_omit_version(
|
||||
symbolfile.Version('foo', None, Tags.from_strs(['systemapi']),
|
||||
[]), Arch('arm'), 9, False, True))
|
||||
|
||||
def test_omit_arch(self) -> None:
|
||||
self.assertFalse(
|
||||
symbolfile.should_omit_version(
|
||||
|
@ -315,6 +330,20 @@ class OmitSymbolTest(unittest.TestCase):
|
|||
symbolfile.Symbol('foo', Tags.from_strs(['apex'])),
|
||||
Arch('arm'), 9, False, True))
|
||||
|
||||
def test_omit_systemapi(self) -> None:
|
||||
self.assertTrue(
|
||||
symbolfile.should_omit_symbol(
|
||||
symbolfile.Symbol('foo', Tags.from_strs(['systemapi'])),
|
||||
Arch('arm'), 9, False, False))
|
||||
|
||||
self.assertFalse(
|
||||
symbolfile.should_omit_symbol(symbolfile.Symbol('foo', Tags()),
|
||||
Arch('arm'), 9, False, True))
|
||||
self.assertFalse(
|
||||
symbolfile.should_omit_symbol(
|
||||
symbolfile.Symbol('foo', Tags.from_strs(['systemapi'])),
|
||||
Arch('arm'), 9, False, True))
|
||||
|
||||
def test_omit_arch(self) -> None:
|
||||
self.assertFalse(
|
||||
symbolfile.should_omit_symbol(symbolfile.Symbol('foo', Tags()),
|
||||
|
|
|
@ -70,9 +70,11 @@ the same line. The supported tags are:
|
|||
|
||||
### apex
|
||||
|
||||
Indicates that the version or symbol is to be exposed in the APEX stubs rather
|
||||
than the NDK. May be used in combination with `llndk` if the symbol is exposed
|
||||
to both APEX and the LL-NDK.
|
||||
Indicates that the version or symbol is to be exposed by an APEX rather than the
|
||||
NDK. For APIs exposed by the platform *for* APEX, use `systemapi`.
|
||||
|
||||
May be used in combination with `llndk` if the symbol is exposed to both APEX
|
||||
and the LL-NDK.
|
||||
|
||||
### future
|
||||
|
||||
|
@ -144,6 +146,12 @@ for use by the NDK, LL-NDK, or APEX (similar to Java's `@SystemAPI`). It is
|
|||
preferable to keep such APIs in an entirely separate library to protect them
|
||||
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.
|
||||
|
||||
### var
|
||||
|
||||
Used to define a public global variable. By default all symbols are exposed as
|
||||
|
|
Loading…
Reference in a new issue