- revert logic changes introduced by ec8fffe61c which break find_boot_image on NAND devices and any others using non-standard naming supported by the A-only device boot partition name list
- despite being accepted equivalents in modern shells -n does not work on Android in some shell/env scenarios where ! -z always does
Distribute Magisk directly with Magisk Manager APK. The APK will
contain all required binaries and scripts for installation and
uninstallation. App versions will now align with Magisk releases.
Extra effort is spent to make the APK itself also a flashable zip that
can be used in custom recoveries, so those still prefer to install
Magisk with recoveries will not be affected with this change.
As a bonus, this makes the whole installation and uninstallation
process 100% offline. The existing Magisk Manager was not really
functional without an Internet connection, as the installation process
was highly tied to zips hosted on the server.
An additional bonus: since all binaries are now shipped as "native
libraries" of the APK, we can finally bump the target SDK version
higher than 28. The target SDK version was stuck at 28 for a long time
because newer SELinux restricts running executables from internal
storage. More details can be found here: https://github.com/termux/termux-app/issues/1072
The target SDK bump will be addressed in a future commit.
Co-authored with @vvb2060
now on addon while flashing recovery usign mount point /system_root by which this is causing a flashing error.
Let's first check and unmount /system_root if mounted
Signed-off-by: Mohd Faraz <androiabledroid@gmail.com>
- the strings fallback was broken when the preceding character changed from 5 to ! recently, this new regex should cover any preceding character going forward
If we assign the execution output directly it will fail (tested on Android 11):
pdx201:/ # INSTALLER=/data/adb/magisk_install /data/adb/magisk_install/flash_script.sh
/data/adb/magisk_install/flash_script.sh[31]: typeset: -o: is not an identifier
Because:
local cmds=$($bb sh -o standalone -c "
for arg in \$(tr '\0' '\n' < /proc/$$/cmdline); do
if [ -z \"\$cmds\" ]; then
# Skip the first argument as we want to change the interpreter
cmds=\"sh -o standalone\"
else
cmds=\"\$cmds '\$arg'\"
fi
done
echo \$cmds")
/system/bin/sh: typeset: -o: is not an identifier
Signed-off-by: Pablo Mendez Hernandez <pablomh@gmail.com>
Previously, Magisk uses persist or cache for storing modules' custom
sepolicy rules. In this commit, we significantly broaden its
compatibility and also prevent mounting errors.
The persist partition is non-standard and also critical for Snapdragon
devices, so we prefer not to use it by default.
We will go through the following logic to find the best suitable
non-volatile, writable location to store and load sepolicy.rule files:
Unencrypted data -> FBE data unencrypted dir -> cache -> metadata -> persist
This should cover almost all possible cases: very old devices have
cache partitions; newer devices will use FBE; latest devices will use
metadata FBE (which guarantees a metadata parition); and finally,
all Snapdragon devices have the persist partition (as a last resort).
Fix#3179
- LOS Recovery can't decrypt or even mount /data, thus the installer can't do everything it needs to do and must abort, so also suggest uninstall via Manager at that point
- fix removal of addon.d script when uninstall is run via Manager on SAR
- fix removal of addon.d with dynamic/logical partitions via mapper
- Do not attempt to patch DTB anywhere outside of boot images as they
are no longer essential. This makes Magisk installation to only modify
strictly boot/recovery partitions again.
- The only required patch for DTB is to strip verity out of partitions
- /vendor is used only on some older devices for recovery AVBv1 signing so is not critical if fails
- this fixes installation in Lineage Recovery on some older devices where /vendor is actually by-name partitions like oem, cust (or even cache), which likely also don't require the AVBv1 signing
- bugged TWRPs were filling persist with recovery logs, so clean those as a potential workaround
- abort module install if sepolicy.rule fails to copy, since 99% of the time the module wouldn't include it if it could function without it
Closes#2461
