Gitiles
Code Review Sign In
review.blissroms.org / platform_bootable_recovery / 2b1a464a7045134b0980def4ea906b98ab3616f1
commit2b1a464a7045134b0980def4ea906b98ab3616f1[log] [tgz]
authorTianjie Xu <xunchang@google.com>Thu Sep 06 11:58:55 2018 -0700
committerTianjie Xu <xunchang@google.com>Thu Sep 13 13:27:55 2018 -0700
tree9a58a8c7a23b44d3ca3d2e52c12041088d777d6d
parent1254e15e5013df9c62564b37ebb86f6e023e76ae [diff]
Move the parse of last_install to recovery-persist

The recovery-persist used to look for the related recovery logs in
persist storage, and copy them under /data/misc/recovery during the
normal boot process.

As we also want to find out the sideload information from last_install,
it makes more sense to move the parse & report of non-a/b metrics to
recovery-persist. Thus we can avoid the race condition of the file
system between the native code and RecoverySystem.

Bug: 114278989
Test: unit test pass, check the event buffer for metrics report
Change-Id: I32d7b2b831bc74a61a70af9a2f0b8a7e9b3e36ee
8 files changed
tree: 9a58a8c7a23b44d3ca3d2e52c12041088d777d6d
  1. applypatch/
  2. boot_control/
  3. bootloader_message/
  4. edify/
  5. etc/
  6. fastboot/
  7. fonts/
  8. fuse_sideload/
  9. minadbd/
  10. minui/
  11. otautil/
  12. private/
  13. res-hdpi/
  14. res-mdpi/
  15. res-xhdpi/
  16. res-xxhdpi/
  17. res-xxxhdpi/
  18. tests/
  19. tools/
  20. uncrypt/
  21. update_verifier/
  22. updater/
  23. updater_sample/
  24. .clang-format
  25. adb_install.cpp
  26. adb_install.h
  27. Android.bp
  28. Android.mk
  29. asn1_decoder.cpp
  30. asn1_decoder.h
  31. bootloader.h
  32. CleanSpec.mk
  33. common.h
  34. default_device.cpp
  35. device.cpp
  36. device.h
  37. fsck_unshare_blocks.cpp
  38. fsck_unshare_blocks.h
  39. fuse_sdcard_provider.cpp
  40. fuse_sdcard_provider.h
  41. install.cpp
  42. install.h
  43. interlace-frames.py
  44. logging.cpp
  45. logging.h
  46. NOTICE
  47. OWNERS
  48. PREUPLOAD.cfg
  49. README.md
  50. recovery-persist.cpp
  51. recovery-persist.rc
  52. recovery-refresh.cpp
  53. recovery-refresh.rc
  54. recovery.cpp
  55. recovery.h
  56. recovery_main.cpp
  57. roots.cpp
  58. roots.h
  59. screen_ui.cpp
  60. screen_ui.h
  61. stub_ui.h
  62. ui.cpp
  63. ui.h
  64. verifier.cpp
  65. verifier.h
  66. vr_device.cpp
  67. vr_ui.cpp
  68. vr_ui.h
  69. wear_device.cpp
  70. wear_ui.cpp
  71. wear_ui.h
README.md

The Recovery Image

Quick turn-around testing

mm -j && m ramdisk-nodeps && m recoveryimage-nodeps

# To boot into the new recovery image
# without flashing the recovery partition:
adb reboot bootloader
fastboot boot $ANDROID_PRODUCT_OUT/recovery.img

Running the tests

# After setting up environment and lunch.
mmma -j bootable/recovery

# Running the tests on device.
adb root
adb sync data

# 32-bit device
adb shell /data/nativetest/recovery_unit_test/recovery_unit_test
adb shell /data/nativetest/recovery_component_test/recovery_component_test

# Or 64-bit device
adb shell /data/nativetest64/recovery_unit_test/recovery_unit_test
adb shell /data/nativetest64/recovery_component_test/recovery_component_test

Running the manual tests

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.

ResourceTest validates whether the png files are qualified as background text image under recovery.

1. `adb sync data` to make sure the test-dir has the images to test.
2. The test will automatically pickup and verify all `_text.png` files in
   the test dir.

Using adb under recovery

When 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 /sbin/adbd shares the same binary between normal boot and recovery images, only a subset of adb commands are meaningful under recovery, such as adb root, adb shell, adb push, adb pull etc. adb shell works only after manually mounting /system from recovery menu (assuming a valid system image on device).

Troubleshooting

adb devices doesn't show the device.

$ adb devices
List of devices attached
  • Ensure adbd is built and running.

By default, adbd is always included into recovery image, as /sbin/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'...
  • Ensure USB gadget has been enabled.

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.

  • Option 1 (Recommended): Authorize a host device with adb vendor keys.

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.

  • Option 2: Allow adbd to connect without authentication.
    • adbd is compiled with ALLOW_ADBD_NO_AUTH (only on debuggable builds).
    • 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.