- with do.systemless prop enabled in anykernel.sh, will push the contents of modules/ to create a simple "ak3-helper" Magisk module, where testing on devices thus far shows it loads early enough that even replacement kernel object .ko modules will get loaded
- the ak3-helper module info is populated from the kernel.string and parsed kernel version from the kernel being flashed, and if at boot time a different kernel is detected the module automatically removes itself before being loaded to avoid conflicts
- since logical partitions and ext4-dedup on Android 10 now prevent mounting /system or /vendor rw under any circumstances, this feature gives kernel developers back the freedom they had before all this to improve kernel .ko modules, .conf files, etc. with the added bonus of it cleaning up after itself
- only repatch when there is an Image* (i.e. don't attempt on ramdisk-only mods)
- make sure new ramdisk is already copied before trying to detect Magisk patch state in case it changed
- clean up Magisk patch state and exported variables immediately
- work around booted flashing apps like FKM/EXKM which make /system busy to keep it from being unmounted but can't do the same with /system_root which can lead to sketchy behavior
- also check patch status as part of repack_ramdisk() to avoid any issues if developer is forcing a compression format change
- get full Magisk patch status value and extract Magisk config to export correct environment variables for dtb patching
Add apex mounting for android Q so dynamic linked binaries and libs will work during install
* Add apex stuff
* Fix minor type
* Better minor type solution
* Update update-binary
- ro.vendor.build.product (from #44) doesn't appear to actually exist in nature, so replace it with ro.product.vendor.device for API 28+ devices, per https://github.com/phhusson/vendor_hardware_overlay/issues/25
- no need to check so many props for getprop parsing fallback check, simply look for ro.build.type which all devices should have in antiquity
- add additional prop locations to getprop failure fallback
- add vendor props to devicecheck and getprop parsing fallback check to avoid false negatives on GSIs
- mask errors from devicecheck getprops as not all of them may exist on GSIs or non-GSIs
Thanks @lazerl0rd for the information and start on the changes
Closes#44
- per Chainfire, "fix slow RNG on some devices, which may cause installation to take weeks"
- it seems like this issue may have been triggered now in recovery on some devices by some of the changes from the new mounting rewrite
- use $ANDROID_ROOT variable which in TWRP is set to /system_root on properly set up SAR devices and default set it to /system
- continue to correct any issues with /system and /system_root mountpoints but backup and restore any symlinks encountered
- only mount and umount /data when it is not mounted to begin with to fix MTP issues in TWRP on some devices (thanks @Zackptg5)
- refactor tear down into restore_env() function to allow restoring original recovery environment even after abort
- add lazy umounts because let's be thorough
- remove hacky workaround to avoid /system_root umount when booted since that should be handled by flashing app now
- rename unmount_all to umount_all since it's been bugging me for a while ;)
- refactor mountpoint setup into its own function
- try mount --move first since /system should already be mounted (thanks @Zackptg5)
- refactor reused script to ui_print from files into its own function
- TWRP for some devices has /system as a symlink, some do not; apparently some weird devices have /system_root as a symlink (somehow); attempt to fix them all
- running reset_ak before an unpack would remove any included ramdisk files from zip, so only remove if $split_img is detected suggesting an unpack has already occurred
- checks the supported.patchlevels prop in anykernel.sh and matches against it to prevent users flashing incorrect kernels for patch levels
- this is possibly more important than supported.versions now since modern Android doesn't really do point releases anymore, so a patch level is more likely to signify breakage than a version change
- supported.patchlevels can be a closed or open-ended range of dates in the format YYYY-MM, e.g. "2019-04 - 2019-06", "2019-04 -" or "- 2019-06" where the last two examples show setting a minimum and maximum, respectively
- clean up device and version checks a bit while we're at it
osm0sis