Magisk v13.0

Due to the fact that this release is nearly completely rewritten from scratch compared to the last release, I decided that it will be a better idea to release it as a beta, since many things might not work properly due to the massive changes. On the other hand, many previous bugs might be fixed due to complete different structure.

Unified Binary

As I previously mentioned in an update post, this release comes with the unified Magisk binary. The binary itself can be used as resetprop, su, magiskpolicy, magiskhide. Along with this change is that all operations are running in the same "unified daemon", including all boot operations, selinux live patches, magic mount etc. Even though this only covers one line in the changelog, it actually takes a lot of effort to redesign a lot of details.

Magisk only requires a single binary (magisk) to be injected into /sbin, an rc script defining all entrypoints, sepolicy minimally patched in order to start magisk daemon to fully work on a device. The ext4 image creation, resize, merging etc. are all handled automatically by the daemon.

Magisk Manual Injection

Due to many changes in this release, it is possible to patch a boot image on the Android device without root. The only requirement is the boot image itself (it is not possible to dump the boot image from the device without root, you will need the boot image from somewhere else), the ability to flash a boot image (most likely an unlocked bootloader), and a few adb commands. This doesn't seem like a big deal, but for devices with no custom recovery, this will be a good way to start rooting and do further modification on your device (flashing zips through FlashFire, adding modules by Magisk Manager etc.) I will post the simple instructions soon, and this boot patch without root feature is planned to be added into Magisk Manager in the future.

MagiskSU Massive Improvements

I spent some time to improve the included root a lot. Added multiuser support, added re-authentication support, and tons of bug fixes. Another point worth mentioning is the new timeout queue for root requests. In this release, root requests from the same requester will use a cached policy and suppress logging if called within 2-3 seconds. This will prevent heavy performance hit from poorly programmed root applications, which calls su for excessive amount of times within a few seconds.

(Addition in 2017.6.9)

New namespace mode options are added in build (0b4baad). In versions before this build, all root sessions run in the same global namespace. Starting from this build, the default mode will inherit the requester's namespace, so an application will internally share the namespace for both privileged and unprivileged processes, but do not share across different applications. Users can choose to use the global namespace, or opt in a stricter "isolated mode", which each root session will have its own separated, isolated namespace.

Temporarily Dropping SuperSU Compatibility

This is not a move against SuperSU. In previous versions, in order to support merging Magisk modifications into SuperSU without breaking stuffs requires TONS of handling in the scripts, and I don't think supporting an already patched boot image worth the effort. I plan to release a su.d Magisk alternative for SuperSU users who wants to use resetprop and magic mount features.

Magisk Manager v4.3.3

manager-v4.3.3

Use stable build tools + retrolambda

Magisk Manager v4.3.2

manager-v4.3.2

Bump version

Magisk Manager v4.3.1

manager-v4.3.1

Bump to 4.3.1

Magisk v12.0

The major version bump should label this release as a stable release (at least this is what I hope). This release is thoroughly tested by all my testers, especially focusing on Samsung devices. Unless major issues, the next release should be a complete new redesign, and requires more time, more info later. The FAQ in OP is updated, please check them out!!!

Samsung, Samsung, oh Samsung

My previous release was widely criticized for breaking tons of Samsung devices, the rating on Play Store also reflected this fact. Thanks to helpful testers and developers, we ironed out all the quirks of Sammy, and in addition added more Samsung specific features. One is adding proper support for Samsung permissive kernels. Another is faking KNOX to 0x0 if MagiskHide enabled. Is that good enough to compensate my mistakes in the last release? :p

Sepolicy Live Patch Moved

Another critical update is that the sepolicy live patching is now moved from the post-fs-data mode to the service mode. This decision is done due to the fact that on some devices (e.g. Samsung), there are too much to patch, which greatly delays the bootup time if the live patching is done in a blocking stage. However, this will require some updates for the minimal sepolicy rules. The minimal patch is now a little more complete, which requires 20-80KB of ramdisk size (previously 1-4KB). Still not large to be honest. However, this makes post-fs-data mode NOT completely unrestricted. post-fs-data mode can still do any file related operations, setting system props etc., a lot more than normal users would use. However, service mode would be guaranteed to be executed AFTER the full sepolicy patch is done. It is recommended to run most scripts in the service mode (service.d/service.sh), except a. mounting files; b. patching system props; c. time critical operations.

Magisk Core Only Mode

People complain that Magisk has "too many features", they don't want to use such "complete" solution. Here I introduce Core Only Mode. It can be enabled in the new Magisk Manager. What will still be started: MagiskSU, post-fs-data.d, service.d, (if enabled: MagiskHide, systemless hosts, systemless busybox). What will not be started: Cache (post-fs) mounts, magic mount (system mirror etc.), all modules, all module scripts. So it literally limits Magisk to root + boot scripts. MagiskHide is still there for those who want some Mario Run lol.

Say Goodbye to Outdated Modules

This day finally comes. All modules on the repo that aren't using the latest template (v3 for now) are now hidden. This not only guarantees that the modules are using the latest scripts, but also a nice way to filter out modules that are no longer maintained by the uploader. You have to add/update template=(ver) in your module.prop. Magisk Manager will not know if you only updated the scripts

Upcoming Features

Here are some planned features (sorted in priority)

• Magisk Manager resetprop GUI
• MagiskSU multiuser support
• Unified Magisk daemon: As stated before, I'm planning to write Magic Mount in code to achieve more efficiency and features. All current Magisk features (magiskpolicy, magiskhide, resetprop, superuser, magic mount) will be in a unified daemon
• Pixel (XL): Some developers has done some progress, I'll contact them and sort things out
• Android O: I bought a Nexus 5X now, finally got some O love

Magisk Manager v4.3.0

manager-v4.3.0

Bump version

Magisk v11.6

The issue turns out to be a veeeery minor issue, but causes the whole script unable to run correctly on Samsung devices. Also, I fixed the incorrect value for selinux prop patching for MagiskHide, so people with selinux issues should now be settled.

I guarantee all future releases will go through serious beta testing, especially Samsung devices. This project is in a scale that these kind of mistakes cannot be tolerated. I'm sorry for all the inconvenience the previous release gave you, and the mess and headaches for all broken devices.

The Module Template is again updated. This bug will also affect module templates, so please update accordingly, thanks!!

But still, I hope you will enjoy this new release :)

Magisk v11.5

It's about time for some Magisk update!!

Magisk Binary Changes

The original tool sepolicy-inject is now renamed to magiskpolicy. However, for backward compatibility, a symlink named sepolicy-inject will be created, which simply just links to magiskpolicy. The original tool bootimgtools is now renamed to magiskboot, which is a complete rewrite of the existing boot image patching tool. More info later. Starting from this release, magiskpolicy, sepolicy-inject, resetprop, and if MagiskSU is installed, su, and supolicy (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:

/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

I spent a lot of time rewriting the whole boot image patching tool. For now it shall GREATLY improve the compatibility of Magisk. Key features:

• 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!
• 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)
• Native LG bump and Samsung SEANDROIDENFORCE flag detection. More Magisk installation methods shall come soon!

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 bandwagon.

MagiskSU Fixes

In all current open source root methods, a common issue is that some apps (most well-known: Titanium Backup) cannot properly mount /system to read-write. Here I'll only briefly explain the technical details.

After spending very many hours, 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 the toybox implementation 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. All root developers can call the "-cn" command on both SuperSU and MagiskSU, it shall work in both cases. I had tried to add the "-cn" command 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) DOES NOT 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).

Magic Mount Vendor Issues

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.5.

Module Template Update

The Magisk Module Template is now updated. All developers please adapt your modules to the newer version. An entry in module.prop called template now indicates the template version number. In future Magisk Manager updates, it will only show the modules that are using the latest two versions of the template. e.g. If the latest template version is v13, only v13 and v12 modules will be showed in the repo. This 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, I'll add them once you have migrated your module to the latest template. Also please note that I will NOT add modules that ONLY change some props using resetprop, as this is a upcoming feature to Magisk Manager in the near future.

What's Next?

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.

Magisk Manager v4.2.7

manager-v4.2.7

Bump version

Magisk Manager v4.2.6

Finally got the Samsung crash fixed!! Thank you for everyone reporting giving feedback, really appreciate the community!
As a compensate for the frequent updates and inconvenience, I added another feature that was requested to Magisk Manager - add a setting to disable update notifications. Play Store might take a few hours to update, direct link in OP is updated

Finally, I can now focus on the core part, which IMO is much much more important :). Device compatibility should be GREATLY improved once the work is done, stay tuned! For Pixel support though, I'll need to borrow my friend's Pixel XL for a couple of weeks to develop, but this might not happen soon since school is quite busy.