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
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
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
* 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"
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
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
Bug: 336189540
Test: m out/soong/.intermediates/all-event-log-tags.txt
Test: m out/target/common/obj/all-event-log-tags.txt
Change-Id: I3c1f09e57f17e2bea1c79841efc5f8c00c1b4a1c
Merged logtags files will be used for Soong built filesystem images.
Bug: 336189540
Test: m out/soong/.intermediates/all-event-log-tags.txt
Test: m out/target/common/obj/all-event-log-tags.txt
Change-Id: Ib590c2bc8073e9acee6b45ef08092768237cf9d3
Remove the need to wrap java_import modules with a java_library
just to include static dependencies.
Bug: 288358614
Test: TestJavaImport
Change-Id: I888aecc6c0efc696a397fc1dd5d0ef5fd644bebc
Fix dependencies of android_library_import modules so that the -nodeps
modules created by pom2bp are no longer necessary. Provide transitive
manifests (b/288358614), combine static dependencies into the output
jars, and propagate uses_libraries and optional_uses_libraries from
dependencies.
Bug: 288358614
Test: TestManifestMerger
Test: TestAndroidResourceProcessor
Change-Id: Ief45169d04217826fbb21ba283602b38ef0dd3f6
This CL uses OverrideName to ensure that the LOCAL_MODULE does not
contain any version information.
Test: Created CaptiveLoginPortalGoogle.v2, and checked that its
LOCAL_MODULE is CaptiveLoginPortalGoogle
Change-Id: I177441bcd55ca538759b69aafb73d0a8b7261179
LOCAL_DROIDDOC_STUBS_SRCJAR is used to copy entries to OUT_DOCS in
build/make/core/soong_droiddoc_prebuilt.mk, which defines the copy rules
to generate the docs. When generating the documentation, the exportable
stubs should be set as dependencies, so that disabled flagged apis are
not exposed. Thus, this change modifies the entries passed to
LOCAL_DROIDDOC_STUBS_SRCJAR from the everything stubs to the exportable
stubs.
Likewise, all other LOCAL_DROIDDOC_* entries are copied to dist during
sdk builds. Therefore, this change replaces the everything artifacts to
the exportable artifacts.
This change also config-guards the exportable stubs generation, so that
the exportable stubs are not generated when the droidstubs module does
not generate the stubs.
Test: m docs dist && inspect ninja file to verify that everything stubs are not exported
Bug: 323261972
Change-Id: Ic04fb47ad311aefafc2f1a7b8bb15525050ecd2e
This CL is the java_(test_)_import equivalent of aosp/2928483.
With trunk stable, we will have
multiple prebuilts of the prebuilt java .jars in
prebuilts/module_sdk/art/<v>/test-exports/, and this CL introduces a
mechanism to use apex_contributions to select a specific versioned
prebuilt when building.
Implementation details: Create a new source_module_name property to
identify the root module. rdeps referring to the root module will get
redirected if necessary. This property also
becomes the stem, if `stem` is not set explicitly.
Bug: 322175508
Test: Added a unit test
Change-Id: I2dff38acdf2002355586dbb2be8c1f98af4741f7
In order to prepare generating "runtime" stubs in droidstubs, this
change performs some cleanups, which are:
- Modify droidstubs providers methods to take a StubsType enum as an
input, in order to remove exportable-specific providers. The methods
are also modifed to return an error when the artifact is not provided
for the input StubsType.
- Wrap droidstubs artifact to a struct. This removes artifacts common to
all stubs types from being written out as a individual module property
(e.g. exportableAnnotationsZip -> exportableArtifacts.annotationsZip)
Test: m nothing --no-skip-soong-tests
Bug: 319162970
Change-Id: I6d6c57c5417ca71eab5ddda7981b71fd84fa6ee1
dexpreopt of apex system server from prebuilts involves three soong
modules
1. prebuilt_apex / apex_set
2. an internal deapexer module created by the prebuilt apex
3. java_import/java_sdk_library
(3) acts as a shim for the deapexer to set the dexjar extracted from the
prebuilt apex. This methodolody requires a 1:1 correspondence across the
three modules
This breaks down when we have multiple versions of the same prebuilt
apex in the tree. In preparation for this, move the dexpreopt
processing from (3) to (1). Each prebuilt_apex will create the necessary
rules for dexpreopting the jars deapexed from itself. In the future,
apex_contributions will be used to pick which service-foo.{odex|.vdex} to
install depending on which prebuilt apex is selected.
Implementation details
- Embed dexpreopter in prebuiltApex structs so that this module type can
register the dexpreopt rules. Since a single apex can have multiple
system server jars, this also requires creating an additional scope in
dexpreopt.go to prevent name collisions
- Add the dexpreopt modules as required in initApexFilesForAndroidMk
- Add the depreopt modules to androidMk in AndroidMkEntries. Drop the
equivalent from java_import and java_sdk_library_import
Bug: 308790457
Test: existing soong unit tests
Test: lunch cf_x86_64_phone-next-userdebug && m out/target/product/vsoc_x86_64/system/apex/com.google.android.adservices.apex
Test: Verified that the above command installs
/out/target/product/vsoc_x86_64/system/framework/oat/x86_64/apex@com.android.adservices@javalib@service-adservices.jar@classes.{odex|vdex} and the equivalent files of service-sdksandbox
Test: presubmits
Change-Id: I01cea8956d2857fb864b415e73d3d2686d069b5e
Passing the list of all transitive aconfig files to Make causes extra
Kati analysis runs when dependencies are changed in Android.bp files.
Since Make is going to merge them anyways, merge them per-module and
pass a single aconfig file to Make for each module.
Fixes: 313698230
Test: m out/target/product/vsoc_x86_64/system/etc/aconfig_flags.pb
Change-Id: Ifde4826bc93bc06e40338f72b4cb39eed26ca08d
Java libraries were writing lists of files that changed whenever
transitive dependencies changed to Android-${TARGET_PRODUCT}.mk, causing
Kati analysis to rerun whenever a dependency was changed in Soong.
In both cases, Make would immediately use the list to write a single
output file. Write the files in Soong and pass the path to the file
to Make instead, which will both reduce the size of
Android-${TARGET_PRODUCT}.mk and skip Kati analysis more often.
Bug: 309006256
Test: m checkbuild
Change-Id: I5dff16c6fb7cca8c6da927b37c612c7b1d0954e6
Setting Generate_product_characteristics_rro will automatically generate
an RRO package which contains resources with
'product="{PRODUCT_CHARACTERISTICS}"'. The RRO package will be installed
to /product partition. The app will be compiled with '--product
default', making the app identical to all targets.
Motivation for this change is to minimize divergence of system.img.
Bug: 294799593
Test: boot and idmap2 dump
Change-Id: I1371f7410a1ecf337e1f73214b024af39aa6d57a
Flag for java_library modules to build just the Turbine headers and
skip building an impl jar.
Test: go test java
Bug: 289776578
Change-Id: Iad0babf951710476bc32df93c25d17065a14ab84
The R.Java files generated by aapt2 link --no-static-lib-packages
cause scaling problems by combining all resources into every package
listed in a dependencies' AndroidManifest.xml file. For SystemUI-core
this results in 74 R.java files, each with 76k lines, and takes 20
seconds to compile in javac.
Both AGP and Bazel have workarounds for this that avoid using the
R.java files generated by aapt2, instead generating more efficient
R.class files directly based on the R.txt file.
Bazel uses the ResourceProcessorBusyBox tool that is already present
in our tree to process the resources. Reuse the same tool in Soong
to create the R.jar.
The more efficient R.class files require modifiying source files
that use incorrect packages to refer to resources.
Bug: 284023594
Test: TestAndroidResourceProcessor
Change-Id: I026073b40dabcfdb10e5d7a52e9348205b0e9a66
Merged-In: I026073b40dabcfdb10e5d7a52e9348205b0e9a66
If a header jar couldn't be built (for example when an API generating
annoation processor is in use) the implementation jar is reused as the
header jar. If the implementation jar contains an annotation processor
listed in META-INF/services/javax.annotation.processing.Processor then
later javac executions with the implementation jar in the classpath
could attempt to run the annotation processors unexpectedly. Remove
the META-INF/services directory when using an implementation jar as
a header jar.
Bug: 290933559
Test: builds
Change-Id: I40d48644bc5a09a9564dc2c4b38f627edd00fcf8
Currently, java_library.stem property is not correctly reflected in the
output jar name in java_library when the module specifies
java_resource_dirs property. This change fixes the unexpected behavior
so that setting the stem property behaves as expected.
Test: go test ./java && m
Bug: 285843207
Change-Id: I0941fcea83c92f4c42ae415aa6ad9125da5cf57b
Instead of rolling assets and manifests up through each static lib,
provide them as a DepSet. This will help with the next patch, which
needs to pass all the transitive manifests and R.txt files together.
Test: app_test.go
Change-Id: Id8b3aa2bed3771e82ab6bde192c9b43baa38b54c
(cherry picked from commit fdf043a7b1)
Test: built fuzz targets locally and tested them with Jazzer
Change-Id: I3ff487ba4e34289e0f53f2077463f524f4bf4f11
Context
- from-text android.jar files are built using Metalava, and these can be
utilized in `decodeSdkDep` so that any modules that depends on APIs
can be compiled using from-text android.jars
- This change removes dependency on source java files when compiling
stub android.jar files
Implementation
- Modify java_api_library module to create system modules using the
generated android.jar
- Replace modules in decodeSdkDep to link against java_api_library
modules
- Add --build-from-text-stub flag to hide the feature behind a flag
Test: m --build-from-text-stub
Bug: 271154441
Change-Id: I104df595edc65c0006820d5ae5b15f1fb167e190
This reverts commit 502da3987a.
Reason for revert: b/274195633
```
In file included from out/soong/installs-aosp_cf_x86_pasan.mk:134984:
In file included from out/soong/Android-aosp_cf_x86_pasan.mk:981696:
In file included from build/make/core/soong_cc_rust_prebuilt.mk:76:
build/make/core/base_rules.mk:342: error: packages/modules/Uwb/service/uci/jni: MODULE.TARGET.SHARED_LIBRARIES.libuwb_uci_jni_rust already defined by packages/modules/Uwb/service/uci/jni.
```
Change-Id: Ic1ea6969e54c23a7d126eb0fb47ab6f2e44ee965
Currently, non-apex variants of modules that are in apexes are not
exported to make unless they're apex_available to the platform. This
means that you can't `m` those modules directly.
However, there is a workaround in the apex androidmk implementation that
emits make rules for the removed modules, but just redirects them to
build the apex itself. We want to remove that, but one of the problems
with doing so is that you can no longer `m` many modules afterwards.
To fix that, unhide the apex's dependencies from make. To ensure they're
not installed, call SkipInstall() on them, and update SkipInstall() to
be more strict by setting `LOCAL_UNINSTALLABLE_MODULE := true`.
Bug: 254205429
Test: Presubmits
Change-Id: Ib971981559f3b642ce6be8890679e994e1b44be0
Currently, non-apex variants of modules that are in apexes are not
exported to make unless they're apex_available to the platform. This
means that you can't `m` those modules directly.
However, there is a workaround in the apex androidmk implementation that
emits make rules for the removed modules, but just redirects them to
build the apex itself. We want to remove that, but one of the problems
with doing so is that you can no longer `m` many modules afterwards.
To fix that, unhide the apex's dependencies from make. To ensure they're
not installed, call SkipInstall() on them, and update SkipInstall() to
be more strict by setting `LOCAL_UNINSTALLABLE_MODULE := true`.
Bug: 254205429
Test: Presubmits
Change-Id: Ib094feb2c437ad50d8319c58caa997759e7ce32f
Previously, as all versioned sdk snapshots have been removed from
Android.bp files this method would always return false. This change
effectively replaces all calls to it with false, and then optimizes
away any unused code.
Bug: 260237150
Test: m nothing
Change-Id: I1b717ee8345e807bd888451f6e7e3c3a0d391ee2
Previously, various places duplicated the logic to check whether a
module was part of a versioned snapshot. This change replaces that code
with a call to the existing IsModuleInVersionedSdk(Module) func.
This makes the code consistent in preparation for a change that will
remove all calls to IsModuleInVersionedSdk(Module). It is separated out
from that change as it is easier to see that the replaced code is
equivalent to the IsModuleInVersionedSdk(Module) func when it is not
mixed in with other changes. It also makes the following change easier
to review.
Bug: 260237150
Test: m nothing
Change-Id: I44d665bf02d2fc97632a03b5a3d2225ea3c2827d
