For example, Lineage's com.android.ondevicepersonalization apex_manifest.pb has a # char, which strings keeps in its output, and breaks the mount for that apex before this fix
It turns out that decompressing and recompressing the kernel is enough to break booting on many devices that use MT6763.
Fix#5124, fix#6204, fix#6566
Co-authored-by: LoveSy <shana@zju.edu.cn>
Co-authored-by: 南宫雪珊 <vvb2060@gmail.com>
We resolve available partitions for sepolicy.rules when patching
boot and bind mount the partition by magiskinit.
For older devices, the previous logic won't work because the part name
is never readable.
Co-authored-by: topjohnwu <topjohnwu@gmail.com>
- /system/bin/su was being removed in error from the live system so update remove_system_su to be aware of a running A/B OTA and generalize/simplify removal logic with relative paths to correctly run on the updated system slot
Fix topjohnwu#5013
When installing from recovery, previous implementation may select f2fs partitions to store sepolicy rules, but magiskinit won't mount them and unable to load sepolicy rules.
Apparently some boot images with ramdisk still have recovery_dtbo,
so this assumption is no longer safe to do. Expect the user to
set this option properly themselves in the app.
Fix#4976, close#5070, close#5184
- ensure all scripts use $NVBASE $MAGISKBIN $POSTFSDATAD and $SERVICED where appropriate
- simplify new grep_cmdline() using xargs and more sed
- show correct active sepolicy $RULESDIR on devices with no encryption
- add support for Android 12 .capex (compressed apex) files
- expand utility of the basic module setup (zip without customize.sh) by setting more default perms, since really it couldn't do any simple binary files additions correctly withonly 0755 0644
- ensure CON stays local
Custom ROM bring-ups of legacy Sony devices contain the following:
/init (symlink to /bin/init_sony)
/init.real (the "real" Android init)
/bin/init_sony (this was /sbin/init_sony on Android <11)
Kernel loads the ramdisk and starts /init -> /bin/init_sony
/bin/init_sony does low-level device setup (see: https://github.com/LineageOS/android_device_sony_common/blob/lineage-18.1/init/init_main.cpp)
/bin/init_sony unlinks /init and renames /init.real to /init
/bin/init_sony starts /init
Since init_sony needs to run first magiskinit needs to replace init.real instead, so add workarounds based on detection of init.real to boot patcher and uninstaller
Thanks @115ek and @bleckdeth
Fixes#3636
Co-authored-by: topjohnwu <topjohnwu@gmail.com>
- revert logic changes introduced by ec8fffe61cf6c2ce66a52d9e8b33cd6e60c7ceb8 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
- try /dev/block first with full depth to catch all platform/soc variations to the by-name directory, and the new dynamic partition /dev/block/mapper
- next try uevent for block devices as before
- lastly try /dev with maxdepth 1 (immediate directory) to find /dev/bootimg, /dev/recovery, etc. while avoiding /dev/log/kernel
- move bootimg higher in the list than boot so /dev/bootimg gets found first and avoids /dev/BOOT
- recovery_a/_b now also exists
- minor touch-ups for readability and consistency
Fixes#2720
- this is needed for installations on Lineage 17.1 Recovery (AOSP Q) for logical partition devices, which uses /dev/block/mapper to stage the partitions
Thanks LuK1337 & erfanoabdi @ Lineage
- /proc/$$/cmdline is \0 terminated argument strings except for the last argument which has no terminus, so the last argument was being dropped by `while read` which requires input to be \n terminated
- switch to a for loop, which will use the \n delimiter but also read the last argument; all arguments are still protected by quoting
- clean up potentially breaking recovery env since $OLD_PATH no longer exists
* Lineage Recovery 17.1, like AOSP Q recovery, has '/' as a shared
mount point, causing `mount --move` to fail.
If it fails, directly mount system to /system_root via
/dev/block/ symlinks, like AnyKernel and OpenGapps
Co-authored-by: John Wu <topjohnwu@gmail.com>
- pass addon.d arguments through trampoline or nothing will happen
- exit immediately after handing over from trampoline
- better grep for recovery OUTFD which should work in all cases
- output to logcat when booted and no binaries are found
- use /postinstall/tmp path to call functions from addon.d-v2 in progress
- remove unnecessary check for $MAGISKBIN since we're already executing from within it
- make sure we're not in $TMPDIR again before we delete it
- use $MAGISKBIN wherever possible in case it ever needs to be changed
- adjust mount scripts to support SOS, APP and CAC Tegra partition naming (vendor is still vendor, oddly)
- -Xnodex2oat is removed on Android 10 in AOSP (despite it still erroneously showing in dalvikvm --help); older devices will still run safely without it
- Android 10 dynamically linked binaries need APEX mounts and variables so add this to recovery_actions/cleanup (thanks @Zackptg5)
- clean up known systemless root leftovers because we're helpful
- Update backup format as we might be patching multiple partitions
- Update uninstaller to remove files in persist (sepolicy.rule)
- Better handling for dtb/dtbo partition patching
The new module installer script completely changes the way how module
installer zips are structured. More info will come later in docs.
The new installer script also supports installing sepolicy.rule to
persist partitions in order to make the module work on the next boot.
Previously, we use either BroadcastReceivers or Activities to receive
messages from our native daemon, but both have their own downsides.
Some OEMs blocks broadcasts if the app is not running in the background,
regardless of who the caller is. Activities on the other hand, despite
working 100% of the time, will steal the focus of the current foreground
app, even though we are just doing some logging and showing a toast.
In addition, since stubs for hiding Magisk Manager is introduced, our
only communication method is left with the broadcast option, as
only broadcasting allows targeting a specific package name, not a
component name (which will be obfuscated in the case of stubs).
To make sure root requests will work on all devices, Magisk had to do
some experiments every boot to test whether broadcast is deliverable or
not. This makes the whole thing even more complicated then ever.
So lets take a look at another kind of component in Android apps:
ContentProviders. It is a vital part of Android's ecosystem, and as far
as I know no OEMs will block requests to ContentProviders (or else
tons of functionality will break catastrophically). Starting at API 11,
the system supports calling a specific method in ContentProviders,
optionally sending extra data along with the method call. This is
perfect for the native daemon to start a communication with Magisk
Manager. Another cool thing is that we no longer need to know the
component name of the reciever, as ContentProviders identify themselves
with an "authority" name, which in Magisk Manager's case is tied to the
package name. We already have a mechanism to keep track of our current
manager package name, so this works out of the box.
So yay! No more flaky broadcast tests, no more stupid OEMs blocking
broadcasts for some bizzare reasons. This method should in theory
work on almost all devices and situations.
