The APIs that are tagged with # vndk are actually for LLNDK libraries.
Although LLNDK is part of VNDK, calling those APIs 'vndk' has given
users a wrong perception that the APIs don't need to be kept stable
because that's the norm for most of the VNDK libraries that are not
LLNDK.
In order to eliminate the misunderstanding, rename the tag to 'llndk' so
that people introducing new such API will realize what they are signing
themselves up for.
Exempt-From-Owner-Approval: cherry-pick from internal gerrit
Bug: 143765505
Test: m
Test: python3 test_gen_stub_libs.py
Merged-In: I2853df3b6e245056c21d4ab3d62466954cf26d72
(cherry picked from commit 3d7b69a657)
Change-Id: I2853df3b6e245056c21d4ab3d62466954cf26d72
This change fixes a bug that a symbol is omitted for apex (or vndk) when
it is annotated with "# vndk apex" (or "# apex vndk).
Bug: 123349183
Test: python3 test_gen_stub_libs.py
Change-Id: I344d6e70732bae8877cb16bbe881edb79fe90670
If a symbol is tagged as # apex, then it is exported when gen_stub_libs
is invoked with --apex.
Bug: 120638081
Test: python3 cc/test_gen_stub_libs.py
Change-Id: I190bca35d1a4fb422b37d1be41a34de1ad64de6b
Generating released API levels and android-current is not sufficient
in a trunk-stable world. One branch will have the stable APIs and
possibly multiple unreleased API levels. We need to generate stubs
for each unreleased API level up to our current target.
I still need to add support for things like `# introduced=O` before
this is really done.
Whether or not we still need something like "current" that would map
to the absolute latest even it hasn't been assigned a code name yet
is uncertain.
Test: make ndk
Bug: None
Change-Id: I282be1347ab39c56fa887d4d71c03bb12c300dc5
This hides a particular symbol from the NDK stubs, while allowing the
symbol to be exposed to the VNDK through the LLNDK stubs. This doesn't
introduce any sort of versioning yet, this will need to change when we
add a new symbol to a new version of the VNDK.
Test: test_gen_stub_libs.py
Test: With my LL-NDK patches, inspecting the generated map files
Change-Id: Iee86aafda7985d6d7a016d0d5ff951505634913b
Support for using this coming in an upcoming patch.
Test: nose2
readelf to check the following:
* bsd_signal unversioned before current
* bsd_signal versioned in current
* catclose missing before current
* catclose present and versioned in current
Bug: None
Change-Id: I861862161426d3ec5b530e3156d3a8ae96fed468
We tried to support this by version name convention (foo_PLATFORM and
foo_PRIVATE), but not everything follows those conventions. libm has
a LIBC_DEPRECATED, which is a bit to generic to apply this convention
to.
Support a "platform-only" tag which omits the tagged version in the
NDK.
Test: nose2
Bug: None
Change-Id: Iba34628ea02a813d22c8b32d10e54064f17ac6df
Bionic's version scripts are unfortunately complicated enough that the
naive processing I was doing before is not going to be sufficient.
Add a real parser/generator with a bunch of tests to fix this.
Test: cc/test_gen_stub_libs.py && make ndk
Change-Id: I0f73b41ade1e6cf4e31bf70ba43a743429ce770b
This adds the `versioned=API` tag. This should be a very uncommonly
needed tag, and is really only needed to fix versioning mistakes that
are already out in the wild.
For example, some of libc's __aeabi_* functions were originally placed
in the private version, but that was incorrect. They are now in
LIBC_N, but when building against any version prior to N we need the
symbol to be unversioned (otherwise it won't resolve on M where it is
private).
Test: make ndk
Change-Id: I0cd2f80cf4b32356356914cf7ff4119e67f15032
A version block might need to be omitted for reasons beyond just
"future". Support all the same tags we do at symbol scope.
Test: `make ndk` with libc/libm migration patches.
Change-Id: I21f54c67079dae10fee1e5e08bcd01f8810e7a67
Symbols that have been added to a library but should not be exposed
in any of the current NDK API levels should be tagged with "future".
These will be suppressed from the NDK libraries.
Once all this is in better shape we'll have `sdk: "current"`. Symbols
tagged with "future" will be available for that.
Note that this tag can be applied directly to a version. Aside from
being more ergonomic than tagging an entire section, this also solved
the problem of gen_stub_libs.py emitting an empty global section
(which is not valid syntax) in the case where every symbol is
"future". Tag the version instead and it will be omitted.
Test: `make ndk` with libc/libm migration patches.
Change-Id: I41f6e4939c406f695ab5725f360ec6554ad8ab31
The list of migrated libraries is currently empty. Libraries will be
migrated as follow up patches.
Test: Migrated libc to this system and everything still builds.
build.ninja shows libraries being built and used and headers are
collected for the sysroot.
Bug: http://b/27533932
Change-Id: Iaba00543c1390f432befe0eed768ed3fbb8a9b96
