`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
