* 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 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
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
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
If a map was included twice, we had side effects when skipping the extra
inclusion.
Bug: 340659219
Test: manual, TH
Merged-In: I90c55a800ecad932f8f67cf6f9f60dba571f7c48
Change-Id: I90c55a800ecad932f8f67cf6f9f60dba571f7c48
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
Merged-In: I671d4b5f57c9bdd252d98e048f16aa9c7b3b2ffa
Change-Id: I671d4b5f57c9bdd252d98e048f16aa9c7b3b2ffa
