Add a jni_uses_platform_api property that will be used to allow
an app that builds against the SDK to use JNI libraries that build
against platform APIs. For now it is a noop, but the next CL will
make it enforcing.
Bug: 149591057
Test: m checkbuild
Change-Id: Id7b7c8186bf0e28498a4cfb15c6a6ccc95df3679
Move the NDK modules defined in app_test.go into cc/testing.go in
preparation for using sdk_version: "current" in more tests.
Test: all soong tests
Change-Id: I80bc31225fb4562fce42781219cefbbd6affae06
This change automates one of the best practices for
custom tools. The best practice says "Prefer to list
input files on the command line, otherwise we may not
know to re-run your command when a new input file is
added." [1]
Normally you'd reference these inputs with $(in) or
one of the forms of the $(location*) substituions on
the command line for the custom tool. However, if the
custom tool does not accept the list of inputs on the
command line, the build system could fail to re-run
the custom tool if the list changes.
This change adds a hash of the list of input names to
the sbox command that wraps the custom tool. If the
list of inputs change, the hash will change, and
therefore the sbox command will change, causing ninja
to re-run the custom tool. The hash is visible to
(but ignored by) the sbox command, and hidden from
your custom tool.
[1] https://android.googlesource.com/platform/build/soong/+/refs/heads/master/docs/best_practices.md#custom-build-tools
Test: TestGenruleHashInputs
Bug: 149397658
Change-Id: I18b547ea3c4296ee15bd6150a4778a8f376d80b7
Previously, there were some places where a java_system_module_import
could not be used in place of a java_system_module. That was because
the code assumed a *SystemModules type not a *systemModulesImport type.
This change introduces a SystemModulesProvider interface that is used
instead and is implemented on both types.
Bug: 142940300
Test: m nothing
ran new tests before changes to make sure they detected the issue
and after to make sure the changes fixed the issue.
Change-Id: I7b16ac5708880bdf61e6f5b1e6616c986f0ed763
The optimization is confusing syshealth because the modules will use
more memory when they are switched to the prebuilt (unbundled) or
updated via Play.
Let's have a per-module switch to control the behavior and turn it on
only for non-updatable modules like ART.
Bug: 149805758
Test: m
Change-Id: Ieb842c47f31f3b06e403b1e1f9e463c3e5524107
This adds public header to deps correctly.
Bug: 148123511
Bug: 149252327
Test: VNDK_SNAPSHOT_BUILD_ARTIFACTS=true m dist vndk
Change-Id: Ib8df3dfb4a068a11fc647de8588cc52889d82fba
This reverts commit 77def87329.
Reason for revert: <cop revert, broken build 6217456 on git_master on cf_x86_phone-userdebug_coverage>
Change-Id: Iaf64cfe8fdfe62d397719f7ca5cc7679e5858d91
.vendor suffix is meant to be attached for vendor variants of
modules without "vendor: true". So when we decide whether the suffix is
needed for a snapshot module, we should check if corresponding source
module is "vendor: true" or not, instead of checking vendor_available of
the source module.
Bug: 149252327
Test: manual
Change-Id: Ibde75737ddce8e1dc974453e88832f9272a2c66e
This change fixes a regression that was introduced with
I597bccbb177b6b6320c3a3edeff467243230d384. With the change, the content
of the permissions XML file for a java_sdk_library was determined before
the java_sdk_library is mutated for an APEX. As a result, the file path
to the implementation jar library was always set to
/system/framework/*.jar regardless of whether the java_sdk_library is
part of an APEX or not.
This change fixes the problem, by creating the permissions XML file via
a new module type. The content of the xml file is determined after the
xml file is mutated for APEXes.
Bug: 149600642
Test: m
Change-Id: Id21f8d8285df49b0b3be1daf0f101f2bc978eeb0
