Ship full recovery image in system

We need to ship zip images:
- to stay compatible with the current official and
  unofficial instructions for installing Replicant
- to minimize the size of the images to install with
  heimdall: on Exynos devices, the probability of
  failure to flash an image increases with the image
  size (and also with the load of the computer running
  heimdall).

To do that we can for instance use the following commands to
build a zip that can be installed with a recovery:
    source build/envsetup.sh
    lunch replicant_i9300-userdebug
    make updatepackage

However if we do that, for some reasons we have the
following build failure:
    2021-09-28 16:38:16 - common.py - WARNING : Failed to read SYSTEM/etc/build.prop
    2021-09-28 16:38:16 - common.py - WARNING : Failed to read VENDOR/etc/build.prop
    2021-09-28 16:38:16 - common.py - WARNING : Failed to read VENDOR/build.prop
    2021-09-28 16:38:16 - common.py - WARNING : Failed to read PRODUCT/etc/build.prop
    2021-09-28 16:38:16 - common.py - WARNING : Failed to read PRODUCT/build.prop
    2021-09-28 16:38:16 - common.py - WARNING : Failed to read SYSTEM_EXT/etc/build.prop
    2021-09-28 16:38:16 - common.py - WARNING : Failed to read SYSTEM_EXT/build.prop
    2021-09-28 16:38:16 - common.py - WARNING : Failed to read ODM/etc/build.prop
    2021-09-28 16:38:16 - common.py - WARNING : Failed to read ODM/build.prop
    Traceback (most recent call last):
      File "[...]/out/host/linux-x86/bin/make_recovery_patch/internal/stdlib/runpy.py", line 174, in _run_module_as_main
      File "[...]/out/host/linux-x86/bin/make_recovery_patch/internal/stdlib/runpy.py", line 72, in _run_code
      File "[...]/out/host/linux-x86/bin/make_recovery_patch/__main__.py", line 12, in <module>
      File "[...]/out/host/linux-x86/bin/make_recovery_patch/internal/stdlib/runpy.py", line 174, in _run_module_as_main
      File "[...]/out/host/linux-x86/bin/make_recovery_patch/internal/stdlib/runpy.py", line 72, in _run_code
      File "[...]/out/host/linux-x86/bin/make_recovery_patch/make_recovery_patch.py", line 67, in <module>
      File "[...]/out/host/linux-x86/bin/make_recovery_patch/make_recovery_patch.py", line 63, in main
      File "[...]/out/host/linux-x86/bin/make_recovery_patch/common.py", line 3059, in MakeRecoveryPatch
      File "[...]/out/host/linux-x86/bin/make_recovery_patch/common.py", line 2523, in ComputePatch
      File "[...]/out/host/linux-x86/bin/make_recovery_patch/common.py", line 228, in Run
      File "[...]/out/host/linux-x86/bin/make_recovery_patch/internal/stdlib/subprocess.py", line 394, in __init__
      File "[...]/out/host/linux-x86/bin/make_recovery_patch/internal/stdlib/subprocess.py", line 1047, in _execute_child
    OSError: [Errno 2] No such file or directory
    16:38:18 ninja failed with: exit status 1

    #### failed to build some targets (02:08 (mm:ss)) ####

And for some reason using BOARD_USES_FULL_RECOVERY_IMAGE
fixes that.

Without BOARD_USES_FULL_RECOVERY_IMAGE, a patch between the
boot image and the recovery image is used when "installing
the recovery image on first boot". The following commit from
build/make adds this patch based installation and so it
might give a little more background:
    commit 73ef8257ce54ce1ddc2d4cfc3b3814ca734c0e11
    Author: Doug Zongker <dougz@android.com>
    Date:   Thu Jul 23 15:12:53 2009 -0700

        use a binary patch to install recovery from system

        Instead of storing the whole recovery image in system in order to
        flash it on first boot, we instead use an imgdiff patch from the boot
        image to create the recovery image.  This is substantially smaller
        since it effectively only stores the recovery binary and UI images
        (the kernel and the init binary are identical to that of the boot
        image).

        This change modifies the OTA-building script to create and install
        these patches, and changes the calculation of the system image size in
        the Makefile to reflect the new scheme.

Here, in the boot bootimage, we are using only a kernel and
no initramfs nor recovery, so maybe it fails because we have
no initramfs in the boot bootimage.

In any case it looks way safer to only use and ship full
recovery images instead of shipping patches to existing
images, as we didn't have any procedure in the previous
Replicant versions to ensure that boot and recovery images
always stay in sync, though we still made sure that they
were in sync during the installation procedures as the
recovery checked the zip file signatures.

In any case we don't know what could break otherwise if
without BOARD_USES_FULL_RECOVERY_IMAGE both are not in sync.

We also have a tool that can patch recovery or boot images
to make adb run as root without any authentication.

While that tool isn't used to make official Replicant
images, it's often used for debugging boot issues. Without
it users not having setup adb as root won't be able to get
boot logs, and/or recover their data with Replicant
recoveries.

And here BOARD_USES_FULL_RECOVERY_IMAGE probably makes sure
to always have recovery images everywhere instead of
patches, so we're also sure not to break that use case
accidentally.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

1 files changed, 1 insertions, 1 deletions

diff --git a/BoardConfigCommon.mk b/BoardConfigCommon.mk
index f68b796..4fbbd89 100644
--- a/BoardConfigCommon.mk
+++ b/BoardConfigCommon.mk
@@ -97,7 +97,7 @@ TARGET_KERNEL_SOURCE := kernel/replicant/linux
 # Software: Recovery #
 ######################
 BOARD_RAMDISK_USE_XZ := true
-BOARD_USES_FULL_RECOVERY_IMAGE := false
+BOARD_USES_FULL_RECOVERY_IMAGE := true
 BOARD_USES_RECOVERY_AS_BOOT := false
 
 #############################