Some devices e.g. cuttlefish include BoardConfigMainlineCommon.mk.
This allows BOARD_VNDK_VERSION to be changed other than current, to
allow mixed build experiment with BOARD_VNDK_VERSION.
Test: try setting BOARD_VNDK_VERSION and get_build_var
Change-Id: I7eb7fe6527f24ee2a3b4af32194a48ca98146a78
* changes:
Set BUILD_BROKEN_VENDOR_PROPERTY_NAMESPACE for goldfish
Add BUILD_BROKEN_VENDOR_PROPERTY_NAMESPACE to BoardConfig
Add PRODUCT_SHIPPING_API_LEVEL to productVariables
device/generic/goldfish/sepolicy/common/property_contexts still contains
violations, so temporarily setting build_broken to relax vendor property
check.
Bug: 176210699
Test: m vendor_property_contexts
Change-Id: Ia7d7830a7e994fd0766fd8854524bb6f9fa5cce6
files.
To clean up an unnecessary indirection. Instead introduce a common file
for module products.
Test: lunch module_{arm,arm64,x86,x86_64}
inspect the build banners
Change-Id: Ia312431a664e731f5d801ee2671f62f5cd23bd51
The config sets a few system properties that end up in command-line
arguments passed to dex2oat. Without these properties dex2oat invocation
fails, because options -Xms and -Xmx are do not have an argument.
Test: buid_mainline_modules.sh
Bug: 176171716
Change-Id: I4fd1f059aad5d48495948bfd668307de8b3d9ee1
Add a new BoardConfigModuleCommon for settings of this sort.
Bug: 176840868
Test: forrest module coverage build
Merged-In: Ie62261ecc0f0967f677a890a382fa1da060f7ff2
Change-Id: Ie62261ecc0f0967f677a890a382fa1da060f7ff2
(cherry picked from commit c0423c8dae)
Goldfish specific board variable:
BOARD_EMULATOR_DYNAMIC_PARTITIONS_SIZE
is used to create misc_info.txt, which is needed to mix GSI or CSI on
Goldfish vendor image, and need to reflect the size of the current
super.img, which is now set to 4G+8M (from 3G+8M previously).
Bug: 174442566
Test: $ lunch aosp_x86_arm-userdebug; m
$ ls -l $OUT/super.img # make sure it's 4 GB
$ grep -i dynamic_partitions_group_size $OUT/misc_info.txt
super_emulator_dynamic_partitions_group_size=4294967296
Change-Id: Idd0fb302b20780ac97959fabec231a632205d46d
Current super image for GF is almost full in sdk_gphone_x86_arm
product, and not big enough to include CSI for mixed configuration,
which is a bit bigger than the system image of sdk_gphone_x86_arm.
Bug: 174442566
Test: $ lunch aosp_x86_arm-userdebug; m
$ ls -l $OUT/super.img # make sure it's 4 GB
Change-Id: Ia2473231c8490995a10700cbd6e0f82598a5e078
Prior to this the generic_* devices were typically used for this
purpose. There are a few reasons to create new specific ones:
- the generic_arm64 device has a hack specifically for building
multi-arch packages that we want to avoid
- the generic_* devices include a bunch of emulator config that does not
make sense for unbundled builds
Bug: 172256440
Test: verify unbundled builds migrated from generic_* don't change
Change-Id: Ia937461aa24a5d5b542f8688a1b71ac3fdeb596b
This device/product is suitable for a soong-only build that builds for
all the architectures needed for mainline modules sdk prebuilts.
Bug: 174315599
Test: TARGET_PRODUCT=mainline_sdk soong_ui --make-mode --skip-kati;
(inspect soong.variables)
Change-Id: I3ab5d3611e25a666de39752dedaddbf32ddf6df7
The hashtree is used in verified boot, and sha256 is more robust against
malicious attacks. Also, sha256 uses the same space as sha1 in the
hashtree. And there isn't much performance regression per
https://b.corp.google.com/issues/156162446#comment18
By putting the config in BoardConfigMainlineCommon.mk, we enable sha256
on all Pixels. And devices who want to use a different hash algorithm
can override it in it's own board configs.
Bug: 156162446
Test: boot the device and check performance
Change-Id: I9f1d3bcf241bc65adf10376cc5ae7ab1986216fa
The aosp_arm64 kernel 4.19 prebuilt name is now kernel-4.19-gz instead
of Image.gz.
Bug: 172246735
Signed-off-by: Will McVicker <willmcvicker@google.com>
Change-Id: I4e6a1fefdf207f97cc6ec5e6ebec261473d1218d
Merged-In: I4e6a1fefdf207f97cc6ec5e6ebec261473d1218d
Devices that uses generic ramdisk must inherit from generic_ramdisk.mk.
This makefile ensures that only a set of files can be installed to the
ramdisk. Other files must be installed to the vendor-ramdisk.
Let aosp_arm64 use this makefile.
Fixes: 173742069
Test: manual
Change-Id: Ib2a4a208deaf2f4d707bec256207b4b8479a601a
(cherry picked from commit bc9608c4c3f3cd0ac3f29863209c80fcfe4e2f7f)
This is needed for the emulator to run on Apple Silicon.
In addition, we're going to move to 64-bit only soon across the platform
so it makes more sense to go with 64-bit-only going forward here.
Change-Id: I0d9d189cd0b7a07d6c315e8c0f99c7b4766b4bde
On devices using the generic ramdisk / GKI,
e2fsck is moved to vendor ramdisk now.
Fixes: 173425293
Test: build and manual inspect.
Change-Id: I27562a875ca33a1b6dd3dcf862232fd4dfef6564
If BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES is defined,
in target files, instead of rebuilding the boot image, copy the boot
image already built in $OUT to target files package directly so that
they are the same package.
Define BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES for aosp_arm64.
The GKI APEX is built using the boot image in $OUT. If the boot image in
$OUT is different from the boot image in target files, aka the generic
boot image we release, the GKI APEX we built is invalid.
If another device needs to copy $OUT/boot.img to target files, it can
define BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES.
Fixes: 172682114
Test: lunch aosp_arm64 &&
Change-Id: I10fc7a5aa36e976dbeaf25434239687455bba061
Legacy GSI is the GSI for the O/O-MR1 launching devices. VINTF and
VNDK do not support O/O-MR1 now. It is the time to phase out Legacy
GSI.
Bug: 162277261
Test: none
Change-Id: I55901604da21daa58b51ee6676cd61bb9e4ff5e6
a0281768fe
This revert includes a fix to use the lz4 variant of the kernel,
as was the case before, rather than the uncompressed one.
Bug: 170451791
Change-Id: Iaab082d8bba04df82d742d682251447f3e21fe9b
Revert "Update kernel to builds 6888926"
Revert submission 1454075-2020-10-07-gki-update
Reason for revert: Looks like this topic changes caused daily build broken, the error log as:
error: +out/target/product/emulator_arm64/boot.img too large (34934784 > 33484800)
I tried to revert this topic first and then feel free to revert revert it.
Reverted Changes:
Ie74ca26e8:use new GKI kernel location
Ibff0d9638:Update kernel to builds 6889747
I693476e82:Update kernel to builds 6888926
I35d7f320c:Update kernel to builds 6888926
Id221a7a30:Update kernel to builds 6888926
I4421dbf67:remove kernel, kernel modules from cuttlefish_kern...
I991f9a6af:Allow downstream devices to customize vendor modul...
I598630e09:load kernel, kernel modules from updated locations...
Bug: 170451791
Change-Id: I4d8f18a7c80eb92cb475c48e1dcf04ceabd08984
There are a couple of use cases where we don't want sparse image:
1. `DynamicSystemInstallationService` in Q framework doesn't support
sparse images.
2. Super image manipulation tools (like `lpadd`) doesn't play nice with
sparse images.
Force non-sparse GSI so we don't break backwards compatibility (1) and
we don't need to write `simg2img` everywhere (2).
Bug: 167695592
Test: Prepare a device flashed with Q framework
Test: Build system.img and create system.img.zip; the image is non-sparsed
Test: m tradefed-all && \
tradefed.sh run commandAndExit template/atest_local_min \
--template:map preparers=template/preparers/dsu-preparer \
--extra-file system-img.zip=out/.../system.img.zip \
--dynamic-system-update:disable-tear-down
Change-Id: Ib7667165ce53e87eb86bc7d3f56c80a418123a62
For development and debugging it is useful to have boot images with all
kernel symbols exported.
Bug: 163613927
Change-Id: I6118e5f0fff6e9cbc20ecca6bd362a26a79544b1
Not all devices support BLE_VND_INCLUDED. Disable BLE_VND_INCLUDED
in GSI before it becoming a runtime enabled feature.
Bug: 146149698
Bug: 160930886
Test: build aosp_arm64-userdebug, check the feature manually
Change-Id: I17fd2c1c3cdb87fde11362683d4a7bec1d989b6f
