| commit | fd57f0bafc90ec80785fd146664dcaac1fbf78aa | [log] [tgz] |
|---|---|---|
| author | Tom Marshall <tdm.code@gmail.com> | Fri Jan 04 14:37:31 2019 -0800 |
| committer | Nick Reuter <nreuter85@gmail.com> | Sat Mar 16 19:09:10 2024 -0500 |
| tree | 442e089af2b95833826bbfe2a85b158c5772e705 | |
| parent | 915b13f5babbee92cbf47f52307e453da04282bb [diff] |
recovery: Implement a volume manager
This is a copy of the pre-binderized vold which has been converted to
use direct calls instead of sockets and stripped down to only what is
needed to support recovery.
Includes:
* recovery: volmgr: remove unused IsSupported
Change-Id: If8206658fdfb6108221806c09c99bf0a30f4a586
Signed-off-by: Jesse Chan <jc@lineageos.org>
* recovery: volmgr: remove filesystem checks
Those checks are not strictly necessary and we are
not building fsck tools for recovery for now.
Remove those checks so volmgr can be useful.
Change-Id: I87756c61b933b6cdccd281c6276b686fbd36019f
Signed-off-by: Jesse Chan <jc@lineageos.org>
* recovery: fixup `EmulatedVolume creating`
Avoid dangling pointer. Instead of pointing to FstabEntry create copy.
Change-Id: I57f76006db09a6add2c173f43175f0f6b848d87b
* recovery: fix volmgr cleaning up
Don't reset pointer to netlink manager
Delete disks in stop() rather then in ~VolumeManager
Call destroy() before deleting disks cause delete expects the
disk to be destroyed
Clear the lists or we would read garbage data on the next scan
Change-Id: Idadfa1f33b7cb5f2f3c780848a99344a6608420e
* recovery: handle interrupts in apply update menu
Change-Id: I1f78f9196634353b77986545332d7d52a5f0c161
Change-Id: Ic82d929e052b5ba70ecf7b475e0a223d77d9687e
recovery: fix applying updates
We need to break after applying from either ADB or Storage to return
the status of the installation.
Otherwise the log is stuck until you press on the back arrow, you
are able to start sideload multiple times and other shenanigans.
Change-Id: I06c9dcf6161dd1a0199417cfed2465914837d795
Signed-off-by: Alexander Martinz <amartinz@shiftphones.com>
Devices using recovery-as-boot (e.g. Pixels, which set BOARD_USES_RECOVERY_AS_BOOT)
# After setting up environment and lunch. m -j bootimage adb reboot bootloader # Pixel devices don't support booting into recovery mode with `fastboot boot`. fastboot flash boot # Manually choose `Recovery mode` from bootloader menu.
Devices with a separate recovery image (e.g. Nexus)
# After setting up environment and lunch. mm -j && m ramdisk-nodeps && m recoveryimage-nodeps adb reboot bootloader # To boot into the new recovery image without flashing the recovery partition: fastboot boot $ANDROID_PRODUCT_OUT/recovery.img
# After setting up environment and lunch. mmma -j bootable/recovery # Running the tests on device (under normal boot). adb root adb sync data # 32-bit device adb shell /data/nativetest/recovery_unit_test/recovery_unit_test # Or 64-bit device adb shell /data/nativetest64/recovery_unit_test/recovery_unit_test
recovery-refresh and recovery-persist executables exist only on systems without /cache partition. And we need to follow special steps to run tests for them.
Execute the test on an A/B device first. The test should fail but it will log some contents to pmsg.
Reboot the device immediately and run the test again. The test should save the contents of pmsg buffer into /data/misc/recovery/inject.txt. Test will pass if this file has expected contents.
adb under recoveryWhen running recovery image from debuggable builds (i.e. -eng or -userdebug build variants, or ro.debuggable=1 in /prop.default), adbd service is enabled and started by default, which allows adb communication. A device should be listed under adb devices, either in recovery or sideload state.
$ adb devices List of devices attached 1234567890abcdef recovery
Although /system/bin/adbd is built from the same code base as the one in the normal boot, only a subset of adb commands are meaningful under recovery, such as adb root, adb shell, adb push, adb pull etc. Since Android Q, adb shell no longer requires manually mounting /system from recovery menu.
adb devices doesn't show the device.$ adb devices List of devices attached
adbd is built and running.By default, adbd is always included into recovery image, as /system/bin/adbd. init starts adbd service automatically only in debuggable builds. This behavior is controlled by the recovery specific /init.rc, whose source code is at bootable/recovery/etc/init.rc.
The best way to confirm a running adbd is by checking the serial output, which shows a service start log as below.
[ 18.961986] c1 1 init: starting service 'adbd'...
If adbd service has been started but device not shown under adb devices, use lsusb(8) (on host) to check if the device is visible to the host.
bootable/recovery/etc/init.rc disables Android USB gadget (via sysfs) as part of the fs action trigger, and will only re-enable it in debuggable builds (the on property rule will always run after on fs).
on fs
write /sys/class/android_usb/android0/enable 0
# Always start adbd on userdebug and eng builds
on property:ro.debuggable=1
write /sys/class/android_usb/android0/enable 1
start adbd
If device is using configfs, check if configfs has been properly set up in init rc scripts. See the example configuration for Pixel 2 devices. Note that the flag set via sysfs (i.e. the one above) is no-op when using configfs.
adb devices shows the device, but in unauthorized state.$ adb devices List of devices attached 1234567890abcdef unauthorized
recovery image doesn't honor the USB debugging toggle and the authorizations added under normal boot (because such authorization data stays in /data, which recovery doesn't mount), nor does it support authorizing a host device under recovery. We can use one of the following options instead.
For debuggable builds, an RSA keypair can be used to authorize a host device that has the private key. The public key, defined via PRODUCT_ADB_KEYS, will be copied to /adb_keys. When starting the host-side adbd, make sure the filename (or the directory) of the matching private key has been added to $ADB_VENDOR_KEYS.
$ export ADB_VENDOR_KEYS=/path/to/adb/private/key $ adb kill-server $ adb devices
-user builds filter out PRODUCT_ADB_KEYS, so no /adb_keys will be included there.
Note that this mechanism applies to both of normal boot and recovery modes.
adbd to connect without authentication.ro.boot.verifiedbootstate is orange) or debuggable build.ro.adb.secure has a value of 0.Both of the two conditions need to be satisfied. Although ro.adb.secure is a runtime property, its value is set at build time (written into /prop.default). It defaults to 1 on -user builds, and 0 for other build variants. The value is overridable via PRODUCT_DEFAULT_PROPERTY_OVERRIDES.
The recovery image supports localization of several background texts, e.g. installing, error, factory reset warnings, etc. For devices using xxhdpi and xxxhdpi, the build system generates these localization images dynamically since android-10 when building the recovery image. While the static images under res-*dpi/images/ is used for other display resolutions and as a backup.
Check the invocation of the image_generator tool in the makefile. And the detailed usage of the image_generator is documented here.