Starting with Android R launched devices, debugfs cannot be mounted in
production builds. In order to avoid accidental debugfs dependencies
from creeping in during development with userdebug/eng builds, the
build flag PRODUCT_SET_DEBUGFS_RESTRICTIONS can be set by vendors to
enforce additional debugfs restrictions for userdebug/eng builds. The
same flag will be used to enable sepolicy neveallow statements to
prevent new permissions added for debugfs access.
Test: build, boot
Bug: 184381659
Change-Id: I45e6f20c886d467a215c9466f3a09965ff897d7e
This is a squash of the following commits:
1. Optimise dex flags for a faster boot
* Used multiple threads and speed profile to hasten the first boot
Signed-off-by: baalajimaestro <me@baalajimaestro.me>
Change-Id: I2cce5ddf7d50308511e81436fcac613b2c6537bf
2. Rework dex flags again
When I went through https://source.android.com/devices/tech/dalvik/configure my previous configs felt wrong, this one should be perfect (I hope).
Even though there is a slight trade-off for boot time by using the speed profile, we do make up for it by using 8 threads.
PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER attempts to compile all prebuilts fully optimised to speed level, thus the phone doesnt need to deal with it.
I also do know that this might be a trade-off on size, but I do see the first boot time is more worthy to trade-off.
The speed level mentioned here runs dex verification and compiles all AOT methods.
Signed-off-by: baalajimaestro <me@baalajimaestro.me>
Signed-off-by: Omkar Chandorkar <gotenksIN@aosip.dev>
Change-Id: Ic0156ff8956a7c5f53820be6db438f6f6399d3c0
3. Switch certain dexopt profiles to verify
Prebuilt apps like Gmail/Google App, will be updated by google play, and there is no need spend time and space optimising what is going to be replaced.
Switch to Google's recommendation of using verify for an OTA package.
Applications still stay on speed.
Instead, replace the install profile with speed-profile making apps perform better.
Signed-off-by: baalajimaestro <me@baalajimaestro.me>
Change-Id: I2cce5ddf7d50308511e81436fcac613b2c6537bf
Those keys will be embedded into VtsSecurityAvb on host side
instead, to verify the GSI image used on the device.
Bug: 149806769
Test: build and checks those keys are removed from
$OUT/recovery/root/first_stage_ramdisk/avb/
Change-Id: I8a002ba6f1421fb460056ccae6572050bdb0ce3c
* qcom-camera topic hasn't been ported to 19.1
* Keep building vendor.qti.hardware.camera.device@1.0 interface lib, IMS stack and possibly camera HAL still needs it
Change-Id: I87bcd5b54ad986d5844df50de243fc1a18507198
06-20 17:06:14.489 13542 13542 F linker : CANNOT LINK EXECUTABLE "/vendor/bin/hw/android.hardware.nfc@1.2-service": library "libchrome.so" not found: needed by /vendor/lib64/ese_client.so in namespace (default)
Change-Id: I96f88c27feea3deeb535eef43533aef4b869734b
Supports to enable/disable USB data signaling
Bug: 161414036
Test: Pass USB V1.3 HIDL tests
Signed-off-by: Albert Wang <albertccwang@google.com>
Change-Id: Iffe00f8753206fb66cd3ab96cae5aa5ad9c410cd
The idea is to allow us to not depend on stock QTI Bluetooth HAL, as MAC
addresses fetched from NVRAM by nv_mac script will be saved as hex-encoded
files. We can decode back saved files to then the Bluetooth one be set using
persist property so it can be read by Bluetooth HAL.
This is loosely based on similar techniques used on Mi 9 and ZenFone Max Pro M2.
Signed-off-by: Albert I <kras@raphielgang.org>
Change-Id: I74d07c3c3125a04962c37fe8bfcc8385d1fd3398
