- boot_img_hdr_v3 now has dtb stored in a new partition called vendor_boot
- allow block=vendor_boot partition detection
- support current practice of Image* and dtb in zip root by automatically creating a multi-partition AK3 zip setup from these files (ramdisk directory is assumed to be for the boot partition)
- fix reset_ak current files cleanup
- unpackbootimg/unpackelf kernel+ramdisk suffixes were corrected to match their corresponding mkbootimg argument in my latest forked tools (AIK-mobile v3.8)
- fix repack from unpackelf to mkbootimg broken base value introduced with AK3 rewrite
- touch up a couple pesky minor things
- add global scope to replace_line and remove_line so they match replace_string, and can now work on all matches found in a file
- remove unnecessary slot swapping since this is already handled with $POSTINSTALL and FlashAfterUpdate addon.d-v2's setup
- add cache mounting into main functions
- rename slot function to bring in line with my other projects
- don't rely on props if possible: determine dynamic/logical partitions from /dev/block/mapper presence, and detect slots more robustly using props and cmdline as in AK3 Core
- fix opposite slot detection for pushing modules to system and/or vendor during addon.d-v2
- fix naming BootSignature_Android.jar -> boot_signer-dexed.jar for my own builds (see https://issuetracker.google.com/issues/143810860)
- correct unpackbootimg/unpackelf suffixes which now correspond to their matching mkbootimg argument
- only do setup_env and restore_env when in recovery to prevent environment/mount issues post-install
- use busybox [ for simple integer test to ensure known numerical operator behavior
- Lineage 17 Recovery has some problems currently: /system mountpoint in ramdisk, neither /system nor /system_root in fstab (it has / instead, which is useless), ANDROID_ROOT=/system, and no /system_root symlink
- /etc is linked to /system/etc so once /system is mounted /etc/fstab is gone and no further simple mount commands will work so move other mounts before /system
- /system/bin are the only utilities available on PATH with none at all in /sbin so we need /apex files mounted immediately or no non-busybox commands will work after mounting /system over the recovery's skeleton /system
- not all devices have /dev/block/bootdevice symlinks, but at some point "broken recovery is broken" has to apply, so I don't intend to build out full system partition discovery for the SAR mount fallback
- for A/B OTAs my FlashAfterUpdate addon.d script requires the zip to know about addon.d-v2 and act accordingly
- signify support with #FLASHAFTERUPDATEV2 tag in updater-script to pass whitelist check since the majority of zips will not work correctly
- Lineage has a mindboggling: /system_root as mountpoint in ramdisk, neither /system nor /system_root in fstab (it has / instead, which is useless), ANDROID_ROOT=/system, and a possible symlink from /system to /system_root/system
- this failure to have a sensible, working fstab triggers the fallback to mounting directly from /dev/block/bootdevice which should exist on all modern devices which would need this SAR fallback
- add basic slot support for the fallback mount, since Lineage Recovery also doesn't make symlinks to the active slot partitions
TWRP now has 3(!) different competing implementations of SAR currently in use by maintainers:
1) /system as mountpoint in ramdisk/fstab and ANDROID_ROOT=/system, and possible symlink from /system_root to /system
2) /system_root as mountpoint in ramdisk/fstab, ANDROID_ROOT=/system_root, and possible symlink from /system to /system_root/system
3) /system_root as mountpoint in ramdisk/fstab, ANDROID_ROOT=/system, and possible symlink from /system to /system_root/system
Attempt to continue to accommodate this bullshit.
osm0sis