Move merge_status from bootloader_control_ab, which is in vendor space,
to a new generic AOSP struct in system space. This will allow more
devices to share the same HAL implementation.
This patch also changes libboot_control to compensate for merge_status
moving out of vendor space. The reference HAL library now also provides
separate helper functions for managing the merge status, so devices
using a custom boot control HAL can still take advantage of the new misc
implementation.
Bug: 139156011
Test: manual test
Change-Id: I5cd824e25f9d07aad1476301def5cdc3f506b029
There is no reason for these scripts to continue to exist in /, when
they are better suited for /system/etc. There are problems keeping
them at / as well, particularly that they cannot be updated with
overlayfs.
Bug: 131087886
Bug: 140313207
Test: build/boot + boot to recovery
Merged-In: I1fb6690d4302a1884d8521c21a9754b2ca710d5a
Change-Id: I1fb6690d4302a1884d8521c21a9754b2ca710d5a
We used to set sys.usb.config to adb in the init script. And the purpose
is to start adbd. This is a duplicate of code because we always check and
reset the usb config in recovery_main.
Test: check adbd starts
Change-Id: I6e2842ff8aebf6ccf3bd3f2ae85323899a2b9de4
This reduces the wipe space from 32K to 16K. The wipe space is now
at the 16K-32K region. The 32K-64K region is now "system space", to
complement the vendor space, for generic AOSP usage.
Bug: 139156011
Test: manual test
Change-Id: I1474bfa65a5f21049ab64ec0aee2f4585b55f60f
During automatic tests, we sometimes want to reboot the device out of
the rescue party remotely. And per http://go/recovery-adb-access, one
option is to start adbd in user build if the device has an unlocked
bootloader. This should not add more surface of attack. Because verified
boot is off with the unlocked bootloader, and the user can always flash
a custom recovery image that always starts adbd.
Bug: 141247819
Test: check adbd doesn't start in user build, unlock bootloader, and
check adbd starts.
Change-Id: I851746245f862cb4dfb01e6c3ad035f2c9f9ccec
required doesn't propagate from apexes, so we need a separate phony
target to track adbd's dependenecies.
Test: m
Change-Id: I13977d1376de63839bf182d2cfa56b5c6c63aba9
`misc_device_` is a std::string, so it allocates and manages its own
memory. Hence, the strdup here is immediately leaked.
Caught by the static analyzer
Bug: None
Test: TreeHugger
Change-Id: Iffb1ff60f6087e470a0979d202150567272e8b1c
C++20 will require members in a designated initializer to be in order
unlike C99.
Bug: 139945549
Test: mm
Change-Id: I6f8d658448f7e5dd980bf95b890b15cb0aab7407
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
We need to run the these tests when starting updater to verify the
statically linked libcrypto. The test function is based on the known
answer tests, and it doesn't compute the hash of the libcrypto library.
Bug: 141003171
Test: unit tests pass, run a updater on cuttlefish
Change-Id: I897918a54bca76ea0c928102e7287df27505e1cc
This change is part of a topic that moves the recovery resources from the
system partition to the vendor partition, if it exists, or the vendor directory
on the system partition otherwise. The recovery resources are moving from the
system image to the vendor partition so that a single system image may be used
with either an A/B or a non-A/B vendor image. The topic removes a delta in the
system image that prevented such reuse in the past.
The recovery resources that are moving are involved with updating the recovery
partition after an update. In a non-A/B configuration, the system boots from
the recovery partition, updates the other partitions (system, vendor, etc.)
Then, the next time the system boots normally, a script updates the recovery
partition (if necessary). This script, the executables it invokes, and the data
files that it uses were previously on the system partition. The resources that
are moving include the following.
* install-recovery.sh
* applypatch
* recovery-resource.dat (if present)
* recovery-from-boot.p (if present)
This makes the applypatch executable a vendor module.
This change supports making dependencies of the applypatch executable available
to applypatch, which is now on vendor.
Since install-recovery.sh is now a vendor service, we add the
applypatch/vendor_flash_recovery.rc file to /vendor/etc/init to start the
service.
Bug: 68319577
Test: Ensure that recovery partition is updated correctly.
Change-Id: I01c0800ee6078aa6c9d716d5f154ad2d63c7af84
A number of utility functions are intended for serving recovery's own
use. Exposing them via libotautil (which is a static lib) would pass the
dependencies onto libotautil's users (e.g. recovery image, updater, host
simulator, device-specific recovery UI/updater extensions etc). This CL
finds a new home for the utils that are private to recovery.
Test: mmma bootable/recovery
Change-Id: I575e97ad099b85fe1c1c8c7c9458a5a43d4e11e1