If booting with debug ramdisk (ro.force.debuggable is true), override
the persistent property "persist.sys.usb.config" to always enable adb.
This ensures a consistent debug experience. The developer can expect
that after debug ramdisk (debug boot image) is flashed,
1. Device is rootable with (adb root)
2. adb is enabled automatically
3. no-auth (if $ADB_VENDOR_KEYS is used)
Bug: 223517900
Test: 1. Flash & boot user build, verify device doesn't have usb
debugging enabled.
2. Reboot to bootloader and flash vendor_boot-debug.img.
3. Boot and verify usb debugging is automatically enabled.
4. Enter Developer Options and manually turn off usb debugging.
5. Reboot and verify that usb debugging is automatically enabled.
Change-Id: I729e961d645f2dd521ead8ca30b5cb8eb1d9f909
Some partitions may not have build.prop files (and it's totally fine).
Rather than logging such failures as WARNING, load_property_from_file
now returns a Result<void> object so callers can manually log for
themselves.
Bug: 228389036
Test: boot and logcat
Change-Id: Ia4ad7eef34d572182a3f6e86547664ae31dfd29f
Non-GRF devices must read only the `ro.product.first_api_level` but
not the vendor build version because `ro.product.first_api_level` is
always less than or equal to `ro.vendor.build.version.sdk` for
non-GRF devices.
Bug: 218610653
Test: getprop ro.vendor.api_level
Change-Id: Ib98c33ae052daa949208c43bd441f98cf442da49
[reland aosp/1910032]
Updatable sepolicy is shipped within an zip within an APEX. Because
it needs to be available before Apexes are mounted, apexd copies
the zip from the APEX and stores it in /metadata/sepolicy. If there is
not updatable sepolicy in /metadata/sepolicy, then updatable policy is
loaded from /system/etc/selinux/apex. Init performs the following
steps on boot:
1. Validates the zip by checking its signature against a public key
that is stored in /system/etc/selinux.
2. Extracts files from zip and stores them in /dev/selinux.
3. Checks if the apex_sepolicy.sha256 matches the sha256 of
precompiled_sepolicy. if so, the precompiled sepolicy is used.
Otherwise, an on-device compile of the policy is used. This is the
same flow as on-device compilation of policy for Treble.
4. Cleans up files in /dev/selinux which are no longer needed.
5. Restorecons the remaining files in /dev/selinux.
6. Sets selinux into enforcing mode and continues normal booting.
Bug: 199914227
Test: adb root
adb shell cp /apex/com.android.sepolicy.apex/etc/SEPolicy-33.zip \
/metadata/sepolicy/SEPolicy.zip
adb shell cp /apex/com.android.sepolicy.apex/etc/SEPolicy-33.zip.sig \
/metadata/sepolicy/SEPolicy.apk.sig
adb shell cp /apex/com.android.sepolicy.apex/etc/SEPolicy-33.zip.fsv_sig \
/metadata/sepolicy/SEPolicy.zip.fsv_sig
adb reboot
ls -laZ /dev/selinux/
Verify that files exist and that the labels are expected.
Change-Id: I2dbe43e329e91f46abedc7e44f7d24b220e19173
"nonplat" was renamed to "vendor" in Android Pie, but was retained
here for Treble compatibility.
We're now outside of the compatbility window for these devices so
it can safely be removed.
While I'm here, improve accuracy of some comments and
in-code-documentation.
Test: build boot cuttlefish device. adb remount, modify
/system/etc/selinux/plat_sepolicy_and_mapping.sha256 to force
on-device policy compilation. reboot. Verify that device boots
without new selinux denials.
Change-Id: Ibe5c5fa1ea206c1b4d5ad8183433c332a8aaadbf
ro.vendor.api_level must be the minimum of ro.product.first_api_level
and ro.board.(first_)api_level.
Bug: 202919753
Test: getprop ro.vendor.api_level
Change-Id: Ie70dd64b21c01ed8cd5e43b01095e1e0d8ff4444
ro.vendor.api_level will have the api_level that the vendor images
are required to implement based on the various api level properties.
ro.board.api_level and ro.board.first_api_level explicitly states
the api level of the vendor images for grf.
If these properties are not provided, it reads the device's launching
api level.
The rest of the properties may show the implemented api level of the
vendor images.
Bug: 200258600
Test: getprop ro.vendor.api_level
Change-Id: Id4131b53d6db00d5bbef3b048384d33c1736d681
This reverts commit 0a799bdfd6.
Now that the kernel bootconfig feature has been to updated to handle
mixed subkeys and values, androidboot.hardware parameter is supported.
Test: build and boot Cuttlefish with "androidboot.hardware=cutf_vm"
Bug: 191502832
Change-Id: I0e436a27730d20689bc6974562c3e88d744385db
Background in http://go/compatible-build-fingerprint. To uniquely
identify the mixed build, we plan to append the unique vbmeta digest
to ro.build.id.
If BOARD_USE_VBMETA_DIGTEST_IN_FINGERPRINT is true, the build system
will not set ro.build.id. Instead, init will set it at runtime, by
appending the digest to the legacy build id.
Bug: 186786987
Test: build and boot a device with new build id
Change-Id: Idea57df599bfd6eede760671e2555541f7dc3f21
emulator migrated to bootconfig, we don't use
the kernel command line to pass userspace properties.
Bug: 182291166
Test: boot
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Iff2f627aec64b7ba2240444639acedc76a1aa806
The existing code has a lot of references to the
`ro.boot.qemu` and `ro.boot.qemu.something` properties
which is not supported by the bootconfig if we place
everything under `androidboot.qemu`.
Bug: 182291166
Test: getprop | grep qemu
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Icb9d29c8dc39e1fa52a6f2ce43b4f42182b7995d
emulator passes `android.checkjni` in the kernel
command which we want to use in
frameworks/base/core/jni/AndroidRuntime.cpp
Bug: 182291166
Test: getprop ro.boot.dalvik.vm.checkjni
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: If9473aa9492fa09d8de7cc8fb08614380e4e15f3
emulator passes `android.bootanim=0` in the kernel
command line to disable boot animation.
Bug: 182336906
Test: boot emulator with -np-boot-anim
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Id89a6c92dd4724cac414ffbf8ee731b2bfcc7195
The emulator migrated to `ro.boot.qemu`.
Bug: 182291166
Test: presubmit
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Iaa3bdff5cc1efa79c21ae2dc2bdf7ec74731f66c
`ro.kernel.` is an emulator specific prefix.
Bug: 182291166
Test: presubmit
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Ie4a19127f05f3074ccb02bd055711e9b70702ba6
The parameter "androidboot.hardware" has been removed from bootconfig
and replaced by "hardware" parameter.
Test: launch_cvd with 4.19 and 5.10 kernels
Test: atest CtsFsMgrTestCases
Bug: 173815685
Change-Id: I627426ae1bd0a165b70b8f2584ec184abfb4236f
Androidboot parameters are being moved from the kernel commandline to
bootconfig.
fs_mgr looks for these parameters in properties and falls back to
reading directly from /proc/cmdline. So both of these sources are
updated for bootconfig.
The androidboot parameters from /proc/bootconfig
are added as ro.boot properties, and fs_mgr will fall back to searching
/proc/bootconfig if it is too early.
Test: boot cuttlefish with androidboot.fstab_suffix and
androidboot.hardware in bootconfig and not in cmdline.
Test: atest CtsFsMgrTestCases
Bug: 173815685
Change-Id: Iea36a0da94c26e1aa37d97c576725e0ad77cd3ad
After Treblized, AOSP do not handle /factory folder. Also, AOSP
does not mount any partition to /factory. /factory has no possibility
to have any content. For factory purpose, it can be implemented in
vendor.
Bug: 177280838
Test: na
Change-Id: I0a2537336c2ef1efbad3e4f9e876aeaa607bc737
Basically, ro.product.cpu.abilist* are defined by
ro.vendor.cpu.abilist*. And they can be overried by
ro.odm.cpu.abilist* and ro.product.cpu.abilist*.
ro.system.cpu.abilist* are for fallback if others are no defined.
Bug: 176520383
Test: check the result by flashing aosp_arm64-userdebug on
Test: aosp_blueline-user and aosp_blueline-user hacked by
Test: 64-bits-only
Change-Id: I01ae01af099a4ec8fe3d4525edecc233a477ff60
This change does the following:
- Create /second_stage_resources empty dir at root.
- At runtime:
- At first stage init:
- mount tmpfs to /second_stage_resources.
- Copy /system/etc/ramdisk/build.prop to
/second_stage_resources/system/etc/ramdisk/build.prop
- At second stage init:
- Load prop from the above path
- umount /second_stage_resources
Test: getprop -Z
Test: getprop
Bug: 169169031
Change-Id: I18b16aa5fd42fa44686c858982a17791b2d43489
The ro.build.version.release property was changed from being the
codename or final name of the current release to be the final name
of the most recent release. Use ro.build.version.release_or_codename
to reconstruct the fingerprint to match what the build system does.
Bug: 158483506
Test: adb shell getprop | grep fingerprint
Change-Id: I3bd992b6f06ff90bb6024253339a2654afa069ee
Load sysprops from /odm_dlkm/etc/build.prop. Note that no
property contexts are loaded from odm_dlkm.
Test: getprop | grep odm_dlkm
Bug: 156020364
Change-Id: I90c3a54a110462736d9888101d4281100d586632
Load sysprops from /vendor_dlkm/build.prop. Note that
no property contexts are loaded from vendor_dlkm.
Test: getprop | grep vendor_dlkm
Bug: 156020364
Change-Id: Ib0e8ba1791e1d2c11d055ef496208993e11d9b0f
build.prop files under system_ext, product, and odm partitions are moved
to the ./etc subdirectory. This is to be in-line with the established
practice of having all configuration files under ./etc subdir.
build.prop doesn't need to be an exception.
However, system/build.prop and vendor/build.prop were not moved because
there are a lot of apps and tools that depend on the path.
Bug: 158735147
Test: device has build.prop under ./etc and is bootable
Change-Id: I26300574c23c78cc4e5bc20f98fc9702838465e1
Regardless of whether a system property is "ro." or not, it can be
overridden by build.prop from the more specific partition. i.e.
foo.bar=true in system/build.prop can be overridden by
foo.bar=false in vendor/build.prop. However, the warning message
was referring the overridden property as "ro." causing confusion
when reading the log. Fix it by not mentioning "ro.".
Bug: 117892318
Test: N/A
Change-Id: I13014522d0c6b507b30c8754e2087fd71cc39971
The file is removed. init no longer needs to read it.
Bug: 117892318
Test: TH passes on non-Treble devices.
Change-Id: Idc4127bad66db24c7033b47c41b9eb85a5e0a5cd
Contents that were in /system/etc/prop.default are now in
/system/build.prop.
The content is placed at the top of build.prop to keep the existing
order between the two files.
Caveat #1: /prop.default still remains for non-Treble devices.
Caveat #2: ReadFileSymbolicLink test was changed to read /system/bin/ps
because /prop.default is no longer guaranteed to exist.
Bug: 117892318
Test: TH passes
Test: inspect /system/build.prop and check if it has contents from
the old /system/etc/prop.default file
Change-Id: I0d3f96c1656dfe02bfa0e801680f7fa887afd1d9
It is merged to /vendor/build.prop. However, for backwards
compatibility, the old file is read on devices running R or earlier.
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: I994cc85fc0765bc9233e9799bcb670a23180f068
Previously, after `adb reboot userspace` is called on a device that
doesn't suppor it, init would've logged an error and quietly exit the
shutdown sequence. This was leaving adb handing forever.
With this approach, init will fail setprop
"sys.powerctl=reboot,userspace" in case userspace reboot is not
supported.
Test: adb root
Test: adb setprop init.userspace_reboot.is_supported 0
Test: adb reboot userspace
Test: atest CtsInitTestCases
Bug: 146639622
Change-Id: I1264078f53ed3ff54638c7f3b6846b7437f98ee5
Userspace reboot resets sys.powerctl to an empty string once it
starts, which was inadvertently triggering the backtrace of the main
init thread.
Test: no more unexpected backtraces
Change-Id: I35d6f1b37aa31a46ae9266647f41a709f28b6099
Bug: 150863651
Test: add delays during critical parts of shutdown and see the
expected debug information
Change-Id: Ida586903fd3eefc32ca9ee34ea2db037896ed9f4
A previous change moved property_service into its own thread, since
there was otherwise a deadlock whenever a process called by init would
try to set a property. This new thread, however, would send a message
via a blocking socket to init for each property that it received,
since init may need to take action depending on which property it is.
Unfortunately, this means that the deadlock is still possible, the
only difference is the socket's buffer must be filled before init deadlocks.
This change, therefore, adds the following:
1) A lock for instructing init to reboot
2) A lock for waiting on properties
3) A lock for queueing new properties
A previous version of this change was reverted and added locks around
all service operations and allowed the property thread to spawn
services directly. This was complex due to the fact that this code
was not designed to be multi-threaded. It was reverted due to
apparent issues during reboot. This change keeps a queue of processes
pending control messages, which it will then handle in the future. It
is less flexible but safer.
Bug: 146877356
Bug: 148236233
Bug: 150863651
Bug: 151251827
Test: multiple reboot tests, safely restarting hwservicemanager
Change-Id: Ice773436e85d3bf636bb0a892f3f6002bdf996b6
This is apparently causing problems with reboot.
This reverts commit 7205c62933.
Bug: 150863651
Test: build
Change-Id: Ib8a4835cdc8358a54c7acdebc5c95038963a0419
Prevent appending ",adb" to persist.sys.usb.config if "none" is
explicitly defined in default prop.
Bug: 150130503
Test: persist.sys.usb.config initalized correctly
Change-Id: I3b5de6fd102e252019e843f39f0875f5aaea7486
Merged-In: I3b5de6fd102e252019e843f39f0875f5aaea7486
A previous change moved property_service into its own thread, since
there was otherwise a deadlock whenever a process called by init would
try to set a property. This new thread, however, would send a message
via a blocking socket to init for each property that it received,
since init may need to take action depending on which property it is.
Unfortunately, this means that the deadlock is still possible, the
only difference is the socket's buffer must be filled before init deadlocks.
There are possible partial solutions here: the socket's buffer may be
increased or property_service may only send messages for the
properties that init will take action on, however all of these
solutions still lead to eventual deadlock. The only complete solution
is to handle these messages asynchronously.
This change, therefore, adds the following:
1) A lock for instructing init to reboot
2) A lock for waiting on properties
3) A lock for queueing new properties
4) A lock for any actions with ServiceList or any Services, enforced
through thread annotations, particularly since this code was not
designed with the intention of being multi-threaded.
Bug: 146877356
Bug: 148236233
Test: boot
Test: kill hwservicemanager without deadlock
Change-Id: I84108e54217866205a48c45e8b59355012c32ea8
