With the addition of apexes and /system_ext some of the bootclasspath
and system server jars have moved from /system to the new locations.
This has been implemented by using lists of colon-separated strings
called "apex-jar pairs" (although "apex" was misleading as it could
refer to "platform" or "system_ext", not necessarily a real apex).
Using the colon-separated string representation is inconvenient, as it
requires splitting and reassembling the list components many times,
which harms performance and makes error handling difficult. Therefore
this patch refactors the colon-separated lists into a struct that
hides the implementation details.
Test: lunch aosp_cf_x86_phone-userdebug && m
Change-Id: Id248ce639a267076294f4d4d73971da2f2f77208
"exec format error" showed up on Mac when running the rbe_test.go.
The generated bash scripts did not have a newline at the end of
the file.
Bug: b/162600461
Fixes: b/162600461
Test: "m blueprint_tools" on Android Mac builder.
Change-Id: I425fa5f428733b6569c3fcdaa312023f9761d020
Disable the error test cases to allow developers to build
AOSP on Mac.
Bug: b/162600461
Test: m nothing
Change-Id: Ic8c6fe04743a8e4fe197a1bb71259036fb749edc
Disable the error test cases to allow developers to build
AOSP on Mac.
Bug: b/162600461
Test: m nothing
Change-Id: Iac4373dcb10710d8a2325eeb3ee20a6eeca6143f
rust_library modules no longer produce "link" variants alongside
"rust_libraries" variants as the former have been moved to rust_ffi
modules. rust_library modules however still create empty link variants
and code paths still assume that modules can support both rust linkage
and cc linkage. This adds unnecessary complexity that no longer serves a
purpose.
This cleans this up by removing the unused "link" variant for
rust_library modules and simplifies code paths that can now assume
modules are either a rust library or a cc library, but not both.
This also fixes a bug where Shared() was returning the wrong value.
Bug: 159064919
Test: cd external/rust/; mma
Test: cd external/crosvm/; mma
Change-Id: I3b5498c80b315c56b621dcb1388022fecc1bfc1b
This will allow us to remove `create_stubs: false` throughout the
codebase easily, then remove the functionslity to create stubs from
droiddoc.
Test: m docs
Test: m checkapi
Test: m updateapi
Bug: 144248501
Bug: 143136634
Change-Id: Ib95f68bc064fbe1475e4b25433bee6292bc005dc
Previously, the prebuilt mutators were added by the
cc.RegisterRequiredBuildComponentsForTest() function as a convenience
but unfortunately it lead to some of the mutators being in a different
order in the tests than in the normal build.
This change:
* Extracts the RegisterPrebuiltMutators() call from
cc.RegisterRequiredBuildComponentsForTest()
* Makes sure that the prebuilt mutators are registered before the
visibility gatherer and enforcer mutators.
Bug: 162505935
Test: m nothing
Change-Id: I7d959b558200b502f0a5e4653c41ea01414e142a
When a module is disabled by calling Disable(), it could be
unexpectedly enabled by the archMutator. For example, a module has
```
enabled : false,
arch : {
arm64 : {
enabled : true,
},
}
```
When this modules is disabled by calling Disable() before the
archMutator, it became enabled again ignoring Disable() command.
By defining the `ForcedDisabled` property, we can disable a module
regardless of `Enabled` property.
Bug: 161565086
Test: m
Change-Id: I443720715edbac25cb6d7c3d9eb1bc9806719161
llndk_library and llndk_headers are backward compatible. We may use
the source code instead of snapshot for those modules.
Bug: 161565086
Test: build with vendor snapshot
Change-Id: If3da3f9b31f7180d8d0835f8dbd7ba938a60d967
Multiple GKI APEXes may write to the same path
under $OUT/apex. Prevent it.
Fixes: 162366062
Test: build GKI APEX
Change-Id: I1b19870b10d6da2a85c3f7b9d93408d3a0fe90bc
When a vendor APEX sets use_vndk_as_stable: true, then the apex doesn't
bundle VNDK libraries but instead it uses them from the "vndk" namespace
at runtime.
":vndk" is a pseudo-name for VNDK libraries, which is processed by
linkerconfig so that the generated linker configuration allows the
namespace for the apex to access VNDK libs.
Bug: 159576928
Test: test with a test-only vendor apex
it runs okay with VNDK libs. (lsof shows that it opens libs from
VNDK APEX)
Change-Id: I924ce0fea696162575f59589b8f858deddf436b3
Update android_app_set to use word install rather than master for
android_app_sets, this better matches the phrasing used for apex_set.
See https://source.android.com/setup/contribute/respectful-code for
reference
Bug: 161896447
Test: m nothing
Change-Id: I429e7f8b16c42c10ad4d9543110f5ce814a893b1
