Contents that were in /vendor/default.prop are now in /vendor/build.prop
The content is placed at the top of build.prop to keep the existing
order between default.prop and builld.prop.
Bug: 117892318
Test: TH passes
Test: inspect /vendor/build.prop and check if it has contents from
the old /vendor/default.prop file
Change-Id: Ifa1f1dca3b4f4a5fa87d26b8ee058ee706dc54bb
PRODUCT_PACKAGES contains "simple module name" and "bitness suffix".
Call `resolve-bitness-for-modules` to resolve module bitness before
using PRODUCT_PACKAGES.
Bug: 155869107
Test: TH presubmit build_test
Test: check the value of event_log_tags_src
Change-Id: I95fcd833990b3401892c2f7859c83acd90f9e920
* Add get-modules-for-2nd-arch helper function
Add a generic function to retrieve second arch variant module names for
TARGET, HOST and HOST_CROSS modules.
It uses ALL_MODULES.<module>.FOR_2ND_ARCH to make sure that we are
really returning second arch variant module names.
Unlike `get-32-bit-modules` this function doesn't sort its output so it
potentially saves us a tiny bit of makefile parsing time.
* Add resolve-bitness-for-modules
Factor out the common bitness-resolving logic of
`product-installed-files` and `host-installed-files` to a helper
function.
When resolving HOST_CROSS modules, the primary arch is 32-bit and
secondary arch is 64-bit.
Bug: 155869107
Test: TH
Test: check the value of product_target_FILES and product_host_FILES
Change-Id: I0fdea2e8c55e5b8edf960dbf5e17bb789abb0bf8
The different boot images in aosp_arm64 have different partition size
requirements. Add support for defining a partition size associated with
each boot image variant.
This support is limited to aosp_arm64 currently, which is built with
recovery-as-boot.
Bug: 156036850
Bug: 155049180
Change-Id: I73b70a4d52c2662c3015899632bb8a2b424108d5
'os_version' and 'os_patch_level' are not defined in vendor boot image header,
so remove INTERNAL_MKBOOTIMG_VERSION_ARGS to avoid confusion
Test: lunch aosp_cf_x86_64_phone-userdebug; m vendorbootimage
Change-Id: I19c82846c9669bbd5475605e8b2457744040390d
Enables signing for them so we can verify that the boot partition
contains a valid generic boot image during the compliance test.
This change also adds the chained partition descriptor of
boot partition into vbmeta.img, which contains the corresponding
public key used to verify the boot partition.
Bug: 151094943
Test: lunch aosp_arm64-user, `make` and use `avbtool info_image`
to check that GKI images are properly signed.
Test: `make dist` and checks that GKI images in the image zip file
are properly signed.
Change-Id: I2fd69964f9dc62526a813875fa9193913aa4935b
(This is a cherry-pick change.)
Bug: 153675112
Test: m cts && ls out/host/linux-x86/cts/android-cts/testcases/
Change-Id: I2f24f4567ed3fab1f6ad4d66cc0f798332543b8d
Merged-In: I2f24f4567ed3fab1f6ad4d66cc0f798332543b8d
With I1889653812a980f6a2e3b6b25e7647f7c5919606, libvixl is not available
to the platform as it is included in the ART APEX. To use the APEX
variant of the library, we use the <name>:<apex_name> notation.
Exempt-From-Owner-Approval: cherry-pick from internal
Bug: 150999716
Test: m
Merged-In: I2206f1c28fc0019c0fd726059aa732145f2998ed
(cherry picked from commit 127eae76bc)
Change-Id: I2206f1c28fc0019c0fd726059aa732145f2998ed
Revert "Move libpac into i18n APEX"
Revert "Add shared library into i18n APEX and add the required s..."
Revert "Make com_android_i18n namespace visible"
Revert submission 1299494-i18nApex
Reason for revert: Breaking aosp_x86-eng on aosp-master
Reverted Changes:
I30fc3735b:Move ICU from ART APEX to i18n APEX
Icb7e98b5c:Calling @IntraCoreApi from core-icu4j should not c...
Ic7de63fe3:Move core-icu4j into I18n APEX
I65b97bdba:Make com_android_i18n namespace visible
Ia4c83bc15:Move v8 and libpac into i18n APEX
I10e6d4948:Move core-icu4j into i18n APEX
I8d989cad7:Move ICU from ART APEX into i18n APEX
I72216ca12:Move ICU into i18n APEX
Ief9dace85:Add shared library into i18n APEX and add the requ...
I7d97a10ba:Move libpac into i18n APEX
I90fff9c55:Move ICU from ART APEX into i18n APEX
Change-Id: I12a7d609d43620edaf2c5f12711eb3ca3a570d79
This reverts commit 6e1fa4452b.
Reason for revert: relanding a reverted changed
Bug: 153073816
Change-Id: I3735866776cf6eb0320c9fb8c6be8ac0c48baa1c
Test: m
This reverts commit f9e67a8980.
Reason for revert: broke some targets
Exempt-From-Owner-Approval: reverting
Change-Id: I10af29b0fcf564dba0c3dbc1951b660b24fc58bb
This change fixes a regression that was caused by I56bc55e2231eb946617a9d6f97d55c9b61f3bff7
that file names for Make modules are ".apk" in apkcerts.txt.
This was because PACKAGES.$(LOCAL_MODULE).STEM was only set for the
modules from Soong. It is now set for Make modules too.
Bug: 155440232
Test: OVERRIDE_TARGET_FLATTEN_APEX=true m apkcerts-list
and check the generated apkcerts txt file to see that it doesn't have an
entry where file name is ".apk"
Exempt-From-Owner-Approval: cherry-pick from internal
Merged-In: I6f14bbb5678255bef2c1f2397f59ede6c2b5df18
(cherry picked from commit db64e3d528)
Change-Id: I6f14bbb5678255bef2c1f2397f59ede6c2b5df18
_apkcerts_write_line has assumed that the stem name of a package is the
same as the module of it. That assumption however breaks for
APK-in-APEX, in which case the stem name is Foo while the module name is
Foo.com.android.bar (where com.android.bar is the name of the APEX where
the APK is in).
Fixing the issue by recording the stem name and use it.
Bug: 155440232
Test: OVERRIDE_TARGET_FLATTEN_APEX=true m apkcerts-list
and check the generat4ed apkcerts txt file to see that it has
Tethering.apk instead of Tethering.com.android.tethering.apex
Exempt-From-Owner-Approval: cherry-pick from AOSP
Merged-In: I56bc55e2231eb946617a9d6f97d55c9b61f3bff7
(cherry picked from commit f58fd52b14)
Change-Id: I56bc55e2231eb946617a9d6f97d55c9b61f3bff7
Everything should be getting device specific kernel headers from the
device_kernel_headers header library these days.
This does change the behavior of system libraries on devices using the
VNDK -- they no longer get device-specific kernel headers by default, as
we generally expect the system image to be device-independent. The few
libraries that may still need this can use:
LOCAL_HEADER_LIBRARIES += device_kernel_headers
Test: treehugger
Change-Id: I90ccb921d58b8d27dd0118a974202696e0af745f
The first component is the apex name, or a special name "platform"
if the boot jar is a platform jar rather than a part of some apex.
This is a prerequisite change for moving core-icu4j to a separate
com.android.i18n apex.
Old one-column format is still supported, but all unqualified
components of PRODUCT_BOOT_JARS get "platform:" prepended to them
after reading the product makefiles.
Test: aosp_walleye-userdebug boots
Bug: 138994281
Change-Id: I0f79c7d10477880ca65354251a5d1ca0b7ce79ab
* changes:
Use .KATI_IMPLICIT_OUTPUTS in build/make/core/Makefile
java_source_list_file is only created when full_classses_jar is set
Remove empty rules for check_elf_files.timestamp
RECOVERY_FROM_BOOT_PATCH has been moved to vendor as per b/68319577. Hence,
the reserved size should be moved from system to vendor as well.
Bug: 68319577
Bug: 153581609
Test: m target-files-package for non-A/B devices
Change-Id: I2fd3fea10ec6dd06f19c5be753d63ddff1ec01f7
There were still two places where we weren't using it. There may be
more, but these are the ones that come up with aosp_cf_x86_phone.
Test: m out/target/product/vsoc_x86/root/default.prop
Test: m out/target/product/vsoc_x86/obj/NOTICE_VENDOR.txt
Change-Id: I17671ca2ed60332aed2bf76aa00e42a92661b58a
If we don't have any new dependencies, or we never set up the
check_elf_files.timestamp rule, don't create an empty one now.
There were >7000 of these unused and empty rules in my AOSP
aosp_cf_x86_phone build.
This was initially brought to my attention by the new checks in
https://github.com/google/kati/pull/189
Test: diff out/build-aosp_cf_x86_phone.ninja, only removed phony rules
Change-Id: Ia43cbbd04df4a01d2182b14e3ccbe5d5ecbcabad
