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
Restructures the java package test setup code to create FixturePreparer
instances for setting up a test fixture and converts some tests to
use it.
The goal with this change is not to switch all the java tests over to
directly using the new model but instead to ensure that the majority of
the java tests run with the new model, to allow existing tests to
easily switch to the new model when needed and to allow dependent
packages to be switched to the new model.
Bug: 181070625
Test: m nothing
Change-Id: I1c9d96ddbc973aaf9733dcd7fa0479f79b0f471f
Set baseline_file properties of droidstubs generated in sdk_libary.go to
incompatibilities modules auto-generated by prebuilt_api. This requires
prebuilt_api to generate the modules whether next_api_dir is set or not.
Test: TreeHugger
Bug: 180123247
Change-Id: I690604a8a54e9d9419f072a28a0c0e7734abbd85
They should have had `android:"path"` tags attached so that users can
point them to filegroup modules.
Test: app_test.go & app_import_test.go
Bug: 182175153
Change-Id: I5580408488ffe5fc12c869cbfb7a468713dcbc96
Give metalava an ANDROID_SDK_HOME directory in the out tree so it
doesn't write to ~/.android.
Bug: 181908035
Test: mv ~/.android ~/.android.bak && m car-doc-stubs
Change-Id: I63064ece62ff4aa1eb93cbb6c9e33038c1e8a19d
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
Change-Id: Ieddaf859f568bc8ee486692474a4dec48b3d25e6
Merged-In: I15e5a6c2f07e73718803501d705de0d7ab9bec90
Merged-In: Ib084ee6676d4a201f4b60533221036245d3be759
Merged-In: I629ed1454def5cf8164a6079034e2c610ed0a554
Merged-In: Ia7613f35c4392eac51c94b0d1da29ecac82eb103
Generating the API fingerpring depends on framework-res, so the
fingerprint cannot be embedded into framework-res. Hardcode an
exemption to UseApiFingerprint.
Bug: 181978889
Test: TARGET_BUILD_VARIANT=user UNBUNDLED_BUILD_TARGET_SDK_WITH_API_FINGERPRINT=true vendor/google/build/build_mainline_modules.sh
Change-Id: I621f36d5eb157dd97baa132ff109b4df791eedcc
The version of robolectric in external/robolectric-shadows is based
on 4.1 and is difficult to update. Support using the prebuilt versions
in prebuilts/misc/common/robolectric, with the caveat that they won't
support the in-progress SDK version.
Bug: 181886851
Test: manual
Change-Id: Ie3a861cf6d637f97cf00212c02322f92c1043f0a
Changes this function so it only registers components from the cc
package by pushing the call to genrule.RegisterGenruleBuildComponents()
down into those packages whose tests need it.
This will make it easier to migrate cc package tests to test fixtures
as the RegisterRequiredBuildComponentsForTest() no longer overlaps with
preparers from the genrule packages.
Bug: 181070625
Test: m nothing
Change-Id: Ic00c7e480dc738d7a88d038aca6ab95a1502a24a
Revert reland the change after tests have been fixed
Reason for revert: relanding after fixes
Reverted Changes:
I89fbce4d7:Revert "Exclude some tests for java_test_host onbo...
Iaa89f9b7e:Revert "Attempt to run all java_test_host that loo...
Change-Id: Idaa80b2d5a8d3ba026e33b453bd163a4e2d31118
Revert submission 1597083-java_test_host_default
Reason for revert: Getting ready for b/181888225 just in case
Reverted Changes:
I220551549:Attempt to run all java_test_host that look unit t...
I29dbbbf46:Exclude some tests for java_test_host onboarding
Change-Id: Iaa89f9b7e9ad72ed962cef285c70a6263e63ffd5
Without dexpreopt the check is not necessary, and although it is good to
have, it is difficult to maintain on non-linux build platforms where
dexpreopt is generally disabled (the check may fail due to various
unrelated reasons, such as a failure to get manifest from an APK).
Bug: 181570790
Bug: 132357300
Test: m nothing
Change-Id: Ie012690e8f047ae9256e26565d162c19af4e8921
The lint rules dumped the text output file to stdout on error. If the
lint binary exited without updating the output file it would show old
results.
Remove the output files before running lint, and only dump the text
output file if it exists.
Bug: 181681346
Test: m lint-check
Change-Id: I4fa962b1212e8715f234912a9a5e049d5c1540e8
Use restat for the api_versions.xml and annotations.zip dependencies
of lint so that frameworks/base changes don't always result in
rerunning lint on every module.
Bug: 181681346
Test: m lint-check
Change-Id: Ic6a540b41cf79b21441311a8baefe528a3d90d8b
Lint references lint-classpath.jar, which does not contain any classes
by has a manifest that points to other jars for the classpath. This
breaks dependency tracking during the build. Use a lint tool that
is repackaged into a single jar.
Bug: 181681346
Test: m lint-check
Change-Id: I07d2b7404c18626e03c5af3ef5a75dd7f899cb0e
This lets one avoid any decisions as to when to chdir there during its
execution and leads to better sandboxing because the pwd doesn't leak to
init() functions anymore.
Test: Manual.
Change-Id: I1560da8ed3a621249426f9e8908aa890c21e13ba
Some of the `uses_libs`/`optional_uses_libs` libraries may have a
library name that is different from the module name. In that case it is
necessary to patch these properties after `provides_uses_lib` for the
library is applied.
Bug: 132357300
Test: m nothing
Change-Id: I2e2248053787557f955a6b363c22e3bad0301ec7
Previously `provides_uses_lib` property affected only those
<uses-library> dependencies that are automatically deduced by Soong as
implicit Java SDK libraries reachable from the `libs` property. Other
<uses-library> dependencies that are explicitly added in `uses_libs` and
`optional_uses_libs` properties ignored `provides_uses_lib`.
As TestUsesLibraries shows (see the TODOs), Soong behaviour is still
incorrect in two ways (to be addressed in follow-up CLs):
- `uses_libs`/`optional_uses_libs` are passed to manifest_fixer
- verify_uses_libraries check is based on `uses_libs`/
`optional_uses_libs`, and not on the CLC as it should be
Bug: 132357300
Test: m nothing
Change-Id: I0ec7aab9dcd44554d1a79ddd382491c562266fa3
