After commit I59cd149e0021211b8fd59c44b93bbf18dc8637bf, init_first_stage
is no longer installed to the ramdisk when BOARD_USES_RECOVERY_AS_BOOT
is True (see b/190974433 for details and init/Android.mk in that commit).
adb_debug.prop, which is needed for boot-debug.img,
boot-test-harness.img, etc.,will be absent when
BOARD_USES_RECOVERY_AS_BOOT is true, because adb_debug.prop is
only required by the init_first_stage.
Adding adb_debug.prop into generic_ramdisk.mk to include it
unconditionally.
Bug: 192432810
Test: flash boot-debug.img on a user build, check `adb root` works
Change-Id: I234b3430af1b8b09aeb46aef928ca8e16ad452cc
These restrictions enable macros that disable sepolicy access to debugfs
for unauthorized clients on S-launching devices. However, since the
Android S GSI build must also be fully functional on earlier devices
that could have possibly depended on debugfs, disable the build-time
restrictions on GSI builds.
Bug: 184381659
Test: make
Change-Id: I583693df5c30d9bab28f76a6c1e4e9db8e5fd89f
The list of updatable system server jars must be known in
module_common.mk which is used to build mainline modules that contain
said system server jars.
module_common.mk inherit from default_art_config.mk.
Note that we could also move the defition into a separate make file,
if current change causes problems. However, places like clockwork
overwrite values of PRODUCT_UPDATABLE_SYSTEM_SERVER_JARS instead
of appending to them, so it should not be a source of issues.
Bug: 180105615
Bug: 190407034
Test: TARGET_BUILD_VARIANT=user vendor/google/build/build_mainline_modules.sh -j64 and inspecting build artifacts
Change-Id: I771895bf0a974a4c6aa4f7374159c22536f03891
Merged-In: I771895bf0a974a4c6aa4f7374159c22536f03891
Merged-In: Id867ec12ab546613f63a50d608192ab5134f65bb
(cherry picked from commit 66bb2ab32d)
This reverts commit 8685248a99.
Reason for revert: Removing libneuralnetworks_shim.so from Android S
Change-Id: I3fa3092e02e9d1bbf00d801ad68ea754bfbd8c37
Merged-In: I3fa3092e02e9d1bbf00d801ad68ea754bfbd8c37
Mark ANGLE as product-specific and remove building the APK. CuttleFish
will continue to build the ANGLE libraries directly.
Bug: b/187342779
Test: launch_cvd --restart_subprocesses=false --start_webrtc=true --gpu_mode=guest_swiftshader
Change-Id: I6cd379a11e0c198ad72636253f1a33f2d1fc798f
This reverts commit b695e761f1.
Reason for revert: b/185708645 has been fixed
Bug: 169780183
Bug: 185708645
Change-Id: If0ea1168c710eeb4c90d7a9768a278a07adc48fa
Test: Manually updated APEX with same version via OTA/adb-remount and observed it was decompressed.
Devices that launched before Android S must still be able to access
debugfs.
Bug: 188022148
Test: build boot
Change-Id: I18ecec3f7daf5a1085de40606640ead63457c4b2
At runtime it is now responsibility of derive_classpath to define value
of BOOTCLASSPATH. As we are modularizing BCP configs, the end goal is to
have a following ordering:
- ART APEX jars
- /system jars
- /system_ext jars
- /apex jars from non-updatable apexes
- /apex jars from updatable apexes
Note that /apex configs are sorted alphabetically, however they preserve
relative ordering of the jars exported from individual apexes. For
example, core-oj.jar would come before bouncycastle.jar if ART apex
defines their relative order as such.
To match end goal expectations of the APEX ordering, sort existing list
of PRODUCT_UPDATABLE_BOOT_JARS.
Bug: 180105615
Test: presubmit
Change-Id: I15512c0da79ad94b547325d563dac473c006f9fd
Merged-In: I15512c0da79ad94b547325d563dac473c006f9fd
For go/updatable-bootclasspath it would simplify the logic if all
system boot jars were in a single block, instead of having some apex
jars in between them.
core-icu4j.jar used to be part of ART_APEX_JARS before it moved to its
own apex. However, this change puts it after system jars in relative
ordering.
Bug: 180105615
Test: presubmit
Change-Id: Icadc1b67191172bb02d1a15bdfa3d2e6f69227aa
Debugfs build-time/run-time restrictions must be enabled on GSI builds
as well.
Test: Build, boot
Bug: 184381659
Change-Id: I940b0a2f6e22086dd479004a68bf6ad1cfe9eb13
This setting doesn't really make sense for unbundled builds but does
have the side-effect of turning on "full treble", which in turn is used
by some modules (libhidlbase) to conditionally use some particular -D
when compiling. The media.swcodec does not work without this define.
Bug: 185759877
Bug: 185789027
Test: compare media.swcodec apex build with module_arm64 and aosp_arm64
Change-Id: I1ebeb5f37816d8576a00ab7553cb4e9e1cab8cfa
This is a step on the way to make module_arm64 to produce the same
artifacts as aosp_arm64 when building unbundled modules.
Bug: 185765252
Bug: 185789027
Test: compare media.swcodec apex build with module_arm64 and aosp_arm64
Change-Id: I50d29c1d57849fd915dc771bb8e9f028fbe8efcd
This reverts commit f8283a8bf6.
Test: device boots
Test: OTA from uncompressed apexes to compressed apexes works
Bug: 169780183
Bug: 184746992
Bug: 185082717
Change-Id: I62e379f44a1dcf8ebd2b3448dc1381cd99427b45
This certificate will be used to enforce a clean break between "old" CTS
UICCs and new ones. The new UICCs will have hardware support for new
calculations that the old ones aren't capable of.
Old certificate:
./testkey.x509.pem
SHA-1: 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
SHA-256: A4:0D:A8:0A:59:D1:70:CA:A9:50:CF:15:C1:8C:45:4D:47:A3:9B:26:98:9D:8B:64:0E:CD:74:5B:A7:1B:F5:DC
New certificate:
./cts_uicc_2021.x509.pem
SHA-1: 06:97:71:39:21:E8:65:D0:1C:45:C4:A8:8D:45:7A:9D:96:F4:39:27
SHA-256: CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0
We won't yet submit the change to switch the signature of
CtsCarrierApiTestCases, as that will introduce downstream presubmit and
postsubmit failures until the new hardware is available for device labs.
Bug: 178419755
Test: temporarily switch CtsCarrierApiTestCases to be signed with
cts-uicc-2021-testkey, ensure:
- Suite fails on a device with the old CTS SIM due to lack of carrier
privileges
- Suite passes with updated cuttlefish modem simulator ARF content
Change-Id: I7598426bd3e4db90a8f0d8d80ea03468fb30f876
Previously:
* If EMMA_INSTRUMENT_FRAMEWORK=true then jacocoagent was
added to the ART_APEX_JARS which itself is added to
PRODUCT_BOOT_JARS.
* If EMMA_INSTRUMENT=true then it was added directly to the
PRODUCT_BOOT_JARS.
* If both were true then it was added in both places ending up on the
bootclasspath twice.
Bug: 185369704
Test: m EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true droid
m droid
Change-Id: Id1d4d1c98455cb2859ed5e4071a0cf14fb40eec4
This change cleans up after the work to remove the android.test.base
classes from the bootclasspath. That work allowed the presence of
android.test.base in the bootclasspath to be configured at build time
to allow the changes to be tested without affecting the standard
Android builds and avoiding having to repeatedly reapply/revert the
changes that excluded android.test.base from the bootclasspath. That
change has been applied and stuck and no builds change the default by
setting REMOVE_ATB_FROM_BCP=false so we no longer need to support that
capability.
This change removes the build time switch to add
framework-atb-backward-compatibility to the bootclasspath and another
change in the same topic merges those classes into the
framework-minus-apex module. So, while a module has been removed from
the bootclasspath the classes available on it have not changed.
Bug: 184331423
Test: m nothing
Change-Id: I9dadaf8b0c2684bf1983b353bb2acf4f42655e1a
Everyone's on libFuzzer now.
(The "fuzz" referred to in base_system.mk was removed in Android 11, but
this reference was left lying around.)
Bug: http://b/184301511
Test: treehugger
Change-Id: I6fe0f2c37e014647802279a656d2c6c9625b7a44
