manager.sh + boot_patch.sh:
- all listed files from boot_patch.sh header are required for boot patching, but stub.apk was being removed so install_magisk via addon.d.sh would fail without it; leave it in place
addon.d.sh:
- remove old redundant recovery_actions call (it's also performed by setup_flashable in initialize)
- print ABI to match flash_script.sh output
boot_patch.sh:
- catch and abort on any errors from ramdisk.cpio patching in the future
util_functions.sh:
- fix hiding of mount_partitions /system_root umount stderr
- quote mount_apex .pb DEST name parsing charset for safety even though both work
Fixes#6828
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