diff options
| author | 2021-02-26 23:57:23 +0900 | |
|---|---|---|
| committer | 2021-03-01 09:12:32 +0000 | |
| commit | 55549df051e822d71bfdb793742c1377098baaea (patch) | |
| tree | eece79df44a2844bd6a13fd5210de1f5f8834cef /java/java.go | |
| parent | 30e3e9d21d3898bc1e97917b4a0428fb696d0804 (diff) | |
APEX uses the latest version of the stub
Previously when an APEX whose min_sdk_version is set is linked to an
external library providing multiple versions of stubs, the
maximum version that is less than or equal to the min_sdk_version was
chosen. For example, if the versions of a library stubs are 28, 29, 30,
and 31, then APEX with min_sdk_version: 29 linked to the version 29 of
the stub.
This was to ensure that the APEX doesn't use any new APIs whose
existence can't be guaranteed.
This however imposes a severe restriction that the APEX can never use
new APIs even when the APIs are actually available: i.e. when the
APEX is running on a newer platform.
With the recent work about unguarded availability, using the future APIs
became much safer. When you use an API that is newer than your
min_sdk_version, the API is automatically declared as a weak symbol
(thus no link error at runtime), while the call to API is guaranteed to
be guarded with the `__builtin_available(...)` macro.
So, there really is no reason to use the old version of the stub. We can
always use the latest version of stub safely.
Bug: N/A
Test: m
Change-Id: Iaac0d8761d8929154527dc2e861a51ae31e23d49
Diffstat (limited to 'java/java.go')
0 files changed, 0 insertions, 0 deletions