[Magisk] badabing2003:
I'm not sure why you're saying that solutions like PF are expectedly affected.

PF never uses recovery, (has never used it either).

PF always creates patches on a booted system.

Likewise no recovery.zip in PF, and in fact patch_boot.sh script, if attempted to run on a mismatched device, PF will warn you, so patches are created on the device that would use them.

That's the thing, PF always does patching clean boot image in app and then flashing in fastboot.

I don't get greeted with reinstall dialogue unless I'm doing odd things like flashing full factory with wipe and root in one shot, and Magisk app is not installed, or if I'm mismatching boot image with Magisk app.

Perhaps you're not that familiar with the internals of PF operation.

Consider two scenarios,

Already patched and functional system, that needs to be upgraded to the next firmware release.

Clean system with no Magisk installed.

Already patched

To upgrade to next release, PF uses /data/magisk/patch_boot.sh (unless a newer Magisk app than the boot version is installed, more on this below), and can only use that while the system is booted and running, I see no difference and expect no difference in creating a patch in UI (other than figuring out the flags the same way the UI is doing it, hence why my previous post). Whether you create a patch in UI or using boot_patch.sh, the process to update / apply is through fastboot and not recovery.

Clean system (not rooted)

PF installs Magisk of choice (has UI to select the various Magisk apps available).

PF figures out the installed app path, and unpacks into /data/local/tmp, and sets up an environment similar to what would be found in /data/magisk

Example script that is run to do this:

#!/system/bin/sh
##############################################################################
# PixelFlasher 4.8.2.0 patch script using Magisk Manager d0c93842:26101
##############################################################################
ARCH=arm64-v8a
cp /data/app/~~IR3Y1CtT9xQazXgxR2Uhkw==/com.topjohnwu.magisk-lPsIhzPfraF1gs860uyN8Q==/base.apk /data/local/tmp/pf.zip
cd /data/local/tmp
rm -rf pf
mkdir pf
cd pf
../busybox unzip -o ../pf.zip
cd assets
for FILE in ../lib/$ARCH/lib*.so; do
NEWNAME=$(echo $FILE | sed -En 's/.*\/lib(.*)\.so/\1/p')
cp $FILE $NEWNAME
done
cp ../lib/armeabi-v7a/libmagisk32.so magisk32
chmod 755 *
export KEEPVERITY=true
export KEEPFORCEENCRYPT=true
./magiskboot cleanup
./boot_patch.sh /sdcard/Download/boot.img_07815117.img
cp -f /data/local/tmp/pf/assets/new-boot.img /sdcard/Download/magisk_patched_07815117.img

PF creates patch using patch_boot.sh from the above created setup

The created patch is pulled and later flashed with fastboot

Neither method does get prompted to continue installation in Magisk after the system is rebooted.

Had this been the case, meaning that after flashing in fastboot, if one needed to continue in the app, then every guide out there needed to be updated to include that step.

If Magisk app is newer than the core Magisk that is running.

PF detects this and offers a choice of patching, either use the current patch_boot.sh in /data/Magisk, or unpack the newer Magisk and use that to create a patch, basically a choice between the two modes above.

I'm not worried that PF has or will have issues with the latest versions of Magisk, what I'm trying to grasp is the exact logic of selecting the right flags to match what would the app UI would do.

My previous post is all about that, basically the use of the flags or applications of them have changed between versions.

I suspect prior to v26, it was broken, and it is fixed now, but I still have to prove that to avoid making the wrong assumptions.

Thanks for the references for RANDOMSEED, would you happen to know why it was needed to be added?