summaryrefslogtreecommitdiff
path: root/java/java.go
diff options
context:
space:
mode:
author Jiyong Park <jiyong@google.com> 2021-02-26 23:57:23 +0900
committer Nicolas Geoffray <ngeoffray@google.com> 2021-03-01 09:12:32 +0000
commit55549df051e822d71bfdb793742c1377098baaea (patch)
treeeece79df44a2844bd6a13fd5210de1f5f8834cef /java/java.go
parent30e3e9d21d3898bc1e97917b4a0428fb696d0804 (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