We are enabling NewApi lint check where the min sdk != compile sdk.
At the same time, we are introducing baseline files for existing
projects that fail this check in order to keep the build running.
At the very least we stop introducing new problems and teams might
realise of risks in their projects they were not aware of.
Bug: 150847901
Test: m lint-check
Change-Id: Icfa5eb98cc6b6708149f0c52fac8fc1440d9c3b0
Merged-In: Icfa5eb98cc6b6708149f0c52fac8fc1440d9c3b0
As part of adding Vendor support to Rust, refactor the image mutator in
CC to a new common image mutator interface so this logic can be reused
across both CC and Rust.
Bug: 184042776
Test: m nothing
Change-Id: Ia55d5ad840db7cf1a64d6c65ed86487230cb8742
Boot jars, updatable boot jars and art apex jars are part of two
separate but related configuration objects, the main Config struct
(actually the nested productVariables struct) and the dexpreopt
specific GlobalConfig. The fields in both are initialized from the same
data in the make config files but handled separately.
Previously each test that used one of the configuration objects would
generally just initialize the one it used. That would make the test
sensitive to the specific configuration object that was used. A
refactoring that change the code from using one configuration object to
the other would cause the test to fail.
Also, some tests would inadvertently create invalid configurations by
setting ArtApexJars without also setting BootJars. While the ability to
create invalid configurations is useful (and there are some tests that
exist to verify the behavior in that case) most tests should not be
using them.
This change simplifies the configuration of the tests and improves
their realism by:
1. Providing a new FixtureConfigureBootJars method that takes a set of
boot jars and sets ArtApexJars, and BootJars in the
dexpreopt.GlobalConfig and BootJars in the product variables too.
2. Providing a new FixtureConfigureUpdatableBootJars method that takes
a set of boot jars and sets UpdatableBootJars in both the
dexpreopt.GlobalConfig and productVariables.
3. Migrating existing tests to use these new methods.
Some tests still use the dexpreopt.FixtureSet...Jars() methods directly,
generally to create invalid configurations.
Bug: 177892522
Test: m nothing
Change-Id: I4d8f0b9762cfcc7ae6383bef08563d7c3fa13955
Previously attempting to use m UNSAFE_DISABLE_HIDDENAPI_FLAGS would
cause a build failure.
It is necessary when UNSAFE_DISABLE_HIDDENAPI_FLAGS=true to create
empty files for the monolithic files so that those usages which are not
protected by the build flag, e.g. in dists or CTS tests like
CtsHiddenApiBlocklistTestApiTestCases do not cause ninja failures due
to reliance on a file that does not exist and has no rule to create it.
Bug: 177892522
Test: m nothing
m UNSAFE_DISABLE_HIDDENAPI_FLAGS=true CtsHiddenApiBlocklistTestApiTestCases
Change-Id: I05d0b3680dbc0b5b7c7c0d792550faf848829647
Change https://r.android.com/1673266 introduced some code that does
nothing. This change removes that.
Bug: 177892522
Test: m nothing
Change-Id: I349b17c7fe7e2f68a807dab43a4300da7fe0ad4d
A skeleton of a classpath fragment's interface and base to be used by
any modules that provide entries for *CLASSPATH variables at runtime.
In follow up changes, this would be extended to generate
packages/modules/SdkExtensions/proto/classpaths.proto configs for such
modules to be bundled into system and individual apex binaries.
Bug: 180105615
Test: m
Change-Id: I2df550862e97222c5650c4d0480c90231fd78ef0
Properly plumb the available environment to the configuration instead of
going through the global variable originalEnv.
Test: Presubmit.
Change-Id: Ia1ea753d5e72c02a0dcaa4c0b43bd6e24fc47cec
Makes the monolithic hidden API files accessible from the
platform_bootclasspath so they can be output to the dist build target
and used by other modules, e.g. by doing something like this:
java_resources: [
":platform-bootclasspath{hiddenapi-flags.csv}",
],
It makes the paths relative to the out/soong/hiddenapi directory rather
than the out/soong directory to make them easier to use in the
java_resources property without changing the structure of the APK.
Without that attempting to use them in a java_resources property will
result in them being copied to a hiddenapi/ within the APK instead of
being used at the top level as existing APKs like
CtsHiddenApiBlocklistTestApiTestCases expect.
Bug: 177892522
Test: m nothing
Change-Id: I829412fc7d25411e0c2e0713d0d219a18f4af2ee
There is little overlap at this point, but we expect these to converge
more over time, to handle exported includes, libs, etc., this will allow
those changes to be handled in one place and allow more consolidation of
code.
Test: bp2build generate & sync; mixed build libc
Change-Id: I51685dad9f4fc11a634965a3c9e84f4a0e279ecb
This is so that the way soong_build is invoked is simpler, which is in
turn useful so that it can be invoked multiple times within a single
build, which in turn will be used to invoke bp2build routinely (as
opposed to manually when needed)
Test: Presubmits.
Change-Id: Iddaebb05ff7bcedc0db8273192bb31284b739920
This change moves the generation of the global hidden API flags from
the singleton to the platform_bootclasspath module. It involves:
1. Moving the ruleToGenerateHiddenApiFlags to hiddenapi_modular.go.
2. Adding HiddenAPIAugmentationProperties to be used by the
platform_bootclasspath type.
3. Moving the file paths into the platform-bootclasspath module
definition in frameworks/base/boot/Android.bp.
The flagsRule is kept as a placeholder for now. The emptyFlagsRule is
also kept so that builds continue to work even when the frameworks/base
repository is not present.
Bug: 177892522
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: Idf4dd414a016831bfe04a01f93234c1c33819881
Extracts the code for creating the rule that creates the monolithic
hidden API flags file which is encoded into dex implementation jars.
This refactoring is in preparation for moving the functionality from
the hiddenapi_singleton into the platform_bootclasspath.
A follow up change will move the method into the new
hiddenapi_modular.go alongside the hiddenAPIAugmentationInfo as they
will both be used to perform hidden API processing for a
bootclasspath_fragment.
Bug: 177892522
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: I2729afa80cdfd2d1d4717365001648453d65632f
This adds the two modules to the bp2build/mixed builds denylist while we
investigate b/185079815.
Test: TH
Change-Id: I6d67c5c24502ac48bdc90a005ddef86c46eab0b7
cc modules have complex image variant settings. To avoid setting
wrong partitions to modules, add a test to check the install
partition.
Bug: 184885453
Test: m nothing
Change-Id: I080661335f2da7281d6e6a0d2fedd1fcecb4b2cb
In aosp/531337 support for installing prebuilts to vendor and odm
partitions was introduced.
Since aosp/1542687 allowed installing vendor variants to odm, we
started to see device_specific cc_prebuilts not installed to odm
at all.
The reason for this is the InVendor condition is true for the
device_specific module and VendorVariantToOdm is false in cases
outside the one it was designed for, so SocSpecific returns true and
the module gets installed to vendor instead of odm.
We need to check if we're specifically building a vendor variant
before triggering this VendorVariantToOdm logic.
Bug: 184885453
Change-Id: I05be06a61c5fc3f2f72599eb4746c9c0523b956e
HWASan for static Rust executables is not supported yet.
Bug: 180495975
Test: build local test app with HWASan
Change-Id: I46e851c82a16943586ec3a789f09a58651d036e3
