To be used in NNAPI apex as part of TF Lite.
This commit is required to resolve merge conflict from aosp/1610793
Bug: 178609672
Test: m
Change-Id: Iaf623823e85e7488e30b3dcf2592d1a90bf9fc9f
Use the name of the apex instead of a global map to find the right
VNDK apex for each VNDK version.
Bug: 181689854
Test: apex tests
Change-Id: If9f8fb10d09e125c9e7d44228e1aa746bf53c082
Originally, when the prebuilt_apex was first created, it selected the
source to use in its DepsMutator. It did that because that was a
convenient place for it to perform that work which had to be:
* After the arch mutator had run so MultiTargets() was available.
* Before the prebuilt_select mutator runs as that relied on the Source
property to have been set.
Change 064b70c9 then duplicated the call from the DepsMutator of the
deapexer module type that was added as part of the work to make dex
files available for hiddenapi processing.
Change 356f7d45 moved it out of the the DepsMutator methods into its
their own mutators, presumably because it interfered with the
Soong -> Bazel conversion work.
This change improves the existing PrebuiltSrcsSupplier mechanism to
support reporting errors so that the logic for selecting the source can
be done on demand rather than in separate mutators.
The main complication was that PrebuiltSrcsSupplier is called with a
BaseModuleContext for both source and prebuilt modules so it cannot use
any methods on it that are related to the current module. That
necessitated adding MultiTargets() to android.Module.
Bug: 181267622
Test: m droid
Change-Id: I106c78fd21016f051a315b82b470d8f12b1f820b
This will ensure that the following refactoring does not change the
behavior.
Bug: 181267622
Test: m nothing
Change-Id: Ieb9b37c2a1ef609b2d6565c54c261439a1ce7147
This will ensure that the following refactoring does not change the
behavior.
Bug: 181267622
Test: m nothing
Change-Id: I36ae9ec9a0a7977bd394f4100c72941052d763ac
Invokes hiddenAPIExtractInformation() on the java_sdk_library_import's
dex implementation jar provided by the deapexer (on behalf of
prebuilt_apex) so that hiddenAPI can extract the information it needs,
if anything, from the dex file.
The dex file provided by deapexer has already had the hiddenapi
information encoded into it so it does not need to do that again.
Usually, it would require a classes implementation jar as well in
order to extract information from UnsupportedAppUsage annotations but
that is not available for a java_sdk_library_import. Fortunately, the
modules that are currently affected by this do not contain any such
annotations. This just uses a public api stubs jar instead.
Bug: 181267622
Test: m nothing
Change-Id: I96275e46f8b7fecba88075319e9f2da5ae315c03
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
We are in the process of snapping the Tethering module in
mainline-prod to AOSP HEAD so we can re-enable the automerger.
This CL adds the necessary dependencies. These are mostly
already present in the allowed_deps file in AOSP master.
Generated by build/soong/scripts/update-apex-allowed-deps.sh .
The merged-in tag is from aosp/1549716, which added one of these
dependencies. This change should not automerge to any branch
because sc-dev and downstream branches already have all these
dependencies.
Test: m
Bug: 167645754
Change-Id: I0216372f973f3d8fa75f7edb2990b9e9db48e3f7
Merged-In: Ief5ffbb96c216796e4f0f4cacbde7c08f4af274a
A new header lib was added to libmath as libui depends
on a libmath header.
Bug: 158790260
Test: libui unit tests
Test: libmath unit tests
Change-Id: Ibdd43a040ebbda314575b6047a8eade415ccd106
These are not currently tracked before because the shims are just
filegroups. aosp/1598155 is turning them into libraries so each
shim can build with the appropriate SDK version.
Test: m
Bug: 180894665
Change-Id: I9df3dd98d46f49943211cb0893493d628ddd157c
These are not currently tracked before because the shims are just
filegroups. aosp/1598155 is turning them into libraries so each
shim can build with the appropriate SDK version.
Test: m
Bug: 180894665
Change-Id: I9df3dd98d46f49943211cb0893493d628ddd157c
Merged-In: I9df3dd98d46f49943211cb0893493d628ddd157c
These are not currently tracked before because the shims are just
filegroups. aosp/1598155 is turning them into libraries so each
shim can build with the appropriate SDK version.
Test: m
Change-Id: I9df3dd98d46f49943211cb0893493d628ddd157c
Merged-In: I9df3dd98d46f49943211cb0893493d628ddd157c
