'merge' command can merge multiple configurations.
It just delegates protobuf's msg.MergeFrom(other_msg).
usage: conv_linker_config merge -o out.pb -i a.pb -i b.pb ...
out.pb will have all keys from multiple inputs.
Bug: 181093750
Test: m
Test: MicrodroidTestCase
Change-Id: Ibf715aa0bcc1e5c82c85a9af8fe7dca8d6ab68ad
Till now, linker_config has to be installable to be packaged. With this
commit, packaging modules like filesystem now can include uninstallable
linker_config. This can help when linker_config can conflict with other
partitions e.g. system.
Bug: 185391776
Test: build filesystem with uninstallable linker_config
Change-Id: Ic2cece08be73749e6bd1f813152c67f8e3904c20
Checks to make sure that every module that is part of the platform
bootclasspath has been initialized property for hidden API processing.
Bug: 177892522
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: Ic4368963f2011784b537b8aebf5ef97ea22b2db5
As part of the work to modularize the hiddenAPI processing the
generation of the monolithic hidden API index file needs to be moved
to the platform_bootclasspath module type. Doing that broke the
TestBootDexJarsFromSourcesAndPrebuilts tests which checks the inputs to
the rule that creates that file. Fixing that required added a
platform_bootclasspath module to the test fixture for those tests which
highlighted an issue with the prebuilt_apex module.
Previously, when the prebuilt_apex created apex variants it would use
its own name as the apex variant name, even when that name included the
prebuilt_ prefix. That broke the platform_bootclasspath logic as it was
looking for apex variants for "myapex" but the only ones available were
"prebuilt_myapex".
This change ensures that it always uses the unprefixed name and fixes
the TestNoUpdatableJarsInBootImage to match. This also adds some
improved error reporting in platform_bootclasspath which helped debug
this problem.
Bug: 177892522
Test: m nothing
Change-Id: I3e88b5cec767f77dcc0e94b3ae38b499d07eadf0
incompatibilities.txt doesn't exist anymore, only
"<module>-incompatibilities.txt". Clean up the associated logic that
mapped incompatibilities.txt to android-incompatibilities.txt.
Bug: 178171189
Test: m
Change-Id: I61eeb5dcc82770fa2af356bad11b7205551d6d83
This adds Rust vendor image support for all module types except
Rust prebuilts.
Bug: 184042776
Test: New Soong tests.
Test: Example cc_library vendor module can depend on rust_ffi_shared.
Test: Example rust_library vendor-only module compiles.
Change-Id: Iaa30ad51fdaedcbf14687da5472581f6af62ff59
Refactor rust to use and implement the new common image mutator
interface to handle future image mutations.
Bug: 184042776
Test: m nothing
Change-Id: If6a85e2b8c6a1969d62264eaea6c6b53cae9c039
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
Jooyung Han