It appears as though change I3a39be5f0b8736de4822c6a14072c78d4e4ad89d
accidentally stopped enforcing the use of the stable core platform
API in AOSP when the changes from rvc-dev-plus-aosp-without-vendor were
merged in.
Unfortunately, since then some additional usages of legacy core
platform APIs have crept in so this adds the affected modules to the
list of modules allowed to use the legacy core platform APIs.
Bug: 180399951
Change-Id: Ibf7b6e895cc1c66b0fec12ca9ee2f6cb6849a93c
Test: m checkbuild
Merged-In: Ieddaf859f568bc8ee486692474a4dec48b3d25e6
The build target uses non-stable APIs such as
dalvik.system.CloseGuard.
Merged-In: Ieddaf859f568bc8ee486692474a4dec48b3d25e6
Change-Id: I7643e6c7febd44509ac819134de91bca88e2d257
It appears as though change I3a39be5f0b8736de4822c6a14072c78d4e4ad89d
accidentally stopped enforcing the use of the stable core platform
API in AOSP when the changes from rvc-dev-plus-aosp-without-vendor were
merged in.
Unfortunately, since then some additional usages of legacy core
platform APIs have crept in so this adds the affected modules to the
list of modules allowed to use the legacy core platform APIs.
Bug: 180399951
Test: m checkbuild
Merged-In: Ieddaf859f568bc8ee486692474a4dec48b3d25e6
Change-Id: Iacbee67fa103279a9823bd26c559821b04849be6
(cherry picked from commit 6fb6cffce2)
Modules that are not available for platform are developed with
updatability in mind, and do not require manual approvals.
Bug: 181223240
Test: checkbuild
Change-Id: I10b91053b3ef5a9ff5400d9d7a68fae3144a671c
Make sure that java_system_modules_import always depends on the
prebuilt by adding dependencies in the ComponentDepsMutator() method
which is called before prebuilts without a corresponding source are
renamed from prebuilt_<x> to <x>. That requires the prebuilt_ prefix
to be provided but it ensures that the dependencies are safe.
Similar logic also makes sure java_system_modules always depends on
the source module and not on a renamed prebuilt module.
Bug: 182402568
Test: m nothing
Change-Id: I30db95978f5d9b205951011edf40585ee36c0c4c
The previous approach of looking for substrings in the command that
matched the base name of the jar could not differentiate between
whether the jar was a prebuilt or a source as they both have the same
base name.
The tests also did not cover the case when there was both prebuilts
and source modules.
This change:
1. Checks that the inputs to the command come from the appropriate
module.
2. Adds a mixed test.
3. Deduped the source and prebuilt module definitions.
The new test reveals the buggy behavior which will be fixed in a follow
up change.
Bug: 182402568
Test: m nothing
Change-Id: I384ecca097cbe3560e7589c23fb99c176a42fd9b
Previously it was creating a java_system_modules which worked fine
because apart from the prebuilt nature the two are functionally
identical. However a follow up change will differentiate between them
which would break this code.
Bug: 182402568
Test: m nothing
Change-Id: Ifc13ce31235494e338d730c61a99d8887c5a2c5b
Without LANG, lint's text output is ASCII instead of UTF-8, causing
differences between local and remote execution.
Bug: 181681346
Bug: 182415460
Test: m USE_RBE=true RBE_LINT=true
Change-Id: I0ad54aa731582c9b54abb80f50ba508c75992b91
Match other tools by defaulting to local exec strategy.
Also use the local absolute path when using the local exec strategy.
Bug: 181681346
Test: m USE_RBE=true RBE_LINT=true
Test: m USE_RBE=true RBE_LINT=true RBE_LINT_EXEC_STRATEGY=remote
Change-Id: I1d6d20ec69663b99d6d9af1d8e5e67b48a5cd050
