Right now there are two bootconfig parsers that gets linked into `init`.
One is from libinit itself and the other is from libfs_mgr.
The one in libinit removes all space characters between list elements,
so `key = "val1", "val2"` gets unquoted and squeezed into:
`key=val1,val2`
The one in libfs_mgr doesn't remove spaces, it only unquotes:
`key=val1, val2`
The libinit behavior is due to existing systems (such as sysprop)
expect the config value to be in the same format as kernel cmdline.
(aosp/1757971)
THe libfs_mgr behavior is due to the `androidboot.boot_device[s]`
format explicitly allows quoted comma appear in its list value, thus
relies on space, not comma, as the list value delimeter.
This commit merges the two parsers into libfs_mgr. Since all usages in
libfs_mgr besides `boot_device[s]` do not care about how list value are
delimited, and most usages in init expects the bootconfig value format
to be the same format as cmdline. We just special case the
`boot_device` scenario.
Also harden the test cases to cover all the different config value
format and expected result.
Note:
The format of kernel bootconfig is described here
https://docs.kernel.org/admin-guide/bootconfig.html
Bug: 293695109
Test: CtsFsMgrTestCases
Change-Id: I42b9bf626e8de38a60e8e09fac0693126b7efd91
init and libfs_mgr both defines get_android_dt_dir() with subtle
differences. Merge the two implementations into libfs_mgr to reduce code
duplication (in terms of source code and code gen)
Note:
init's implementation checks the kernel cmdline first and then the
kernel bootconfig, while libfs_mgr's order is the opposite.
Realistically I don't think this order matter much though. If any, we
should prioritize bootconfig over kernel cmdline most of the time.
Bug: 293695109
Test: Presubmit
Merged-In: Ic8d2c965c62f9e873ccdaf77d67c7708f25a7b56
Change-Id: Ic8d2c965c62f9e873ccdaf77d67c7708f25a7b56
The DebugRebootLogging() function was introduced to help with
root-causing b/150863651. Remove this function since this logging
functionality is no longer needed. Also remove the functions and methods
that are only used by DebugRebootLogging().
Change-Id: Ia150604c6cd70f42b13d655ba43b95445a55b6e2
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Persistent properties are flushed with fsync which can cause the
non-persistent property write path to block.
Bug: 250125146
Test: manual test with ro.property_service.async_persist_write = true
Change-Id: Id123bfc7de948b76c51b4d98d00c8cb4a0850bf1
From the unique_fd.h header file: "unique_fd's operator int is
dangerous, but we have way too much code that depends on it, so make
this opt-in at first."
From the Google C++ style guide: "Do not define implicit conversions."
See also go/cstyle#Implicit_Conversions.
Hence this CL that disables unique_fd::operator int().
Change-Id: I28d94755d5408f63e5819da8d1cbc285057f867f
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Simplify PollIn() by converting a single-element array into a scalar. No
functionality is changed.
Change-Id: I3ef36b9c0daafeed3a92f90c7a7c4fe0654dd586
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Invoke the callback functions from inside Epoll::Wait() instead of
returning a vector with pointers to callback functions. Remove handlers
after handler invocation finished to prevent that self-removal triggers
a use-after-free.
The CL that made Epoll::Wait() return a vector is available at
https://android-review.googlesource.com/c/platform/system/core/+/1112042.
Bug: 213617178
Change-Id: I52c6ade5746a911510746f83802684f2d9cfb429
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Review note: Original change was a p-o-c by agl in
https://r.android.com/2094350 which I think is actually
production quality. I'm just taking it over so that he doesn't
get spammed by any review comments as that's not a good use
of his time.
Needed for the hardware entropy daemon (see bug).
Original commit message:
If one needs to create a service that synchronously starts listening on
a socket then there are currently no good options.
The traditional UNIX solution is to have the service create the socket
and then daemonise. In this situation, init could start the service with
`exec_start` and yet not block forever because the service forks and
exits. However, when the initial child process exits, init kills the
daemon process:
> init: Killed 1 additional processes from a oneshot process group for
> service 'foo'. This is new behavior, previously child processes
> would not be killed in this case.
Next, there is a `socket` option for services and (although the
documentation didn't nail this down), the socket is created
synchronously by `start`. However, init doesn't call `listen` on the
socket so, until the service starts listening on the socket itself,
clients will get ECONNREFUSED.
This this change adds a `+listen` option, similar to `+passcred` which
allows a socket service to reliably handle connections.
Bug: 243933553
Test: Started prng_seeder from init using the new listen flag
Change-Id: I91b3b2b1fd38cc3d96e19e92b76c8e95788191d5
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
