b7646e4d4f
This is a relanding of I0930cb1ebb8ca8a6efd64b1ce2cdfd1c47fe19ef plus
some forward fix described below:
Export non-embedded JNI lib names via LOCAL_REQUIRED_MODULES
The non-embedded JNI libs are installed as the dependencies of the APK.
However, that dependency is not revealed to the Make world and as a
result, the JNI libs are dropped from the file_list.txt file which Make
uses to filter files to include in the image file.
Adding the lib names to LOCAL_REQUIRED_MODULES fixes it.
Bug: 341335305
Bug: 330276359
Test: m out/target/product/vsoc_x86_64_only/obj/PACKAGING/system_intermediates/file_list.txt
and check if libcarservicejni.so is there
Test: go test ./... under soong/java
Change-Id: If915a05909129c92fab7a6cbbd0c4c55f5ced598
* 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"
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
* 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
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
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
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
* 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"
Since we will not shrink the resources anyway this is a waste of time
Bug: 338429777
Test: m SystemUI
Change-Id: I388f045294131a304920756607792091627921bc
* changes:
Install transitive deps of jni libs, but not the jni libs themselves
Add SkipToTransitiveDepsTag interface for dependency tags
Revert "Revert "Collect transitve deps of jni libs only for bund..."
Revert^2 "Always embed jni libs and store uncompressed"
Consider this case:
app --(jni_libs)--> libfoo --(shared_libs)--> libprivate
Only libfoo is embedded into the app. libprivate is not embedded because
libprivate is very likely to be depended on by other components in the
platform, in which case it will anyway be installed to /system/lib.
Embedding libprivate into the app will increase the storage usage as a
whole. Furthermore, if libprivate is not a shared lib but a config file
(of type prebuilt_etc), it can't be embedded and therefore must be
installed outside of the app.
However, a problem occurs when libprivate is not depended on by anyone
else. Then libprivate is not installed to the system partition, causing
an error at runtime.
This CL fixes that by making the jni_libs dependency to implement the
new SKipToTransitiveDepsTag interface. Now, jni_libs themselves are not
installed, but their transitive deps are depended on by the app
containing the jni libs.
Bug: 330276359
Test: m NfcNci and check if libnfc-nci.config is installed.
Test: m CarService and check android.hardware.automotive.evs-V2-ndk.so
is installed as well.
Test: go test ./... under soong/java
Change-Id: I04cc92b7fad768a20ec60a02b3e7534641b1e74d
android.ModuleBase already calls aconfigUpdateAndroidBuildActions()
that is the same with CollectDependencyAconfigFiles(). Remove the
CollectDependencyAconfigFiles() to avoid duplication with
aconfigUpdateAndroidBuildActions().
To make the aconfig information available in
GenerateAndroidBuildActions() of all modules, call
aconfigUpdateAndroidBuildActions() before calling
GenerateAndroidBuildActions() of each module.
Also, we don't need SetAconfigFileMkEntries(), which is a duplicate
of aconfigUpdateAndroidMkData()
Bug: 335363964
Test: diff `adb shell printflags` before and after the change.
Change-Id: I52808e442e9fed7db1eae7b7c5ed0b1c5ba74f5d
This change modifies the build actions of java_sdk_library module type
so that it does not perform any compilation actions (i.e. does not
create the top level java_sdk_library jar file). Instead, it delegates
the build actions the top level jar file was performing to the
dynamically created ".impl"-suffixed java library module. The build
actions that are delegated to the impl library module include hiddenapi
processing, dexing, and dexpreopt.
This change relands https://r.android.com/3035972. Implementation
changes from the original change:
- "all_apex_contributions" is added as a dependecy to the implementation
library modules where the parent sdk_library module has a prebuilt
equivalent. This allows the source apex variant to be hidden from make
when the prebuilt is active.
Test: patch in internal main, lunch barbet-ap2a-userdebug && m nothing
Test: m nothing --no-skip-soong-tests
Bug: 332785297
Change-Id: I017938e5567aef82e428e7ceb557d9c9090e0257
Revert submission 3070882-sdk_lib_remove_compilation
Reason for revert: Potential culprit for build breakage of barbet-ap2a-userdebug in git_main
Reverted changes: /q/submissionid:3070882-sdk_lib_remove_compilation
Change-Id: I5135760e13e0152480c68fe91a3c88564e9bc7cb
We do this because otherwise we will be embedding platform libs in the
bundled apps bloating their size.
Bug: 330276359
Test: Build Galery2 and check if libc++.so is not included there.
Change-Id: Ie866b192e9816bcb71b7ca3d74331d14d85592a4
This change modifies the build actions of java_sdk_library module type
so that it does not perform any compilation actions (i.e. does not
create the top level java_sdk_library jar file). Instead, it delegates
the build actions the top level jar file was performing to the
dynamically created ".impl"-suffixed java library module. The build
actions that are delegated to the impl library module include hiddenapi
processing, dexing, and dexpreopt.
Test: m nothing --no-skip-soong-tests
Bug: 332785297
Change-Id: I7534f9eaacf6d9f72fbf8d540b1e26af84106c20
Previously, unlike unbundled apps, if a platform app depends on a native
library, it is not embedded in the app, but installed to <partition>/lib
and the app is instead provided with a symlink to the lib. This actualy
is a legacy from the original Android where native libraries couldn't be
executed while embedded in the apk. To be executed, the native libs had
to be extracted to a mutable storage, but that had a risk of breaking
the verified boot, so libs couldn't be embedded.
Since API level 23, execute-in-place of native libs has become
possible. But platform apps had to opt-in (use_embedded_native_libs:
true) for the feature for a reason that is unclear today. Perhaps, it
was to save disk space in case when multiple apps share the same native
library, but such cases are found to be very rare, or non-existing.
With this CL, two changes are introduced:
1. jni libs are always embededd for all apps (bundled or unbundled)
2. use_embedded_native_libs is deprecated unless the module type is
android_test or android_test_helper_app. It is now a
no-op property. It's left just to not break existing bp files.
This will make unbundled apps bigger, but given that unbundled apps
built using android platform build system are tests, the size increase
should be acceptible.
Bug: 330276359
Test: m
Change-Id: I7df993ea85bce1c0a7222000c403a974818c3362
While the `system-server` API surface extends the `module-lib` API
surface a library can only provide one or the other as they appear
in bootclasspath and systemserverclasspath respectively. A library
that is on the bootclasspath cannot provide a `system-server` API
as it would be usable by non-system server code. A library that is
on the systemserverclasspath could provide a `module-lib` API but
there is no point as it would only be usable by the system server
making it effectively a `system-server` API anyway.
As a result the `system-server` extension directories only contain
`service-*` jars for libraries that provide system server APIs.
e.g.
```
$ ls prebuilts/sdk/extensions/11/system-server | cat
api
service-adservices.jar
service-sdksandbox.jar
$ ls prebuilts/sdk/extensions/11/module-lib/ | cat
api
framework-adservices.jar
framework-connectivity.jar
framework-connectivity-t.jar
framework-sdksandbox.jar
framework-tethering.jar
```
So, in order to construct the whole `system-server` API, i.e. the API
visible to the system server, it is necessary to add in the
`module-lib` extension jars too which this change does.
This is necessary to construct an `api-versions.xml` file for the
complete `system-server` API.
Bug: 336993217
Test: TARGETS=$(for i in public system module-lib module-lib-complete system-server-complete; do U=$(echo $i | sed "s|-|_|g"); echo "out/target/common/obj/PACKAGING/api_versions_${U}_generated-api-versions.xml"; done)
m $TARGETS; mkdir -p before; cp $TARGETS before
m $TARGETS; mkdir -p after; cp $TARGETS after
meld before after
# Review differences.
Change-Id: Ic9652dd28f05e5f569a7a30a84b87f227314d119
Also, fixes the error when it cannot find a module containing the
`annotations.zip` file.
Bug: 336993217
Test: change `apiVersionsModule` setting in `lint.go` to refer to
a non-existent module and then run `m nothing` to see the
error message correctly lists the module name.
Change-Id: I84a9e241d1c3bedebc26e119bd4b9861664c43c1
This allows using select statements with it.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: I6f3efaaa3d82505e38a91ee4ba0e18e404360191
Merged-In: If355d24506e3f117d27b21442a6c02bca3402dc7
Change https://r.android.com/3068903 adds some extra
`android-plus-updatable.jar` files in `module-lib` and `system-server`
directories of API versions 30 through 34 in `prebuilts/sdk`. This
change modifies the build to pass those files, along with appropriate
`--android-jar-pattern` options to Metalava so it can use them when
generating `api-versions.xml` files for the different API surfaces.
The extra patterns are only passed when `extension_info_file` is
specified as there is no point in including the updatable modules that
contribute to SDK extensions without providing information about the
SDK extensions as well.
Bug: 337836752
Test: See https://r.android.com/3068903
Change-Id: I439179a9d35a4bb677e3bf87a3aea4a983724534
Restructures the code a little to make it clear that extensions
directories are distinct from dessert release directories.
Bug: 337836752
Test: m --no-skip-soong-tests nothing
Change-Id: I8ad68f0d112e62f8f1ddda1b6718119fe18eb8a9
This is to support etc/classpaths for filesystem modules.
Bug: 337993199
Test: m aosp_cf_system_x86_64
Change-Id: I0d5d3dc8af9646a24c8ae97d4d1418ddb0e5f46b
