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
The ABI dumps depend on the LLNDK API level and SDK version defined
in the release configurations. The error messages shows additional
parameters for the user to select the right version and variant.
Test: make libvulkan
Bug: 323447559
Change-Id: If12f3f74be49c3036516f42fb5d91979b610fafe
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
After aosp/3089654, Android.mk files will be able to read
EXTRA_INSTALL_ZIPS, which we don't want. Use the new
$(KATI_visibility_prefix) to restrict its usage.
Test: m nothing passes, adding $(warning $(EXTRA_INSTALL_ZIPS)) in build/make/core/main.mk produces an error
Change-Id: Ib3c0079efd534e580a176fc69f746852b66297af
platform-bootclasspath constructs the monotlithic hiddenapi flags by
looking at PRODUCT_BOOT_JARS which are not included in another
bootclasspath fragment. PRODUCT_BOOT_JARS is a product specific
property, and non java devices like minidroid have an empty value for
this. For such devices, the monolithic flag generation runs into an
error because there are no jars to run this on.
This CL disables the generation of monolithic specific hiddenapi flags
when there are no monolithic boot jars in the build.
Bug: 338363444
Test: lunch aosp_cf_x86_64_minidroid-trunk_staging-userdebug && mmma
frameworks/base
Change-Id: I093690786bcf85b2aa6f01d0c689fc2a35861b5c
Replace the performOverrideMutator with a TransitionMutator.
This relands I358f260f1bcd894d7803036ce77ba666c0429355, which was
reverted due to a subtle behavior change when converting AliasVariation
into an IncomingTransition. AliasVariation is temporary, losing its
effect after the next call to CreateVariations that doesn't also call
AliasVariation. dexpreopt_bootjar.go was checking if a variant existed
after the apex mutator had run and obsoleted the alias created by the
perform_override mutator. When the alias was replaced by
IncomingTransition it wasn't obsoleted and dexpreopt_bootjar.go found
extra dependencies. The extra dependencies were picked up by the
core licensing code walking dependencies, and caused a significant
increase to the size of system/etc/NOTICE.xml.gz.
ag/27324277 removed flags that triggered the extra dependencies,
which prevents the system/etc/NOTICE.xml.gz increase for now.
b/340911730 tracks avoiding the unnecessary dependencies if the
flags are re-enabled.
Bug: 319288033
Flag: NONE
Test: all soong tests pass
Test: no change to build.ninja
Change-Id: I46171ba69f24482414a20d63a131941a162f025c
Currently, you can't have two prebuilt_etcs in one apex with the same
file name, because apexes emit make modules for all the files in the
apex, and the module name for the prebuilt_etc's make representation
is based on the base filename of the installed file. We can change it to
be qualified based on the full relative path of the outputfile so that
you don't hit the conflicts as much.
Fixes: 340207931
Test: Presubmits
Change-Id: I7836fd4661fcaafd91901eba7e0b89506946c3e2
This reverts commit d94cccc523.
Reason for revert: Patchset 2 was wrong, doesn't actually fix the bug
Change-Id: Ie2d931ad3e2277ce1923284b13f50f62ac2f8917
If a map was included twice, we had side effects when skipping the extra
inclusion.
Bug: 340659219
Test: manual, TH
Change-Id: I90c55a800ecad932f8f67cf6f9f60dba571f7c48
Trying to clean up cruft from envsetup.sh
Shell functions require re-sourcing envsetup.sh, and should be avoided
if possible.
Bug: 340648588
Test: try the scripts
Change-Id: I15ec39b0382d9dd60e290dae633e8730a8d18131
Currently, you can't have two prebuilt_etcs in one apex with the same
file name, because apexes emit make modules for all the files in the
apex, and the module name for the prebuilt_etc's make representation
is based on the base filename of the installed file. We can change it to
be qualified based on the full relative path of the outputfile so that
you don't hit the conflicts as much.
Bug: 340207931
Test: Presubmits
Change-Id: I6708d89c755c31c17cce112fb08a810e51926c76
* changes:
Revert "Revert^2 "Always embed jni libs and store uncompressed""
Revert "Revert "Revert "Collect transitve deps of jni libs only for bund...""
Revert "Add SkipToTransitiveDepsTag interface for dependency tags"
Revert "Install transitive deps of jni libs, but not the jni libs themselves"
Only add a repository to the trace when it actually specifies
aconfig_value_sets.
Also default to only generating the release config .mk file for the
current TARGET_RELEASE (rather than all), to reduce kati reruns.
Bug: 340126861
Test: manual, TH
Change-Id: I671d4b5f57c9bdd252d98e048f16aa9c7b3b2ffa
When a common-arch module (ex: phony) has the "required" dependencies on
native modules (ex: cc_library), both 32 and 64-bit variants of the
native modules are added as dependencies. This by itself is fine and
actually is intended, otherwise there's no way for us to install both
arch variants via required deps.
However, this imposes a problem when the common-arch module is depended
on by a filesystem module with compile_multilib: "first". Here, the
expectation is that only the first variant (64-bit) of the native module
is instaled, but in reality both variants are installed.
To handle this situation, make sure that the packaging routine filters
out packaging specs from unsupported architecture.
Bug: N/A
Test: go test ./... under soong/filesyste
Change-Id: Ie1ad5ace2e5d88e00183a115f4a76e5df87a8166
By setting aconfig_flags: true, soong filesystem module installs the
aconfig_flags.pb file to its etc directory.
We need to define aconfigFilePaths to ModuleBase to store the list of
aconfig file paths that is generated from the GenerateBuildActions().
The aconfigFilePaths are collected when build the filesystem module
to build the aconfig_flags.pb for the filesystem image.
Bug: 335363964
Test: compare the cache list with those generated from make.
Change-Id: Ia32b566bf43174e94b9e610b9503608c6b583899
soong_build uses / as it's cwd, so we need to specify the top directory
when checkign for files.
Test: add a printf in the if statement; touch out/soong/Android.bp && m nothing; ensure printf doesn't fire
Change-Id: Iba9773765547b22a03dbca33aa6b8c75359cb5ff
Make needs to know the primary file, because the zip is only extracted
when the primary file is installed.
Bug: 337869220
Test: m out/target/product/emu64x/obj/PACKAGING/system_intermediates/file_list.txt and checking it for the extra NetworkStackGoogle apks, with a local NetworkStackGoogle android_app_set added into the tree
Change-Id: I5cb7243d214f4730e3f9efb6746793f3bf4b8214
Since we will not shrink the resources anyway this is a waste of time
Bug: 338429777
Test: m SystemUI
Change-Id: I388f045294131a304920756607792091627921bc
This change fixes a bug that required deps from native module to phony
module was ignored. It happened because addRequireDeps incorrectly
thought that both are native modules with different bitness (32->64),
which isn't.
Fix this by doing the bitness check only when both the current module
and the required module are native modules.
Bug: N/A
Test: go test ./... under build/soong/filesystem
Change-Id: I494ebc47e29001f174fa44d72809041f8ceffb0b
