This change moves the ro.build.require.* props extracted from
TARGET_BOARD_INFO_FILE to vendor/build.prop as opposed to
system/build.prop. These typically contain what bootloader and
baseband the build requires, which are very device-specific.
Bug: 130025216
Test: make, inspect props
Test: flash blueline
Change-Id: I48642485bdc853884d465d1fe00f2ceae69a4736
Merged-In: I48642485bdc853884d465d1fe00f2ceae69a4736
Some people apparently still talk to the network during their build.
Allow this temporarily with a BUILD_BROKEN_USES_NETWORK check.
Bug: 129992021
Test: attempt to talk to the network during the build with and without
this flag
Change-Id: I45612ad6165f92f123847b4057338c0dfc3424ee
Merged-In: I45612ad6165f92f123847b4057338c0dfc3424ee
(cherry picked from commit 0586c65780)
Prior to this change the properties were in system/etc/default.prop.
These properties are device-specific and don't really belong on the
/system partition.
I anticipate further change to these properties in the future:
- pruning down the set of properties, as the .product. props
don't make much sense for the boot image
- moving them to the ramdisk instead
Bug: 130025216
Test: boot into recovery, observe title (shows bootimage fingerprint)
Change-Id: I9e92c1ec7068ae18fa0d709c77eac22a6b88c3d8
Merged-In: I9e92c1ec7068ae18fa0d709c77eac22a6b88c3d8
Like Ie413f84c545c869ee336912a7b05ca80bb968129, but for all
mainline devices.
Bug: 119800099
Test: m
Change-Id: Ief77adaea61203a013f85cf870c5350253fdb7dd
Merged-In: Ief77adaea61203a013f85cf870c5350253fdb7dd
We only need to define it once. dex_preopt_libart.mk can be read
multiple times if there are many boot image.
Test: m && no warning
Bug:119800099
(cherry picked from commit 7e8ca9a174)
Change-Id: I16d67b77142fce93c6d4acc15f557ad073b2de44
Merged-In: If5b8fbb0c3310eb42f676d7b5267dcee679f7e19
Test: lunch walleye_jitzygote-userdebug m && all odex file use the apex image
Bug: 119800099
(cherry picked from commit 0639b7de03)
Change-Id: Ic76f3ad6da0425479fbe660efe0a0677e60771a2
Merged-In: Ieb8f36b94264496a41998d4ceca30e1f41a98ebe
We used to add framework.jar to proguard via -systemjars option even
for the apks building againsd SDK. This was because the app might have
references to hidden APIs via static libraries, etc.
However, for vendor apks, the use of hidden API is strictly prohibited.
So it is fine to not include framework.jar. Furthermore, including
framework.jar even causes problems in some cases; if a java library
(e.g., android.hidl.base-V1.0-java) is statically linked to both the app
and the framework.jar, -systemjars frameworks.jar forcibly removes
classes in the library from the app to have references to the non-public
classes in framework.jar. This could fail some compliance tests.
Fixing the problem by not raising SDK for apks located in vendor or odm
partitions.
Bug: 128574081
Test: m
Merged-In: If2b658fead5b4bb4d8c023a37eb57a37ad9b741d
Change-Id: If2b658fead5b4bb4d8c023a37eb57a37ad9b741d
(cherry picked from commit eadd1bdb8e)
If TARGET_USERIMAGES_SPARSE_EXT_DISABLED is set, don't provide
--sparse to lpmake, so that a non-sparse super image is built.
Test: build with the flag set.
Bug: 120041578
Change-Id: I5a26e4c793b0e2ddc89e9c38c8828ac21044e78a
Merged-In: I5a26e4c793b0e2ddc89e9c38c8828ac21044e78a
