am skip reason: Change-Id I6fd7d3a25d3225081388e39a14c9fdab21b592ba with SHA-1 10615eb397 is in history
Change-Id: I05faca41a3d6ba5a64e7fe0d8d3e9131c91c14a4
am skip reason: Change-Id I1264078f53ed3ff54638c7f3b6846b7437f98ee5 with SHA-1 92116e4129 is in history
Change-Id: I072de643588f5d9c915ff9d6fea498c0c80f875b
Devices in the lab are hitting an issue where they're getting stuck
likely in the sync() call in DoReboot() before we start the reboot
monitor thread and before we shut down services.
It's possible that concurrent writing to RW file systems is causing
this sync() call to take essentially forever. To protect against
this, we need to remove this sync(). Note that we will still call
sync() after shutting down services.
Note that the service shutdown code has a timeout and there is a
reboot monitor thread that will shutdown the device if more than 30
seconds pass above that timeout. This change increases that timeout
to 300 seconds to give the final sync() calls explicitly more time to
finish.
Bug: 150863651
Test: reboot functions normally
Test: put an infinite loop in DoReboot and the the reboot monitor thread
triggers and shuts down the device appropriately
Merged-In: I6fd7d3a25d3225081388e39a14c9fdab21b592ba
Change-Id: I6fd7d3a25d3225081388e39a14c9fdab21b592ba
(cherry picked from commit 10615eb397)
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
Merged-In: I1264078f53ed3ff54638c7f3b6846b7437f98ee5
(cherry picked from commit 92116e4129)
am skip reason: Change-Id I7552d5ccc6e9b750a6081947eef8fcb027be13e1 with SHA-1 663cd35030 is in history
Change-Id: Iea491137db1f9dd047c3d82ecc6f97d83e860712
This should help in debugging issues related to the mismatch between
actual last reboot reason property and the expected one (see attached
bug).
Test: adb reboot
Test: adb logcat | grep bootstat
Bug: 152900920
Change-Id: I085cf1fb80a30389fd3ba821d40b6111a3294d95
If the value of androidboot.boot_devices has a comma in its path, it'll
get split and /dev/block/by-name symlinks won't work. As a workaround,
add "androidboot.boot_device" as a valid command-line parameter. It can
be repeated multiple times to retain multiple-boot-device semantics.
Bug: 153024538
Test: device boots with androidboot.boot_device= set
Change-Id: I1be5aeec287ba198768c3452b1930d59b2f13463
Vendors may add additional functionfs mounts. Since these
will never be remounted, we can safely filter these out.
Bug: 153008210
Test: Test device with previously unfiltered entries.
Change-Id: I7f384b8a0ce93dd6701fe3c4d9dd2557370b31e1
General recommendation is to avoid read-only properties, and instead control
"read-onlines" by only allowing init/vendor_init to set the property.
Since ro.init.userspace_reboot.is_supported was added in this release, and
nobody outside of the platform is querying it directly, it should be fine to
simply rename it.
Test: adb shell getprop init.userspace_reboot.is_supported
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 152803929
Change-Id: I7552d5ccc6e9b750a6081947eef8fcb027be13e1
Merged-In: I7552d5ccc6e9b750a6081947eef8fcb027be13e1
(cherry picked from commit 663cd35030)
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
am skip reason: Change-Id I9f356c854833b5e68820e4d3d4e9709af1288381 with SHA-1 e580566b00 is in history
Change-Id: I68152c57f213124e286840088518056bd519d689
am skip reason: Change-Id Ie479ae2fbaf1006228a531dab26c7d535ed403db with SHA-1 3735614b28 is in history
Change-Id: I87ca144566ff9c69070f5de8b9aa86b2a8d41e0d
Devices in the lab are hitting an issue where they're getting stuck
likely in the sync() call in DoReboot() before we start the reboot
monitor thread and before we shut down services.
It's possible that concurrent writing to RW file systems is causing
this sync() call to take essentially forever. To protect against
this, we need to remove this sync(). Note that we will still call
sync() after shutting down services.
Note that the service shutdown code has a timeout and there is a
reboot monitor thread that will shutdown the device if more than 30
seconds pass above that timeout. This change increases that timeout
to 300 seconds to give the final sync() calls explicitly more time to
finish.
Bug: 150863651
Test: reboot functions normally
Test: put an infinite loop in DoReboot and the the reboot monitor thread
triggers and shuts down the device appropriately
Change-Id: I6fd7d3a25d3225081388e39a14c9fdab21b592ba
am skip reason: Change-Id I8a86bc4d12e4b3be020bbe47e02262a5aaa913a7 with SHA-1 2ffc31b090 is in history
Change-Id: Id6ae907072764761a5b51deb4aff81f7e4debb8a
