- 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
osm0sis