PRODUCT_NEXT_RELEASE_HIDE_FLAGGED_API added to the sdk targets will be used to determine whether to exclude flagged apis for next release or not.
Test: m TARGET_PRODUCT=sdk nothing
Bug: 299570421
Change-Id: I00cb84341a05e296a0c747d4921ed5fe445eabe6
Rather than PRODUCT_SHIPPING_API_LEVEL, use board api level
(BOARD_API_LEVEL or BOARD_SHIPPING_API_LEVEL) to determine whether we
check coredomain violations or not.
Also provides a Makefile variable to override the flag, for targets that
want to turn on the check optionally.
Bug: 280547417
Test: see build command of vendor_seapp_contexts
Change-Id: I177630d33313334ca4a56a9be88b78cff678281e
Like aosp/2495518, but adds the ability to centrally disable HWASan
for multiple modules when building with SANITIZE_TARGET=hwaddress.
HWASan takes precedence over CFI and several other sanitizers that it's
incompatible with[1], which can be problematic for modules that require
those sanitizers (e.g. those that depend on vendor prebuilts where only
sanitized variants are provided). This patch adds an easy way to disable
HWASan for such modules while still keeping it globally enabled.
Test: build with HWASAN_EXCLUDE_PATHS set and verify with readelf that
relevant modules have no references to __hwasan symbols
[1] bb31ca1168/core/config_sanitizers.mk (236)
Change-Id: I64185b570bc64e61680c3212934a02d80a4904b9
The new boolean flag will be PRODUCT_PAGE_SIZE_AGNOSTIC.
When PRODUCT_PAGE_SIZE_AGNOSTIC is true:
- AOSP will use getpagesize() to retrieve the page size.
- The flag `TARGET_MAX_PAGE_SIZE_SUPPORTED` has to be equals to `65536`.
- AOSP will be able to use 4k/16k page size Linux kernels
When PRODUCT_PAGE_SIZE_AGNOSTIC is false:
- AOSP will only support 4k page size kernels.
Test: source build/envsetup.sh
lunch aosp_raven_64-userdebug
get_build_var TARGET_PAGE_SIZE_AGNOSTIC
get_build_var PRODUCT_MAX_PAGE_SIZE_SUPPORTED
65536
source build/envsetup.sh
lunch aosp_raven_64-userdebug
build/make/core/config.mk:414: error: TARGET_MAX_PAGE_SIZE_SUPPORTED has to be 65536 to support page size agnostic.
10:32:55 dumpvars failed with: exit status 1
Bug: 289419664
Change-Id: If8fc243a3e2cad77414a53a29805c7b6d349d4dd
...from devices launching after Android V.
Devices can add them back in explicitly now that they are also moved to
system_ext.
Test: m
Bug: 218588089
Change-Id: Ib3c917896c7a9b2c5940922c9faddb44cc7a0766
We will deprecate flattened apexes. In this change, GSI-specific make
variable (PRODUCT_INSTALL_EXTRA_FLATTENED_APEXES) is removed. The
variable was used to install both image/flattened apexes in the GSI, so
that it works on ro.apex.updatable devices and not-updatable devices.
Now, GSI will have only image APEXes in it.
Bug: 278826656
Test: lunch gsi_arm64-userdebug && m # no flattened apexes
Change-Id: I4702973d4ee75aa693e4e7f4e57577b77059dc09
Allow product configuration of memtag target list by
moving the current set into a product variable instead of the various
.bp files.
The default list of memtag targets can be found in
build/make/target/product/memtag-common.mk
This is NFC as all targets in the list already have "memtag_heap: true"
in the build files.
Bug: 280343521
Test: no functional change
Change-Id: I5954fde05256e00a8e01c114ad522f50ed0cfa9f
This flag controls whether com.android.virt APEX should include an
additional kernel image that supports modules loading.
Bug: 283822676
Bug: 278008256
Test: m
Change-Id: I296c57308e130ee6d5d185dcb4b690d11d2b04ac
Adding in build time flag for specifying cow version, in preparation to
add new cow version in libsnapshot
Test: m -> cat misc-info.txt
Bug: 279954153
Change-Id: I148d4e7cdd669496c91213889787172ffd83a5ab
The PRODUCT_MAX_PAGE_SIZE_SUPPORTED will be used to define the
ELF segment alignment of the binaries (executables and shared
libraries). The alignment is set based on these conditions:
- If PRODUCT_MAX_PAGE_SIZE_SUPPORTED is defined, that value will be
used to align the binaries. If not defined, see condition below:
- If it is a low memory device, 4096 will be the alignment. If it is
not low memory device, see conditon below:
- If VSR vendor API level < 34, 4096 will be the alignment, otherwise
it will be 65536.
Test: Built for in Pixel 4a, 6 and verified the alignment with readelf.
Bug: 276963698
Bug: 276801883
Change-Id: I53a8902ab62e6d378aec84c28bc627f0e8a98500
Currently, PRODUCT_AFDO_PROFILES is generally applied to all products and is not semantically treated as a product config varilable.
Splitting this allows us:
1. Explicitly tell that PRODUCT_AFDO_PROFILES takes precedence over product-agnostic profiles in AFDO_PROFILES
2. Add PRODUCT_AFDO_PROFILES to _product_vars_list
Test: Define PRODUCT_AFDO_PROFILES in a product config and make sure it appears first in the soong var AfdoProfiles
Bug: 277215393
Change-Id: I284f6308d456994bb72129cb0d7be7cd091993ae
Merged-In: I284f6308d456994bb72129cb0d7be7cd091993ae
Previously, the product var is defined in pixel product config only. This breaks SDK finalization for udc (google3/configs/wireless/android/busytown/platform/git_udc/git_udc-release.gcl). In SDK finalization, we need to ensure performance/usage of libraries are consistent across all builds that don't set SKIP_ABI_CHECKS.
This CL optionally includes the afdo_profiles if available so that afdo is on all products by default.
Ignore-AOSP-First: The topic has internal-only CLs
Test: CI
Bug: 276672785
Change-Id: I2cc51412de141c4e6ad69f49cef378121e0b3b87
Merged-In: I2cc51412de141c4e6ad69f49cef378121e0b3b87
Environment variables HWASAN_INCLUDE_PATHS and
PRODUCT_HWASAN_INCLUDE_PATHS can be used to enable HWASan for multiple
modules, by just adding the module directory to the env variable.
Bug: b/271948407
Test: Set specific module directory to above env variable and check the
assembly codes of output elf files after building, finding hwasan
related symbols inside.
Change-Id: I4493cb627fb564ee317eb95bd24ec020d42ae28c
This is needed so we can run hwasan-enabled apps for debugging on normal
system images.
Bug: 276930343
Change-Id: Ie572d77307e5e6268b851ea5c96aae05d588dae3
Ignore-AOSP-First: Ignore-AOSP-First: Other CLs in the same topic are internal-only
Test: m nothing
Bug: 267229065
Change-Id: I2d71daa6af97eeb0050e1084b27b03900d2d75ef
Merged-In: I2d71daa6af97eeb0050e1084b27b03900d2d75ef
Added new properties, which could be set for AOSP/GSI builds.
These properties are going to be used for attestation feature through
Build.java class. Earlier in AOSP builds attestation ids were different
from provisioned ids in Keymint. These properties will be identical to
provisioned ids.
Bug: 110779648
Bug: 259376922
Test: atest VtsAidlKeyMintTargetTest:PerInstance/NewKeyGenerationTest#EcdsaAttestationIdTags/0_android_hardware_security_keymint_IKeyMintDevice_default
Test: atest VtsAidlKeyMintTargetTest:PerInstance/NewKeyGenerationTest#EcdsaAttestationIdTags/1_android_hardware_security_keymint_IKeyMintDevice_strongbox
Test: atest CtsKeystoreTestCases:android.keystore.cts.KeyAttestationTest CtsKeystoreTestCases:DeviceOwnerKeyManagementTest
Change-Id: I9eea5e0f2fabc667b3efedeeefdf12e7b4fc9502
When we have dedicated .mk files for each modules (e.g. usb, drm, etc)
and those modules have their own linker configuration requirements, it
would make more sense to have "fragments" for linker configuration.
This change introduces a new list variable to store the list of linker
configuration fragments. When it's set, vendor/etc/linker.config.pb is
generated from the list of input fragments.
Bug: 264330513
Test: set PRODUCT_VENDOR_LINKER_CONFIG_FRAGMENTS
Test: m vendorimage (generates vendor/etc/linker.config.pb)
Change-Id: I9eed0f90add0191885b7195efdab94b5b1a4a62d
Example usage:
PRODUCT_INCLUDE_TAGS += use_myspecial_sdk
This also populates the allowlist with go/nogo mainline tags. Usage of
`PRODUCT_INCLUDE_TAGS` outside this allowlist will raise an error
in product config
Test: TH
Change-Id: Ica82a8f65cbfda600d72fc54fb873c1eaa1666a7
This is determined by:
- a product config flag
- the vendor API level
It is then passed to the device as a system property
"ro.dalvik.vm.enable_uffd_gc".
This change is a no-op change. It doesn't enable userfaultfd GC by
default. OVERRIDE_ENABLE_UFFD_GC=default can be passed to the build
system to enable userfaultfd GC for testing purposes.
Bug: 242553398
Test: -
1. lunch aosp_redfin-userdebug
2. OVERRIDE_ENABLE_UFFD_GC=default build/soong/soong_ui.bash --dumpvars-mode --vars=ENABLE_UFFD_GC
3. See "false" in the output
Test: -
1. lunch aosp_oriole-userdebug
2. OVERRIDE_ENABLE_UFFD_GC=default build/soong/soong_ui.bash --dumpvars-mode --vars=ENABLE_UFFD_GC
3. See "true" in the output
Test: -
1. lunch aosp_redfin-userdebug
2. OVERRIDE_ENABLE_UFFD_GC=true build/soong/soong_ui.bash --dumpvars-mode --vars=ENABLE_UFFD_GC
3. See "true" in the output
Test: -
1. lunch aosp_oriole-userdebug
2. OVERRIDE_ENABLE_UFFD_GC=false build/soong/soong_ui.bash --dumpvars-mode --vars=ENABLE_UFFD_GC
3. See "false" in the output
Change-Id: Ifd6e6cddb502315912ff949619a5b526ae0d73ff
The change in the packages/modules/Virtualization in the same topic
takes care for defining the right variant of the APEX to be installed:
* Devices with AVF support will get the full com.android.virt APEX
* Devices without AVF support will get an almost empty version that only
contains an app that defines AVF-related permissions, and soon the BCP
fragment jar.
Bug: 243512044
Test: build & flash oriole
Test: build & flash redfin
Change-Id: I2c38e03529a77dd2820212812433741725115ce0
* Expand the allowlist to include {system_ext, vendor, odm,
product}/framework/*. Generate .fsv_meta for them.
* Add BuildManifest.apk for those partitions.
* Rename PRODUCT_SYSTEM_FSVERITY_GENERATE_METADATA to remove "SYSTEM".
* (new in reland): add apkcerts
Bug: 245957815
Test: m
Test: ls -l $ANDROID_PRODUCT_OUT/*/etc/security/fsverity/BuildManifest.apk
Test: extract assets/build_manifest.pb from apk, inpsect
Test: run asit/ota/signing
Change-Id: I48a5e473aa5eedb24edab54357a9141fc8d78759
* Expand the allowlist to include {system_ext, vendor, odm,
product}/framework/*. Generate .fsv_meta for them.
* Add BuildManifest.apk for those partitions.
* Rename PRODUCT_SYSTEM_FSVERITY_GENERATE_METADATA to remove "SYSTEM".
Bug: 245957815
Test: m
Test: ls -l $ANDROID_PRODUCT_OUT/*/etc/security/fsverity/BuildManifest.apk
Test: extract assets/build_manifest.pb from apk, inpsect
Change-Id: I503672571741d47ba15add048c0a2f00b6b2a86d
verity.mk is used to set the related variable for VB 1.0 support, but
we already removed VB 1.0. This change removes the unused code. We also
remove and block PRODUCT_VERITY_SIGNING_KEY in this change.
Bug: 241044073
Test: atest under build/make
Change-Id: Ifbcde7da27a931ef3b9d746b1c5a279d88c0ec85
PRODUCT_SUPPORTS_VERITY and PRODUCT_SUPPORTS_VERITY_FEC are going to be
deprecated since we removed VB 1.0 support. This change removes the
related references.
Bug: 241044073
Test: atest under build/make
Change-Id: Icee659ff0606cda1ab44e92372d86a394ddf1466
These varaibles are going to be deprecated since we removed VB 1.0
support. This change removes the related references. boot.img can be
verified by a AVB 2.0 hash descriptor now.
Bug: 241044073
Test: atest under build/make
Change-Id: I267da2d591525ffc0cabf92791cf66a36ef8ff62
The makefile product inheritance code was supposed
to deduplicate inheritance calls, but there was
a bug in the uniq-word function that caused it
to not work when duplicated words were adjacent.
$(subst |||x|||,||| |||,|||x|||x|||) produces
||| |||x||| instead of ||| ||| |||.
Rewrite the uniq-word function to fix the bug.
This issue was causing a discrepency between
the makefile and starlark based product configurations,
as the starlark implementation didn't have this bug.
Bug: 237019892
Test: ./build/bazel/ci/rbc_dashboard.py --quick on an internal-only product
Change-Id: I543a80746412ffcb9743203399413a0e707111e6
The long-form variables (PRODUCTS.<makefile>.<variable>)
are used to get information about multiple products.
However, they've never really worked correctly, and so
importing multiple products is deprecated behavior.
Remove as many usages of the long-form variables and
multi-product imports as possible.
Bug: 228518445
Test: Manually
Change-Id: I0b67f16360ff8bdcdb39638de739440472bccf76
This overrides the branch default
(BRANCH_DEFAULT_MODULE_BUILD_FROM_SOURCE) if it is set to use
prebuilts.
Test: build/soong/soong_ui.bash --dumpvar-mode MODULE_BUILD_FROM_SOURCE
returns false with BRANCH_DEFAULT_MODULE_BUILD_FROM_SOURCE:=false
in internal
Test: env TARGET_PRODUCT=module_arm64 \
build/soong/soong_ui.bash --dumpvar-mode MODULE_BUILD_FROM_SOURCE
returns true with BRANCH_DEFAULT_MODULE_BUILD_FROM_SOURCE:=false
in internal
Test: env TARGET_PRODUCT=mainline_modules_x86 \
build/soong/soong_ui.bash --dumpvar-mode MODULE_BUILD_FROM_SOURCE
returns true with BRANCH_DEFAULT_MODULE_BUILD_FROM_SOURCE:=false
in internal
Test: env TARGET_PRODUCT=redfin \
build/soong/soong_ui.bash --dumpvar-mode MODULE_BUILD_FROM_SOURCE
returns false with BRANCH_DEFAULT_MODULE_BUILD_FROM_SOURCE:=false
in internal
Bug: 222723757
Change-Id: I0faea006b0e95eff40bbfbe00cc74ba5985beeba
Add vendor_kernel_boot image for vendors whose bootloader support
extra first stage booting kernel modules ramdisks. This benefit
kernel repo to build kernel-artifacts only image without Andorid
artifacts dependency.
Bug: 214409109
Signed-off-by: Lucas Wei <lucaswei@google.com>
Change-Id: If07218b86a7751b3d452a172610af960f5f9ec74
Currently inherit-product and the rest of the product
configuration infrastructure does not handle wildcards.
However, they still get passed through unchanged, until
they reach the raw Make include statement, which expands
them. This essentially makes a meta-product that is the
result of combining all the makefiles that were matched.
In Starlark, the behavior is to actually treat each file
as it's own product. This causes a discrepency when using
`m product-graph`, where make shows one node for all those
files and Stalark has a node for each.
This is probably unintentional behavior, so change Make
to also import each file as separate products. On the
product I was investigating, the only difference this
made in the ninja file was in the product graph.
Bug: 221312856
Test: Presubmits
Change-Id: I9ca7aff0b0790aeb6e42861ce2745feed8a1a7c4
There are 2 choices to build system_dlkm.img for
the system_dlkm partition for Android T launch
devices and must choose one.
1. Use kernel prebuilt system_dlkm.img
- BOARD_PREBUILT_SYSTEM_DLKM_IMAGE to point image
2. Build from kernel prebuilt system_dlkm_staging
- PRODUCT_BUILD_SYSTEM_DLKM_IMAGE
Both requires: BOARD_SYSTEM_DLKM_PARTITION_SIZE and
must be 64MB or higher in size (enforced via vts).
Bug: 200082547
Test: TH
Test: atest vts_system_dlkm_partition_test
Signed-off-by: Ramji Jiyani <ramjiyani@google.com>
Change-Id: I83435123bd8aa3d04ab8a8b650a95fbab0bc49f2
I56ed328a9ae70cf49dbd3c6efb5a4a8c54e1b7a7 added a validation check to
otatools to check the target_files archive for the existence of
userdebug_plat_sepolicy.cil. That check superseded the original
PRODUCT_INSTALL_DEBUG_POLICY_TO_SYSTEM_EXT product_config.mk check and
is more robust because it can handle not only phone GSI but also car/tv
GSI (downstream of phone GSI).
Modify the check to show a scary wall of text if non-compliance-GSI
products tried to set PRODUCT_INSTALL_DEBUG_POLICY_TO_SYSTEM_EXT,
instead of erroring out immediately.
Also add gsi_car_arm64 & gsi_car_x86_64 to the list of eligible GSI
product names.
After this change, any product can set
PRODUCT_INSTALL_DEBUG_POLICY_TO_SYSTEM_EXT for development purposes, but
only GSI products that specifies `--allow_gsi_debug_sepolicy` during
image signing can release sign a product built with
PRODUCT_INSTALL_DEBUG_POLICY_TO_SYSTEM_EXT.
Bug: 188067818
Test: Presubmit
Test: lunch gsi_arm64-userdebug && m nothing # => no warning
Change-Id: I34ef49af29c7064bea8924b0070793f1e78256bf
Equivalent to PRODUCT_EXTRA_RECOVERY_KEYS but for A/B OTA.
Bug: 211848136
Test: set PRODUCT_EXTRA_OTA_KEYS and check otacerts.zip
Change-Id: I81e27d12a22b405f6227b09c01ed684dfcede19e
This ramdisk used to be in boot.img, and is now placed into this new
init_boot.img instead.
This new image is used for a new init parition to seperate Android
platform artifacts from the kernel artifacts in boot.img.
Test: boot Cuttlefish
Bug: 203698939
Change-Id: Iaaf82486259979ab728730ce72a4e847ae005c18
This is the list of jars that system_server loads dynamically using
separate classloaders. We will rely on this variable to decide which
jars to preopt in the build system and on the device for system_server.
The list is supposed to be in sync with the code in SystemServer.java.
There will be a follow-up CL to add a comment in SystemServer.java to
remind developers to keep them in sync.
Bug: 203198541
Test: m nothing
Change-Id: I305a73218ef2d2c61ac3795d21026b2afe7007fd
builds (reland).
- Use art/build/boot/boot-image-profile.txt for the primary boot image
in the ART module, both when it's built from source in platform and
as an unbundled module.
- Use frameworks/base/boot/boot-image-profile.txt for the framework
extension image in platform, but not in unbundled builds.
This should obsolete the combined profile
frameworks/base/config/boot-image-profile.txt.
This relands https://r.android.com/1881863 with a fix to allow multiple
values on PRODUCT_DEX_PREOPT_BOOT_IMAGE_PROFILE_LOCATION.
Test: build/soong/soong_ui.bash --dumpvar-mode \
PRODUCT_DEX_PREOPT_BOOT_IMAGE_PROFILE_LOCATION
and check that it prints both art/build/boot/boot-image-profile.txt
and frameworks/base/boot/boot-image-profile.txt in a platform build
on master.
Test: build/soong/soong_ui.bash --dumpvar-mode \
PRODUCT_DEX_PREOPT_BOOT_IMAGE_PROFILE_LOCATION
and check that it prints only art/build/boot/boot-image-profile.txt
in an unbundled build on master-art.
Test: banchan com.android.art && m
on master-art and check that
out/soong/.intermediates/art/build/apex/com.android.art/android_common_com.android.art_image/image.apex/javalib/x86_64/boot.oat
shrinks from 14 MB to 4.7.
Test: m droid
on master together with https://r.android.com/1895131 and check that
out/soong/.intermediates/art/build/apex/com.android.art/android_common_com.android.art_image/image.apex/javalib/x86_64/boot.oat
and out/target/product/vsoc_x86_64/system/framework/x86_64/boot-framework.oat
are identical.
Test: lunch armv8-eng && art/tools/buildbot-build.sh
on master-art
Bug: 174746397
Change-Id: I9114271bc69cf0888150b2c778a086bc50b73045
Using fsverity tool, fsverity metadata for specific artifacts in system
mage can be generated. Users can do that by setting a makefile variable
PRODUCT_SYSTEM_FSVERITY_GENERATE_METADATA to true.
If set to true, the following artifacts will be signed.
- system/framework/*.jar
- system/framework/oat/<arch>/*.{oat,vdex,art}
- system/etc/boot-image.prof
- system/etc/dirty-image-objects
One fsverity metadata container file per one input file will be
generated in system.img, with a suffix ".fsv_meta". e.g. a container
file for "system/framework/foo.jar" will be
"system/framework/foo.jar.fsv_meta".
Bug: 193113311
Test: build with PRODUCT_SYSTEM_FSVERITY_GENERATE_METADATA := true
Change-Id: Ib70d591a72d23286b5debcb05fbad799dfd79b94
Add PRODUCT_BROKEN_DEPRECATED_MK_SYSTEM_SERVER_JARS variable that is
undefined by default. Setting that variable to true enables support for
system server jars defined in Android.mk. It should be enabled on a
per-product basis in product makefiles.
Bug: 203618671
Test: m nothing
Change-Id: If90d7131d37f308c468e395c236d5aa5ad053bad
This reverts commit a2a5db4466.
Reason for revert: original change was obsoleted by
I3161e42b00a93177a1a4cb3b22da2218d294b7a7
Bug: 202129499
Test: Presubmit; change should be noop
Change-Id: Ib7be1ed73dbf08758276666f8ce35ed9cbf18a36
