There are a couple of instances in apex/ and java/ that rely on the naming
convention that the jars exported by prebuilt apexes follow the name of
the java_sdk_library_import, minus the prebuilt_ prefix. With muliple
module sdk prebuilts in trunk stable, this naming convention might not
be valid. Use `source_module_name` instead.
```
prebuilt_sscp_fragment {name: "", contents: ["service-foo.v2"]}
java_import {name: "service-foo.v2", source_module_name: "service-foo"},
```
We should use service-foo and not service-foo.v2 because
1. The prebuilt apex contains service-foo.dex
2. PRODUCT_*JARS will contain service-foo and not service-foo.v2
For clarity, this CL does not drop the current mechanism where prebuilt bcp
fragments create a dependency edge to prebuilt java or java_sdk_library
imports. There is still some discussion around whether we can remove
that completely (b/320711431). If we were to do that, then the
Android.bp files will become
```
prebuilt_sscp_fragment {name: "", contents: ["service-foo"]}
```
Bug: 322175508
Test: Added a unit test
Test: In internal, lunch cf_x86_64_only_phone-next-userdebug && m
nothing # .ninja files identical
Test: In internal, created a parallel set of v2 prebuilts of
java_sdk_library_import and prebuilt_bcp_fragments for adservices && m
nothing # build passes
Change-Id: Ia899d75e826fa1a559368d706eaa65835f748d40
strict_updatability_linting imposes requirements on all of a module's
transitive dependencies. So you may start getting errors on a module
due to some random other module that is hard to track down. Print out
the modules that caused the current module to use strict updatability
linting so that these errors are easier to debug.
Ignore-AOSP-First: The lint code in internal has diverged from AOSP quite a bit now
Bug: 323366771
Test: m lint-check
Change-Id: I43f2b1adb1ffa5b6e9516694c2bb87c7f94fed7d
How it works:
1. build/make/core/Makefile generates a txt file with the kernel
version, which is taken from an explicit BOARD_KERNEL_VERSION value,
or extracted from the kernel image on the source tree, or extracted
from the kernel image extracted from the prebuilt boot.img.
The file is saved at
$ANDROID_PRODUCT_OUT/obj/PACKAGING/check_vintf_all_intermediates/kernel_version.txt.
2. If PRODUCT_ENABLE_UFFD_GC is "default", meaning the GC type needs to
be determined by the kernel version, build/make/core/Makefile copies
kernel_version.txt to
out/soong/dexpreopt/kernel_version_for_uffd_gc.txt.
3. build/soong/dexpreopt/config.go writes the the UFFD GC flag to
out/soong/dexpreopt/uffd_gc_flag.txt. The flag is determined by an
explicit PRODUCT_ENABLE_UFFD_GC value or by contruct_uffd_gc_flag.py,
which reads kernel_version_for_uffd_gc.txt and determines the flag
accordingly.
4. dex2oat takes the UFFD GC flag from uffd_gc_flag.txt.
5. post_process_props.py mangles ro.dalvik.vm.enable_uffd_gc based on
the same logic.
Bug: 321751629
Bug: 319554951
Bug: 318763448
Bug: 319648491
Test: m --no-skip-soong-tests nothing
Test: atest uffd_gc_utils_test
Test: Build with `OVERRIDE_ENABLE_UFFD_GC=default m` for device with no
UFFD support -
1. Check the existence of `-Xgc:CMC` in
out/soong/dexpreopt_arm64/dex_bootjars/android/system/framework/arm64/boot.invocation
(dex2oat invocation for a boot image)
2. Check the existence of `-Xgc:CMC` in
out/soong/.intermediates/packages/apps/Settings/Settings/android_common/dexpreopt/Settings/oat/arm64/package.invocation
(dex2oat invocation for an app defined in .bp)
3. Check the existence of `-Xgc:CMC` in
$ANDROID_PRODUCT_OUT/obj/APPS/Dialer_intermediates/oat/arm64/package.invocation
(dex2oat invocation for an app defined in .mk)
4. Check the value of ro.dalvik.vm.enable_uffd_gc in
$ANDROID_PRODUCT_OUT/product/etc/build.prop
Test: Build with `OVERRIDE_ENABLE_UFFD_GC=default m` for device with
UFFD support, and do the steps above.
Test: Build with `OVERRIDE_ENABLE_UFFD_GC=true m`, and do the steps
above.
Test: Build with `OVERRIDE_ENABLE_UFFD_GC=false m`, and do the steps
above.
Change-Id: I035ad32233e49e2a30ce11f6c7c318a648511ef8
crt_pad_segment adds a NOTE to the ELF which is used by the binoic
loader to determine whether it should pad segments when mapping them
into the virtual address space, such that there are no gaps between
mappings of consecutive segments. This avoids an increase in
unreclaimable kernel slab memory usage for VMAs on devices where the
runtime-page-size > elf-segment-p_align.
Since -fandroid-pad-segment [1] respects -nostdlib used in android
platform builds, soong must link in crt_pad_segment to platform shared
libraries.
For simplicity, link crt_pad_segment everywhere that crtend_so is
applicable, ignoring nocrt property, as there is no other reason
to track these separately.
Example:
❯ readelf -WS /system/lib64/libc++.so [Output simplified]
...
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
...
[ 2] .note.android.pad_segment NOTE 0000000000000288 000288 000018 00 A 0 0 4
...
[1] https://github.com/llvm/llvm-project/pull/77244
Bug: 316403210
Test: readelf -WS <lib>.so
Change-Id: Icc06611376cfd5ee4de7281b4134f9f8ffe7ca60
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Current VNDK prebuilts are disabled if BOARD_VNDK_VERSION is not set,
but VNDK prebuilts should be enabled even BOARD_VNDK_VERSION is not set
because VNDK APEXes should be available from VNDK deprecation. This
change removes some restrictions on VNDK prebuilts to enable those from
VNDK deprecation.
Bug: 316829758
Test: AOSP Cuttlefish build succeeded without BOARD_VNDK_VERSION
Change-Id: Id780811dab26f2125097c3efc5b2b4a59416b826
For prebuilts, the dexpreopt rules of system server jars are now
generated from the context of the top-level prebuilt apex and not in the
context of the shim java_import modules. Since
`dex_preopt.profile_guided` property is defined in java_import, this
needs to be bubbled up to the top-level apex. This will be done using
deapxerInfo. If profile_guided of a transitive java_import is true, the deapexed .prof file will be
set as dexreopter.inputProfilePathOnHost before invoking
dexpreopter.dexpreopt. This ensures that only that java_import undergoes
profile guided dexpreopt, and not every other transitive java_import
Test: go test ./apex -run TestPrebuiltStandaloneSystemserverclasspathFragmentContents
Test: lunch cf_x86_64_only_phone-next-userdebug && m
$ANDROID_PRODUCT_OUT/system/framework/oat/x86_64/apex@com.android.art@javalib@service-art.jar@classes.odex
Test: du -sh
$ANDROID_PRODUCT_OUT/system/framework/oat/x86_64/apex@com.android.art@javalib@service-art.jar@classes.odex
24K
Bug: 308790457
Change-Id: Ibf46ecb400b3f126b243fc8d27b08d9a1aa4cc97
For prebuilts, java.dexpreopt gets called twice
1. in the context of the top-level prebuilt apex
2. in the context of the java_library shim
Only the artifacts of (1) get installed. The artifacts generated by 2)
are unused. However the args used to generate the artifacts of (1) are
incorrect. It uses moduleName(ctx) to do special-handling of apex system
server jars. This special-handling does not happen in (1), so although
dexpreopt artficats get generated, they get generated with the wrong
args.
To fix this, add an additional parameter in java.dexpreopt to pass the
libraryName explicitly.
Details
- Delete moduleName function. This was used to determine the java
library name, which is no longer safe
- Add a libraryName parameter to java.dexpreopt
- Most module types will use j.Name() as libraryName
- prebuilt_apex and apex_set will iterate over its `contents` and use
each element as libraryName when invoking java.dexpreopt
With the correct args passed from (1), we can drop j.dexpreopt from (2)
completely. Dropping (2) also breaks profile guided dexpreopt tests.
These currently operate on (2). They will be moved to (1) in the next CL
of this stack.
Test: presubmits
Test: lunch cf_x86_64_auto-trunk_staging-userdebug && m nothing (this
was a postsubmit failure with aosp/2923733)
Test: art_standalone_dexpreopt_tests on next https://android-build.corp.google.com/builds/abtd/run/L86000030001579256
Test: art-gtest on git_master-art-host https://android-build.corp.google.com/builds/abtd/run/L07800030001550262
Bug: 308790457
Bug: 322255144
Change-Id: I8eb604c82f1fa5289d3cd1a20084d56e4d7485e3
This provider contains information about the contents of an apex and is
set during the post deps phase of top-level source and prebuilt apexes.
java.dexpreoptDisabled needs to distinguish between platform and apex
variants of a library to prevent creating duplicate ninja rules. It does
so by looking at ApexInfoProvider. This provider gets set on the ctx of
the java_library being dexpreopted.
In case of prebuilts, these rules are being moved to the top-level
prebuilt apexes. Move ApexInfoBundleProvider from apex to android so
that java.dexpreoptDisabled can consume this provider without running
into a golang circular dependency. (java.dexpreoptDisabled will use this
provider in the next CL of this stack).
Test: go build ./android ./apex
Change-Id: I665abd9d0591eeb17b273cc822beb20690e6af09
Aconfig file dependencies are module-independent, and properly part of
ModuleBase.
Bug: b/308625757
Test: manual
Change-Id: I38c5907d1671cc69bb198345201316ae781fdc9f
Convert coverageMutator to a TransitionMutator as a step towards
variants-on-demand.
Bug: 319288033
Test: coverage_test.go
Test: treehugger coverage builds
Change-Id: Ic50c0040dea8b42c36b5d784221daa00b7b0d379
(This was missed in aosp/2876756, which copied only the bcp jars)
This hardcoded location is used by dex2oat to compile the dexpreopt
artifacts. The copy rules are currently generated by java_(sdk)_library
for source builds, and their prebuilt counterparts in prebuilt builds.
After this change, the copy rule will be bifurcated between source and
prebuilt builds
1. For source builds, it will come from java_(sdk)_library
2. For prebuilt builds, it will come from the top-level prebuilt apex.
Since there can be multiple prebuilt apexes in trunk stable,
HideFromMake will be used to determine which deapexed jar to copy.
The bifurfaction is expected to be temporary. It is needed for now since
the `apex_contributions` which will be used for source vs prebuilt
selection have not been populated completely.
Test: Added a unit test
Test: Presubmits
Test: git_master-art-host:
art-gtest (https://android-build.corp.google.com/builds/abtd/run/L40800030001459791)
Test: git_main:art_standalone_tests
(https://android-build.corp.google.com/builds/abtd/run/L09000030001463855)
Bug: 308790457
Change-Id: I3105d3b3a7e5c41cb601d07806f4ea483a61b50a
hiddenAPIFlagFileCategory used to contain function pointers, and is
used in a provider. Providers must be serializable for incremental
soong support, so the function pointers must be removed.
Refactor hiddenAPIFlagFileCategory into a simple int.
Bug: 322069292
Test: m nothing --no-skip-soong-tests
Change-Id: I2bd50fa1b59979f30869b405314cbef16ee345f1
Now that all use cases where it would've errored on are removed.
Ignore-AOSP-First: the properties were only removed in internal main to make the LSC smaller
Bug: 320698986
Test: m nothing --no-skip-soong-tests, and also locally edited soong to add a quick build that runs all the strict updatability checks in the tree and ran that
Change-Id: If9e23327a3c0944cc8c6849914fe51dc48bdb626
strict updatability linting has been disabled for a while now.
In the process of re-enabling it, we need to allowlist all the apexes
that have violations.
Bug: 320698986
Test: Presubmits
Change-Id: I96501bc120d8127cb3675ecbee088ea887fabbc1
aosp/2876754 missed adding error handling to one of the places which
consumes the dex jar deapexed from prebuilt apexes. This CL ensures that
when we have multiple prebuilt apexes _without_ flagging, the hiddenapi
processing code emits a more descriptive error "Multiple deapxers..."
rather than a cryptic error "<module> does not provide a dex jar"
Test: m nothing --no-skip-soong-tests
Change-Id: I80849fa7cca17d724ac53c94bb353b169175ee28
The availability of these soong modules to com.android.runtime has
been made explicit in Android.bp files
One exception is libz. Making apex_available explicit has some subtle
implications on stub/impl selection which breaks coverage builds.
Bug: 281077552
Test: m nothing
Change-Id: I6db7db6dfcb5c468ca68c3e166fe79b9356c4fa8
This change is to fix more misc issues to enable Soong without VNDK
version. This change contains
* Update properties in generated Android.mk
* Update VNDK APEX build to work without VNDK version
Bug: 316829758
Test: AOSP Cuttlefish build succeeded
Change-Id: I10f3c798299afe2d539ec3426b8e2b6068a158f6
* changes:
Copy exportable artifacts to module sdk snapshot
Enable hiddenapi check for exportable stubs
Add defaults support for bootclasspath_fragment module type
This change modifies the dependencies of the hiddenapi to always depend
on the exportable stubs, instead of the currently utilized everything
stubs.
To support this, the full api surface exportable stubs are defined in a
separate change at the `frameworks/base` project. Note that the full api
surface exportable stubs are only used for the hiddenapi purpose, and
`sdk_version` continues to utilize the currently existing everything
stubs.
Currently, this feature is hidden behind the build flag
"RELEASE_HIDDEN_API_EXPORTABLE_STUBS". This feature will be fully
enabled once metalava fully supports handling of the flagged apis.
Test: ENABLE_HIDDENAPI_FLAGS=true m
Bug: 317426356
Change-Id: I109b7cd27b20ceffcdf1766ab8106b0c276be2b3
