2017.3.21 Magisk v11.5/v11.6

Magisk Binary Changes

Code: /sbin/su -> /data/magisk/su /sbin/resetprop -> /data/magisk/resetprop /sbin/magiskpolicy -> /data/magisk/magiskpolicy /sbin/sepolicy-inject -> /data/magisk/magiskpolicy /sbin/supolicy -> /data/magisk/magiskpolicy /data/magisk/sepolicy-inject -> /data/magisk/magiskpolicy

New Boot Image Tool: MagiskBoot

Complete rewrite boot image extracting process

Proper MTK header support

Sony ELF type boot image support

Native ramdisk compression method support : gzip, xz, lzma, bzip2, lz4

This means custom kernel developers can now use a different ramdisk compression method with their custom kernels!

This means custom kernel developers can now use a different ramdisk compression method with their custom kernels! Native cpio patching support: auto ramdisk backups, auto ramdisk restores, auto dm-verity patch, auto forencrypt patch, native cpio extract/mkdir/add

This means boot patching process itself does not require root access anymore (it usually does)

This means boot patching process itself require root access anymore (it usually does) Native LG bump and Samsung SEANDROIDENFORCE flag detection

More Magisk installation methods shall come soon!

MagiskSU Fixes

Magic Mount Vendor Issues

Module Template Update

The Magisk Module Template is now updated. All developers please adapt your modules to the newer version

it will only show the modules that are using the latest two versions of the template

I'll add them once you have migrated your module to the latest template

NOT add modules that ONLY change some props using resetprop

What's Next?

It's about time for some Magisk update!!The original toolis now renamed to. However, for backward compatibility, a symlink namedwill be created, which simply just links toThe original toolis now renamed to, which is a complete rewrite of the existing boot image patching tool. More info later.Starting from this release,, and if MagiskSU is installed,, and(this is NOT the SuperSU supolicy, it just links to magiskpolicy, exists for compatibility) are all added to the PATH, which means you can directly call these commands through shell (and apps) without explicitly calling "/data/magisk/XXXXX"In a nutshell:I spent a lot of time rewriting the whole boot image patching tool. For now it shallimprove the compatibility of Magisk. Key features:I believe some of the features above do not exist in any existing rooting methods, I hope this will bring more users on the Magisk bandwagonIn all current open source root methods, a common issue is that some apps (most well-known: Titanium Backup). Here I'll only briefly explain the technical details.After spending, the victims are narrowed down to programs that directly use the "mount" system calls instead of calling the "mount" command. Also, the issue does not only happens to /system, but instead any read-only partitions. The only way to remount them to rw is through theimplementation of the mount command, which should be the default of all devices. This means that any external mount command (e.g. busybox) cannot remount them to rw either. After digging through the AOSP toybox source code and some search through the commits, I finally found the culprit: this commit in AOSP . What that commit does in a nutshell is that all blocks mounted read-only will be locked to read-only.So starting from this release of MagiskSU, all blocks will be unlocked when the daemon is started (this does NOT break your system integrity, meaning it does not break OTAs), everything should work fine.Another subtle change is that the command "-cn" will not do anything starting from now.I had tried to add thecommand in the previous release, which only exists in SuperSU, but it was not implemented correctly, and apps depending on it will not work correctly.However, this "context switch" command is originally added to SuperSU due to the way it managed selinux back in the old days. The way I deal with selinux, starting from Magisk v7 (Chainfire switched to similar method in his latest beta)need any context change, as all root procedures and processes are running in a permissive domain (in Magisk's case it's a domain that allows everything, which is slightly different to permissive. This is because permissive does not work on Sammy)In Magisk v11.1, devices with a separate vendor partition (newer Nexus devices) will fail to properly magic mount files in vendor, the most common issue is using the ViPER4Android Magisk module.It is now fixed in v11.5An entry in module.prop callednow indicates the template version number.e.g. If the latest template version is v13, only v13 and v12 modules will be showed in the repoThis gives the time for developers to update their modules, but also enforcing them to adapt to newer scripts, so I don't need to support the old template formats.I apologize that I was busy and didn't add the existing module requests,Also please note that I will, as this is a upcoming feature to Magisk Manager in the near future.Magisk v11.1 got over 500K downloads! Thank you for all the support!The next short term goal is to add more features into MagiskManager (including the mentioned prop management, and a new installation method)The long term goal will be migrating the current script-based magic mount to C program, which shall be run as a daemon in the background, combining resetprop, magiskhide etc. all-in-one. This will take some time to finish though.For the long awaited Pixel support, I think I'll start working on it, but the complexity of that device might take a very long time for me to understand, since I do not own the device. I can only borrow my friend's device for not that long of a period of time, so progress shall be really slow. I'll not get the Pixel device now, because I don't think it is worth the price and the hassle for me to import it into Taiwan, but I'll definitely get the Pixel 2 to replace my current daily driver lol.