An android app is automatically creating a corresponding "product
characteristics" RRO. The app's resources are filtered by the aapt
product config, but the rro resources are not. This cl makes the RRO
resources also filtered.
When building the CN version, it was expected that only the resources
corresponding to the CN version would be retained, but the actual result
was that other unexpected areas appeared on the region setting interface
in boot interface. After investigation, it was found that the
framework-res__nosdcard__auto_generated_characteristics_rro.apk apk
integrated resources other than the CN version that caused this problem,
and the integration of this apk was not filtered by aaptconfig.
The purpose of this modification is to add aaptconfig filtering, and it
has been verified that this problem can be fixed.
Change-Id: I85d5d07397bd2b0759d35b9f3a07f015346af4e9
Signed-off-by: wybxyx <wybxyx@gmail.com>
Certain applications, like tracking the dependency chain of modules,
knowing the "required" dependencies is required.
In this context, "required" here means the `required` field in
Android.bp files.
Bug: 339193439
Test: Inspect module-info.json for the `required` field
Change-Id: I420c781d410e715ef86823278f99e4ffe51f8022
The use case for this are go apexes which are only installed in T and
above, even though the base AOSP apexes might be installable on < T
devices.
If provided, the overridden min_sdk_version will be
1. Used as the `min_sdk_version` in the manifest file of the
top-level override apex binary
2. Used to build the transitive closure of its dependency with that
min_sdk_version, i.e. with a different apex variant.
(2) requires some special handling. At ToT, the outgoing transition
value is the base apex name (e.g. com.android.foo). Since
min_sdk_version of the overridding apex can be different than the
overridden apex, the base apex name is no longer sufficient. Instead,
transition to the name of the overriding apex com.mycompany.android.foo.
If deduping is possible, transitive deps will get deduped to
`apex_<min_sdk_version>` later.
Test: added a unit test
Test: in internal, modified min_sdk_version of com.google.android.go.art
locally, built BA and Go apexes, and used `aapt2 dump badging` to verify
that BA has minSdkVersion of 31 and Go has minSdkVersion of 33
Bug: 295311875
Change-Id: Ifbe123d1517fccbc0c058042b8a6eeb3609b6787
ToT switched on "relaxed-template-template-args" by default. This does
not work with our outdated libc++. Turn it off until we have the new
libc++.
Test: build with Kokoro ToT Clang (build 2417)
Bug: 341084395
Bug: 332594828
Change-Id: I994c476c1f7b4abd81e5ae0bde4e1f9afd1aa920
deps: ["foo"] + select(product_variable("debuggable") {
true: ["bar"],
default: [],
}),
returns ["foo", "bar"] on debuggable builds, and ["foo"] on user builds.
Bug: N/A
Test: go test ./...
Change-Id: I31ca22e69e3316e4007a36ae13c04c7e5c445907
* changes:
Revert "Install jni symlinks in Soong"
Revert "APK-in-APEX should set use_embedded_native_libs: true"
Revert "Add make java.dependencyTag installable or not"
Revert "Refactor how jni_libs dependencies are added"
This replaces the global override of min_sdk_version (via
`APEX_GLOBAL_MIN_SDK_VERSION_OVERRIDE`) with an min_sdk_version override
that can be set by each individual soong override_app.
The use case for this are go apps which are only installed in T and
above, even though the base AOSP apexes might be installable on < T
devices.
Test: added a unit test
Bug: 295311875
Change-Id: Ie2e738a6786bb24417c675617f7c78358017c96c
Revert submission 3088867
Reason for revert: On cf_auto build, we are seeing a symlink of jni lib pointing to lib64/libcarservicejni.so, which does not exist on the device.
Reverted changes: /q/submissionid:3088867
Bug: b/341335305
Change-Id: Ie4ff26fe47e1a0ab5e97b185c61cb94473cc5fb8
Revert submission 3088867
Reason for revert: On cf_auto build, we are seeing a symlink of jni lib pointing to lib64/libcarservicejni.so, which does not exist on the device.
Reverted changes: /q/submissionid:3088867
Bug: b/341335305
Change-Id: I3064caef0cb55d1594951835a1173c667f58e607
Revert submission 3088867
Reason for revert: On cf_auto build, we are seeing a symlink of jni lib pointing to lib64/libcarservicejni.so, which does not exist on the device.
Reverted changes: /q/submissionid:3088867
Bug: b/341335305
Change-Id: I60052dbb004df58fdfaf93be6089769ab2a670fc
Revert submission 3088867
Reason for revert: On cf_auto build, we are seeing a symlink of jni lib pointing to lib64/libcarservicejni.so, which does not exist on the device.
Reverted changes: /q/submissionid:3088867
Bug: b/341335305
Change-Id: Ibda68b268e74ffca1840faae01a2f3fe2e00be30
This reverts commit 4412723f63.
Reason for revert: Droidmonitor triggered revert due to build breakage in b/341339765.
Change-Id: Id2880f6c0e38504f1adace5e4dab3fd7f6b9b792
This adds an option to disable LTO when building a Rust module. This is
mostly intended to speedu p local prototyping, and LTO should not
normally be disabled for production builds.
Bug: 339628497
Test: m blueprint_tests && m rust
Change-Id: I21d5d4513a259a56f101ce8906e2bef7404e4efb
* changes:
Refactor how jni_libs dependencies are added
Add make java.dependencyTag installable or not
APK-in-APEX should set use_embedded_native_libs: true
Install jni symlinks in Soong
Also use a different name for the output.
Bug: 341117082
Bug: 328495189
Bug: 339707888
Test: manual, TH
Change-Id: Ib98d487f57cf8b55dff61a7969139a6e199fee90
This reverts commit 0135499554.
Reason for revert: Droidmonitor triggered revert due to b/341148479 and b/341138217. Will be verifying through ABTD before submission.
Change-Id: I22e069178dfda0b1791bd77c908afff8cb87bf26
This reverts commit 9b7e07c7aa.
Workaround for the post-submit failure in b/339523786 has been merged.
Fixes: 315245071
Change-Id: I517f13334ad169429daaa68bda7d5f600f653977
Whenever any two Rust static libraries are included
as static libraries anywhere in a CC dependency tree, we sometimes
get duplicate symbol errors. To avoid this, we no longer
directly link multiple rust static libs to CC modules.
Instead, we build rust_ffi_rlib modules and produce the actual
static library that gets linked against the CC module based on
that CC module's full list of Rust rlib dependencies.
This introduces a new static_rlibs property for cc modules to
define the rust_ffi_rlib dependencies, which are then used to
generate the module above.
This CL is intended to deprecate rust_ffi_static. It leaves
rust_ffi_static and rust_ffi static variants in place until
the remaining rust_ffi_static declarations and uses can be
removed. In the meantime, rust_ffi_static produces
rust_ffi_rlib variants as well to make the transition easier.
Bug: 254469782
Test: m # with no changes
Test: m libapexsupport # with static_rlibs
Test: m libunwindstack # with static_rlibs
Test: m netsimd # with static_rlibs, no duplicate symbols
Test: m blueprint_tests # New Soong tests
Change-Id: I47e27ac967ef0cad46d398ebf59d8275929ae28a
Refactor transformSrctoCrate and the functions it calls to not rely
on rust.ModuleContext, preparing it to be callable from soong-cc
context to build a Rust staticlib.
This also refactors out common default flags used when building
libraries, again to prepare for building a Rust staticlib from
a soong-cc context.
Bug: 254469782
Test: m blueprint_tests && m
Change-Id: I678f6fee989c61bb15c340b9887e4d1934991907
This CL brings three changes in how jni_libs are depended on.
1. SDK variants of the jni_libs are depended on only when they can be
embedded. This is because SDK variants are not installable.
Previously, app could depend on SDK variants without embedding them, but
this didn't cause a problem because the installation of the jni libs was
done in Make. However, as it's done in Soong, we need to depend on a
correct variant.
2. Non-SDK variants of the jni_libs are now tagged with jniInstallTag.
This automatically installs the libraries along with the app. The
installation of the jni libs is no longer done in app.
3. checking of the sdk version of the jni libs is done only when they
are embedded. Doing the check even when the libs are not embedded
triggers a lot of false alarms. Note that with #1, many platform apps
have started depending on non-SDK variants.
Bug: 330276359
Test: m
Change-Id: I1bc9ceb8f79b102caeb23476c3fb03989e184a91
java.dependencyTag now has a new field installable which contols whether
the dependency should be added as the install dep of the app or not.
This allows us to model all the dependency tags for Java using the same
struct.
Bug: N/A
Test: m
Change-Id: I9b1c7809a0bde3f15579aefd9bb34d828764b84b
So far, we automatically have embedded JNI libs for APKs in APEX, even
if use_embedded_native_libs was not set or set to false.
With this change, such APKs should explicitly set the property.
This is in preparation for an upcoming change for using different
dependency tags to JNI deps depending on whether they are embedded (thus
no install is needed), or not (thus installation to the partition is
needed).
shouldEmbedJni function now doesn't make use of the ApexInfoProvider
which is not available during deps mutator.
Bug: N/A
Test: m
Change-Id: I836171aacba19dbfa0e09f16a773ae498c56d60b
The installation of the symlink
(<partition>/app/MyApp/lib/<arch>/libfoo.so) and its target
(/system/lib64/libfoo.so) are now done int Soong.
I gave up the idea of always embedding jni libs to apps, due to a
hard-to-fix regression in storage usage. Specifically, consider this
case.
app --(jni_lib)--> libfoo
--(jni_lib)--> libbar
libfoo --(shared_lib)--> libbar
Ideally, with the embedding idea, both libfoo and libbar should be
embedded into the app and there should be no libfoo or libbar outside of
the apk, unless there's no dependency to any of them from outside of the
apk.
However, the previous implementation installed libbar to /system/lib64,
leading two copies of the lib; one in /system/lib64, the other in the
apk.
This was happening because libbar was also considered as a transitive
dep of libfoo, and therefore a dependency to its installation path is
added to the apk. The problem here is that the app doesn't know that
libfoo depends on libbar. We in theory can write a very delicate
dependency traverse routine which filters libbar out of the transitive
deps, but that looked too complicated.
Bug: 339923078
Bug: 330276359
Test: Build and watch any bloatbuster warning
Test: m aosp_cf_system_x86_64
The following three files are found
* system/lib64/libnfc_nci_jni.so
* system/etc/libnfc-nci.conf
* system/priv-app/NfcNci/lib/arm64/libnfc_nci_jni.so
Change-Id: I0930cb1ebb8ca8a6efd64b1ce2cdfd1c47fe19ef
With this change, the deps property in filesystem modules gather the
first target of the filesystem module only.
To gather dependencies across both targets, use multilib.both.deps
instead.
Bug: N/A
Test: go test ./...
Change-Id: Ie2ff0c48f08c61c8b219fc2c1540476ff8e4b1fc
In Android 11 or higher, you can use OverlayConfig
to configure the mutability, default state, and priority
of overlays.
To configure an overlay, you need to create a config.xml
in partition/overlay/config/. Since there is no module type
in soong to install prebuilt artifacts on that location
(like prebuilt_etc for example) we need to manually create
and move that file using Make duing the build process.
This commit adds support to instead create that file
using soong. Then we can instead do something along the
lines of:
prebuilt_overlay {
name: "test-overlay",
src: ":generate-test-overlay",
sub_dir: "config",
filename: "config.xml",
product_specific: true,
}
which would create a config.xml file at the overlay/
directory of the partion in which the overlay is configured,
product/ in this example.
Test: cd build/soong/etc ; go test -run \
TestPrebuiltOverlayInstallDirPath
Bug: 340833016
Change-Id: Iaecae7784683fb9c4306a6834b3ee705c9c20806
During trunk stable development, it is possible that a new boot jar is
added to the source apex, but not available in prebuilt apex yet.
Thefore we need to conditionally check the `contents` of the respective
bootclasspath_fragment modules. https://r.android.com/2822393 did this
using isActiveModule. This function relies on soong config namespaces to
"hide" the source bootclasspath_fragment module when
<module>.source_build is false.
Soong config namespaces for mainline source vs prebuilt selection is no
longer in use, so this CL replaces `isActiveModule`. The CL cleaves the
implementation
1. For source builds, the check will run in the context of the
bootclasspath_fragment module. `disableSourceApexVariant` will be
used to skip the check if prebuilts are selected.
2. For prebuilt builds, the prebuilt bootclasspath_fragment module sets
a provider, and the top-level apex will do the check.
(2) is necessary to handle the edge case of multiple versioned mainline
prebuilts and possible skew in apex boot jars across them. In case of
prebuilt builds, the unselected mainline prebuilts will have
HideFromMake called on them, so the check will only run on the apex that
is actually used during the build.
Bug: 328578801
Test: go test ./apex
Change-Id: I6eec603397eea926f3a481b79ca938245064d809
Merged-In: I6eec603397eea926f3a481b79ca938245064d809
