APEX variants that share the same SDK version and updatability
almost always use identical command line arguments to build but
with different intermediates directories. This causes unnecessary
build time and disk space for duplicated work.
Deduplicate APEX variants that would build identically. Create
aliases from the per-APEX variations to the new shared variations
so that the APEX modules can continue to depend on them via the
APEX name as the variation.
This has one significant change in behavior. Before this change,
if an APEX had two libraries in its direct dependencies and one
of those libraries depended on the other, and the second library
had stubs, then the first library would depend on the implementation
of the second library and not the stubs. After this change, if
the first library is also present in a second APEX but the second
library is not, then the common variant shared between the two
APEXes would use the stubs, not the implementation.
In a correctly configured set of build rules this change will
be irrelevant, because if the compilation worked for the second
APEX using stubs then it will work for the common variant using
stubs. However, if an incorrect change to the build rules is
made this could lead to confusing errors, as a previously-working
common variant could suddenly stop building when a module is added
to a new APEX without its dependencies that require implementation
APIs to compile.
This change reduces the number of modules in an AOSP arm64-userdebug
build by 3% (52242 to 50586), reduces the number of variants of the
libcutils module from 74 to 53, and reduces the number of variants
of the massive libart[d] modules from 44 to 32.
This relands I0529837476a253c32b3dfb98dcccf107427c742c with a fix
to always mark permissions XML files of java_sdk_library modules as
unique per apex since they contain the APEX filename, and a fix
to UpdateUniqueApexVariationsForDeps to check ApexInfo.InApexes
instead of DepIsInSameApex to check if two modules are in the same
apex to account for a module that depends on another in a way that
doesn't normally include the dependency in the APEX (e.g. a libs
property), but the dependency is directly included in the APEX.
Bug: 164216768
Test: go test ./build/soong/apex/...
Change-Id: I2ae170601f764e5b88d0be2e0e6adc84e3a4d9cc
APEX variants that share the same SDK version and updatability
almost always use identical command line arguments to build but
with different intermediates directories. This causes unnecessary
build time and disk space for duplicated work.
Deduplicate APEX variants that would build identically. Create
aliases from the per-APEX variations to the new shared variations
so that the APEX modules can continue to depend on them via the
APEX name as the variation.
This has one significant change in behavior. Before this change,
if an APEX had two libraries in its direct dependencies and one
of those libraries depended on the other, and the second library
had stubs, then the first library would depend on the implementation
of the second library and not the stubs. After this change, if
the first library is also present in a second APEX but the second
library is not, then the common variant shared between the two
APEXes would use the stubs, not the implementation.
In a correctly configured set of build rules this change will
be irrelevant, because if the compilation worked for the second
APEX using stubs then it will work for the common variant using
stubs. However, if an incorrect change to the build rules is
made this could lead to confusing errors, as a previously-working
common variant could suddenly stop building when a module is added
to a new APEX without its dependencies that require implementation
APIs to compile.
This change reduces the number of modules in an AOSP arm64-userdebug
build by 3% (52242 to 50586), reduces the number of variants of the
libcutils module from 74 to 53, and reduces the number of variants
of the massive libart[d] modules from 44 to 32.
Bug: 164216768
Test: go test ./build/soong/apex/...
Change-Id: I0529837476a253c32b3dfb98dcccf107427c742c
In preparation for reusing the same variation for multiple apexes,
rename ApexName to ApexVariationName.
Bug: 164216768
Test: all soong tests
Change-Id: I88f2c5b192ffa27acd38e01952d0cefd413222a0
Remove ipmemorystore-aidl-interfaces-java in allowlist for
com.android.tethering
Bug: 146436251
Test: m nothing
Change-Id: I8b7f97d59c2fd191f467ad50a8fd66d9a5d37704
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
Vendor APEXes(in general, APEXes for non-system partitions) which is
supposed to be tied to a specific VNDK version can set this new property
so that it excludes VNDK libs and use them from VNDK APEX (provided by
system parition).
For these APEXes to use VNDK libs from VNDK APEX, linkerconfig should
link "vndk" linker namespace to the namespaces of these APEXes.
Bug: 159195575
Test: m (soong test added)
Change-Id: If90650973239ef7aab0ff084488bda57d9b0364e
This change fixes this error:
```
TARGET module com.android.adbd.flattened requires non-existent TARGET
module: prebuilt_libclang_rt.ubsan_standalone-arm-android
```
apexFile.moduleName is used as Make dependency name, so it should use
m.BaseModuleName() instead of m.Name(), because soong may prepend
"prebuilt_" to or mutate the output of m.Name() in other ways.
android/androidmk.go emits Android.mk modules with
`LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace
apexFile.moduleName with BaseModuleName() + <SubName> as much as
possible.
Bug: 7456955
Test: Add unit test in apex/apex_test.go
Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing
Test: Verify out/soong/Android-blueline_hwasan.mk
Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
Previously, an APEX variant was created for a module that was a member
of an SDK just in case it had to be replaced with an APEX requested
snapshotted version of that member. That was necessary because that was
the only way to have APEX specific replacements.
Since then a new method called ReplaceDependenciesIf() has been added
which provides fine grained control over which dependencies are
replaced. This change uses that new method to handle the replacements
which allows the APEX variants to be removed.
Bug: 161928524
Test: m nothing
Change-Id: If3869dd6753dc182b099af566b20fbc9c9c6eff7
apexDepsMutator marks all dependencies of apex modules. Previously, it
was converted from WalkDeps() to Top-down mutator to avoid the pitfall
of WalkDeps() bug. (It did't handle multiple visits via different
paths.)
Because WalkDeps() problem solved in aosp/1277516, apexDepsMutator can
be reverted to use WalkDeps().
Even though there's no observable difference between them, I revert this
for the up-coming change, which requires different pruning strategies
per apexes.
Bug: 159195575
Test: m
Change-Id: Ib09cbc7a3dfd143dd37b660b1aea6c71392ce2e3
prebuilt_apex has been disabled when the device is configured for
flattened APEXes, sanitized, instrumented, or built unbundled. However,
apex_set which is another type of APEX prebuilt wasn't disabled for the
same conditions.
This change fixes the discripency. apex_set modules are also force
disabled when the prebuilts are not expected.
Bug: 161316762
Bug: 160933444
Test: OVERRIDE_TARGET_FLATTEN_APEX=true m
The built image has only the flattened APEXes and the device boots
Change-Id: I6c90dfb28d565861a473a1bdce93269ec370601d
If prebuilts are active they will have the other direct dependencies
from the source modules.
Bug: 151303681
Test: m nothing
Test: `m` with prebuilts/runtime in the manifest (along with other
fixes)
Change-Id: I1ffc7e7b528ed9db5ce6ca2ee96c9d23c6548c49
