Changes https://r.android.com/3106478 and https://r.android.com/3110137
unintentionally started reporting some previously hidden issues as
error when new. This change hides those issues again.
Bug: 343157584
Test: m checkapi before and after
Change-Id: I2e04c919ce5c4f2b39fab65afd13bc31725031f0
This change modifies the contents of the generated Android.bp files so
that when generating a snapshot on a older platform, the "exportable"
modules are removed from the bp files, as the "exportable" modules are
first introduced in V and do not exist in older platforms.
Bug: 345162614
Test: ABTD
Change-Id: I2dba51b98deec7805bd796647a66981f237c55a9
`com.android.art` and its overrides include a `etc/boot-image.prof`
which is used on device for profile guided dexopt.
```
$ deapexer list <path_in_product_out>/com.android.art.apex | grep
boot-image
$ deapexer list <path_in_product_out>/com.google.android.art.apex | grep
boot-image
```
To identify that we should include a boot-image.prof in the override
apexes, we currently look at ApexInfo.InApexVariants in the context of
art's bootclasspath fragment module. InApexVariants are colated based on
the min_sdk_version of the top-level apex. At ToT, we have a single
variant of `art-bootlcasspath-fragment` for aosp art apex, google art
apex and google go art apex.
When google go art apex overrides the min_sdk_version, ApexInfo is
cleaved, and two distinct variants of art-bootclasspath-fragment are
created. The one corresponding to go art apex does not know we should
include boot-image.prof
To fix this, use AllApexInfoProvider instead. If any of the apexInfos
corresponds to com.android.art, include etc/boot-image.prof
Test: Added a unit test
Test: With https://b.corp.google.com/issues/345173231#comment2 reverted,
m com.google.android.go.art && deapexer list <apex> # verified that
boot-image.prof exists
Bug: 345173231
Bug: 295311875
Change-Id: I5a0e8f74725388f05343c64f268260b1eb139ae5
This changes makes bpf module type uses OutputFilesProvider,
instead of current OutputFileProducer for inter-module-
communication.
Test: CI
Bug: 339477385
Bug: 342406930
Change-Id: I85d1141e9f6583cc5427756107da99f56b0c7ea1
Revert submission 3060229-ron-tmc-symlinks
Reason for revert: Droidmonitor created revert due to b/344045516
Reverted changes: /q/submissionid:3060229-ron-tmc-symlinks
Change-Id: If5045366677163560cdae95c0ab74256b4b49b9a
Follow-up to https://r.android.com/3106478 to have exportable handle
documentation issues being errors in the same way as everything does.
Bug: 343157584
Test: ./gradlew
Change-Id: Iba490e46e2ff202e2ef78f49389319ee8549fe3f
Now the derived modules will have symlink's to base's testcase dir
rather than copyfile files from base's intermediates dir.
I also removed storing the "base" module as dependency and only use
data from the provider in GenerateAndroidBuildActions and
AndroidMkEntries.
I did have to add two fields to the provider for this.
To ensure the symlinks always resolve to a physical file, I also added
goals such that building `derived-target` will also build `build-target`
Create new Make variable: LOCAL_SOONG_INSTALLED_COMPATIBILITY_SUPPORT_FILES
for tasks/general-tests.mk,device-tests.mk to read.
This allows "support" files that are installed with soong rules rather
than make rules to still end up in the zips.
Sample dir structure:
% tree -ls testcases aosp_cf_x86_64_phone[4:31:54]/0
[ 4096] testcases
├── [ 4096] FrameworksServicesTests
│ ├── [ 4096] data
│ │ └── [ 851] broken_shortcut.xml
│ ├── [ 2800] FrameworksServicesTests.config
│ ├── [ 12695] JobTestApp.apk
│ ├── [ 8599] MediaButtonReceiverHolderTestHelperApp.apk
│ ├── [ 16791] SimpleServiceTestApp1.apk
│ ├── [ 16791] SimpleServiceTestApp2.apk
│ ├── [ 16791] SimpleServiceTestApp3.apk
│ ├── [ 1017763] SuspendTestApp.apk
│ └── [ 4096] x86_64
│ └── [ 79827767] FrameworksServicesTests.apk
└── [ 4096] FrameworksServicesTests_contentprotection
├── [ 4096] data
│ └── [ 54] broken_shortcut.xml -> ../../FrameworksServicesTests/data/broken_shortcut.xml
├── [ 3005] FrameworksServicesTests_contentprotection.config
├── [ 41] JobTestApp.apk -> ../FrameworksServicesTests/JobTestApp.apk
├── [ 69] MediaButtonReceiverHolderTestHelperApp.apk -> ../FrameworksServicesTests/MediaButtonReceiverHolderTestHelperApp.apk
├── [ 52] SimpleServiceTestApp1.apk -> ../FrameworksServicesTests/SimpleServiceTestApp1.apk
├── [ 52] SimpleServiceTestApp2.apk -> ../FrameworksServicesTests/SimpleServiceTestApp2.apk
├── [ 52] SimpleServiceTestApp3.apk -> ../FrameworksServicesTests/SimpleServiceTestApp3.apk
├── [ 45] SuspendTestApp.apk -> ../FrameworksServicesTests/SuspendTestApp.apk
├── [ 36] test_module_config.manifest
└── [ 4096] x86_64
├── [ 64] FrameworksServicesTests.apk -> ../../FrameworksServicesTests/x86_64/FrameworksServicesTests.apk
└── [ 36] UNUSED-FrameworksServicesTests.apk
Test: m clean && atest FrameworksServicesTests_contentprotection
Test: m clean && atest CtsDevicePolicyManagerTestCases_ParentProfileApiDisabled
Bug: b/332320956
Change-Id: I8466f253fa559bc74cef4533edf263650e96bbfb
If profile guided dexpreopt _and_ optimization/obfuscation is true, then
apps must use the rewritten profile created by r8/d8
Bug: 335418838
Test: m nothing --no-skip-soong-tests
Change-Id: Iac45b614f43e52ac40ad1d13df0338bcafa788c3
Currently, dexpreopt supports profile guided optimization. This does not
work well with r8/d8 optimization, since the checked-in profile will not
match the dex signatures after r8/d8 has optimized the dex code.
This CL introduces a new property `dex_preopt.enable_profile_rewrting`.
If set, the checked-in profile will passed as `input` to r8 via
`--art-profile <input> <output>`. The <output> from the previous command
will be used as the profile for dexpreopt.
Test: m nothing --no-skip-soong-tests
Test: m CredentialManager with https://ag.corp.google.com/27448930
and obfuscation turned on
Test: nm -U symbol.odex # contains obfuscated methods
Bug: 335418838
Change-Id: I53beed9ed76f013262f1c503de0f2b74997c2a7f
Previously, documentation issues had `lint` severity (which was between
`warning` and `hide`) by default. However, a recent change in Metalava
switched documentation issues to `error`. That broke some `droidstubs`
modules that either did not specify `api_lint` or were previously allow
listed to not use `--lints-as-errors`.
This change adds `--error-when-new-category Documentation` to the
Metalava arguments on any use of `droidstubs` that did not previously
specify `--lints-as-errors` to prevent the build breakage while still
warning developers of the problem and preventing new cases being added.
Bug: 343157584
Test: ./gradlew
Change-Id: Id80bc05e2dade580b2f3ac6416aeeed6b64ba22a
`UpdateDirectlyInAnyApex` is used to propagate the ApexProperties
`DirectlyInAnyApex` and `InAnyApex` to the direct dependencies of the
direct dependencies of an apex bundle. In other words, this will be
propagated only to two-levels max dependency from the apex bundle.
However, the implementation library of the sdk library can have longer
dependency chain from the apex bundle than two levels:
e.g. apex -> bcpf -> sdk_lib -> sdk_lib impl lib
Therefore, even if the implementation library of the sdk library is
registered as a dependency using the "CopyDirectlyInAnyApexTag"
dependency tag, the ApexProperties would not be propagated to the
implementation library. In order to resolve this issue and recognize
the implementation library to be directly in apex and allow
instrumentation for the implementation library, this change proposes
propagating `DirectlyInAnyApex` and `InAnyApex` to transitive
dependencies on top of direct dependencies.
Test: DIST_DIR=dist_dir TARGET_BUILD_VARIANT=userdebug PRODUCT=mainline_modules_x86_64 COVERAGE_MODULES="uwb" ./vendor/google/build/build_unbundled_coverage_mainline_module.sh && \
unzip -l out/target/product/module_x86_64/jacoco-report-classes-all.jar and ensure that framework-uwb is included
Bug: 341170242
Change-Id: I27d7a74f6e5bc3e0a044d13c619f4897b6b2eb57
https://r.android.com/3094444 has removed instrumentation from the
implementation library of the java sdk library. However, given that the
top level java sdk library was not being instrumented before removing
the compilation action, there is no way to get the coverage data for the
java sdk library included in the mainline modules with the
aforementioned change.
As seen in b/340174053, instrumenting all impl libraries by default
may lead to double instrumentation execution time error in some edge
cases (especially with make to soong dependency).
Given the above two conditions, this change allows instrumentation for
the implementation library of the java sdk library that belongs to
apex(es).
Test: lunch husky-trunk_staging-userdebug && EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true m droid dist
Test: DIST_DIR=dist_dir TARGET_BUILD_VARIANT=userdebug PRODUCT=mainline_modules_x86_64 COVERAGE_MODULES="uwb" ./vendor/google/build/build_unbundled_coverage_mainline_module.sh
Bug: 341170242
Change-Id: I175e02f61e139296f5a177e6fc1c3ded760ac028
To include a sdk library impl and a permission xml for that.
Bug: 340365498
Test: m aosp_cf_system_x86_64 && check if there is a sdk lib impl and
permission xml
Change-Id: I10190fb9d398b6249efd6fe50b204e328250f23f
* changes:
Revert^2 "Refactor how jni_libs dependencies are added"
Revert^2 "Add make java.dependencyTag installable or not"
Revert "Revert "APK-in-APEX should set use_embedded_native_libs:..."
Revert^2 "Install jni symlinks in Soong"
Revert submission 3094658-revert-3088867-QEHDREAABY
Reason for revert: not a regression
Reverted changes: /q/submissionid:3094658-revert-3088867-QEHDREAABY
Change-Id: Ie1e4a196f181643a3e64e573b132d52d7455461b
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
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>
Currently, the implementation library of the java_sdk_library is always
being instrumented due to the issue described in b/159241638.
With https://r.android.com/3079425, all compilation actions of the
java_sdk_library is delegated to the implementation library.
Consequently, this has caused all java_sdk_library to be instrumented,
leading to coverage builds failing due to double instrumentation (i.e.
instrumenting an already instrumented class file). In order to prevent
such error, this change modifies the property of the implementation
library to not instrument during coverage builds.
This change also copies some additional java library properties from
that of the implementation library to the top level sdk library, in
order to ensure that all non-null androidmk entries are correctly
reflected in that of the sdk library.
Test: lunch husky-trunk_staging-userdebug && EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true m droid dist
Bug: 340174053
Bug: 341170242
Change-Id: I9d8f1c190205fa7a827649961ba5222293a945ad
This is a followup https://r.android.com/3089366 that disabled the
creation of out/soong/hiddenapi/hiddenapi* files for non java device
builds. This works fine for `m`, but `m dist` runs issues since
`f/b/boot/Android.bp` dists these files. For non java devices, the
previous implementation would report missing files during ninja
excecution (https://b.corp.google.com/issues/338363444#comment5)
This CL creates empty files for these so that the dist tags can always
be resolved.
Bug: 338363444
Test: lunch aosp_cf_x86_64_minidroid-trunk_staging-userdebug && m dist
Change-Id: Ice2d970a164246753da89a6a06dfd28a627a272d
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
* 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
* 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
