Magisk - The Magic Mask for Android

Why is Magisk Manager not available on Play Store? Is development abandoned?
This is what I get from Google this morning:

Magisk Manager, com.topjohnwu.magisk, has been suspended and removed from Google Play as a policy strike because it violates the malicious behavior policy.

Click to expand...

Click to collapse

What is the so-called "malicious behavior"? From what I've suspect, viewing the definition of malicious behavior, most likely I violated the two following policies:

• Apps that introduce or exploit security vulnerabilities.
• Apps or SDKs that download executable code, such as dex files or native code, from a source other than Google Play.

Click to expand...

Click to collapse

For the first policy: Magisk bypasses Google's strict compatibility check - the CTS check on tampered devices (SafetyNet checks CTS status). CTS is what Google judge whether a manufacturer can ship a device with its Google services, so Google is definitely really serious about this issue. Also, Magisk roots your device, patches tons of SELinux policies (all rooting method do) etc, which is also an obvious security breach.

However, I doubt this was the main reason, since many superuser management apps are also on the Play Store. The main reason should be the other one.
The second rule I listed can be translated to: you cannot have anything "market-like" to let users download and run code on your device. Apparently, Magisk's Online Repo is a complete violation against this rule.

Now I have two choices: Remove the online repo from Magisk Manager, and re-release a NEW APP on the store (yes, once your app is pulled down, the package name and app name is permanently banned).
The other way is to simply just distribute the app through places like XDA and third-party markets (just like Xposed Installer).
I prefer the second decision, because I can still use the same package name, also I wouldn't need to remove the online repo feature, which is one of the most precious thing for a development community like XDA. What I really lost is the $25 dollars for Play Store registration lol.

Development is definitely NOT suspended in any way, in fact, I had significant progress lately.
There are still some bugs not sorted out, and I need some feedback from the users, so I decide to start a new thread for public beta testing!
Expect the new thread to be live very soon, but I still need to do some small adjustments to deal with the unfortunate Play Store situation....

So the conclusion is: Yes, Magisk Manager is pulled from Play Store due to policy violation; and no, this is not a sign for the end of development.
In fact, I think Magisk is undergoing the most active development since release!

2017.6.8 [BETA] 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.

Documentations, module template updates, manual injection instructions will be updated in the few days.

2017.7.11 Magisk v13.1
Wow, what a journey! The last stable release is in April, nearly 3 months ago! As stated before, even though the functionality is the same as previous "script based" releases (anything prior to v13), the underlying mechanisms are actually significantly different from all aspects. You can consider this as a complete different project from previous versions lol. Here I will just do some announcements instead of going through all changes. The changelog now shows proper v12.0 -> v13.1 changes instead of changes for each beta iteration. Those interested in the actual changes can take a look there.

Completely Drop Support for Older Versions
Due to the massive difference between v12.0 and v13.X+, older "script based" versions were and will be never, ever put into consideration in development. There will be a lot more things that is no longer backwards compatible, and staying on an old release will let you miss out a tons of fixes and improvements, so please be sure to upgrade to the latest version.

New Magisk Module Template v4
Finally, the module template received an update! The new upgrade brings proper Android O handling, and many fixes for flashing in all kinds of environment. New changes comes with new things that need to be noted. You will find out that the commands in the flash script are now greatly reduced, with only the essentials and function calls remain. The script now relies on the main binary /data/magisk/magisk, and the shell script function collection /data/magisk/util_functions.sh, both come along with a proper Magisk v13.1+ installation. These changes are due to the fact that a lot of the ext4 image handling are now offloaded to the magisk binary, since there is no real way to properly handle these operations aside from using my own written tools, one factor being the removal of the bundled busybox. Another major advantage is that since the actual logic and operations are not bundled in the template itself but rather included in Magisk, once a bug or improvement is found, the changes can simply be pushed through a Magisk update instead of updating the template, which requires module developers to migrate to new code. It is similar concept to what "shared libraries" are doing.
However, due to these changes, Magisk Modules are no longer flashable in custom recoveries without /data access. You have to either flash in proper configured custom recovery with /data access, or flash within Magisk Manager (the scripts and merge handling are greatly improved compared to old versions, worth trying!)
The next release (not this one) of Magisk Manager will filter out all modules on the repo with template version lower than v4, developers please find some time to upgrade your modules, I believe it will only take you a few minutes!

Module Repo Submission
Many could have questioned why I haven't accepted a single module into the repo for quite a while, not because I don't care about the community (I gave up Play Store for this, how come will I abandon it), the reason is because I have been working hard to finalize Magisk, which only after then I can decide the final format of the template. With the new Magisk comes to stable, and a lot of thoughts have been into, things should rarely change, at least not significantly, and as a result module submissions will start get accepted once they are adapted to template v4.
This summer vacation I have an internship, so things are different compared to last summer when Magisk was born from my endless and sleepless development - I have proper work to do now lol. Also due to the fact that it's going to be my last year in university, I need to start preparing for applying graduate school; the free time will be very limited. I will focus more on maintaining the online repo, and slow down the development of Magisk, which means submission should be addressed in a timely manner.

Play Store Device Certification
There is a new thing within Play Store called "Device Certification" (you can check through settings). Currently I cannot find how it works, it always shows "Certified" on my Nexus 5X on O preview and Galaxy Note 10.1 2014 running LineageOS 14.1, however no matter what I do, my HTC U11 always shows "Uncertified". Currently this isn't a big deal though, I won't spend time investigate this.

Some Miscellaneous Stuff
Some might have noticed, the scripts under /magisk/.core/post-fs-data.d and /magisk/.core/service.d requires execution permissions to be executed, this is done intentionally as some developers rely on the file permissions to toggle scripts. post-fs-data.sh and service.sh in modules, on the other hand, doesn't have this requirement. These scripts should be toggled along with the module, not based on the permission of the file itself.

On Android O, setting system props through property_service (the setprop command, and resetprop by default) in the post-fs-data stage will cause the boot progress to halt - it will wait till the timeout set in Magisk init scripts is over, doing nothing in the meantime. This will cause super long boot times and prevents Magisk to work properly. In previous Android O previews, this even prevents the device to boot up.
Important: I HIGHLY suggest all developers/users to run their scripts in service mode UNLESS necessary. If you had to set props in post-fs-data (build related ro props for example), please consider using system.prop in modules as Magisk will handle it properly. If you really need to set props through post-fs-data scripts, call resetprop with the flag "-n" enabled, this will bypass the property_service.

With the introduction of mount namespace separation, some root developers contacted me for a request for "master-mount" option. This is added to MagiskSU, and calling su with this flag will give you the global mount namespace regardless of user configuration within Magisk Manager. Useful for root developers which need to global mount namespace for managing mount points.

Final Words
The documentation is super outdated now, and I have previously promised for an update but it never happened lol.
I already start working on it, too many has changed and some stuffs has changed seriously. A major new release should come with proper documentation
I will post another update once the documentations are done, I will point out some of the most important ones.

2017.7.14 Magisk v13.2
Here comes the release to fix many fairly small but critical issues in the last release

MagiskPolicy Update
Thanks to @jenslody for finding this bug! This is the reason why many cannot make Magisk v13.1 run on your device, since selinux patching is a critical part in both Magisk's boot patch and boot sequence. Most victims seems to run on Marshmallow. If your device wasn't running v13.1, this release worth a shot

/sbin Re-link Fixes
One of the most important part in MagiskHide is the /sbin re-linking part. In previous versions there is a bug where the selinux context was set to a non-target folder, which casues some issues. Also, along with the bug fix, I also adjusted the context to match other files in the ramdisk, so that it might also eliminate a lot of weird issues (phone feature breaking non-related to Magisk) if MagiskHide is enabled. For one that I know is that HTC U11 users suffering the USB-C headphone jack adaptor malfunctioning should now be fixed.

Please Migrate Modules to v4!!
Currently, there is only few modules on the repo that has updated to the new template format. This release still WILL NOT block out v3 modules, but this will happen most likely when the next verison comes out. For the many module submissions on Github, please also update your module to the new template. Many thanks!!

2017.7.18 Magisk v13.3
Google really doesn't want me to rest, let's just jump right into it, shall we?

SafetyNet
This update is pushed out earlier than I planned to do so, but apparently users cannot wait anytime longer for the SafetyNet fix lol. This time, the additional detections are fairly easy to figure out, some even cracked it before I even know the issue exists.
This particular change is still within my expectations; in fact, being the creator of Magisk, I personally have TONS of other ways to detect Magisk, apart from "package name" detection which I currently do not have an optimal solution, I can hide all the other methods (note: I'm no security expert, this is only MY point of view, a university student who can't stop coding). I won't go on and implement all the hiding techniques and put all my cards on the table though, Google will slowly add more and more detections, and I'll just update Magisk each time something breaks. I believe there is still a long way till I run out of ideas

Resetprop
Google is targeting system props this time, resetprop FTW! The init process will record all start up services and set a property for each to indicate the state of the service. Well, we'll just parse through all props, and remove those which Google doesn't like! Something worth noting though, previously deleting props only happens in the memory, so the props disappears immediately, but persist props will actually stick for the next reboot. Resetprop is updated to support completely eradicating persist props when using its delete command, and the "-n" flag can give you the option to only modify the data structure within memory without actually touching anything.
The uninstaller is also updated to remove all persist prop it left behind.

Magisk Manager
The big thing here is actually Magisk Manager! I have massively rewritten a lot of portions of the code, mostly under-the-hood changes. However, there is a feature I always wanted.
You can already enjoy the new flashing log screen if you upgrade Magisk Manager before upgrading Magisk through the application!
A video is always better than a million of words, check it out with your own eyes

2017.7.20 Magisk Manager v5.1.1
Here comes the update of Magisk Manager to fix the notorious "app cannot start" issue. Fun fact: this issue is not even my fault!

According Posix Standards, a line in Unix is defined as a sequence of characters following a terminating <newline> character. So what this means is that if the last line of the file does not end with a newline, technically speaking the text file is not "ended". Magisk Manager didn't handle this situation, so it simply hangs there while parsing an improperly formated module.prop file, since it cannot find the end of the file. Magisk Manager will now handle this properly, so things should work just fine!

Magisk-v13.3.zip in the OP is re-uploaded with Magisk Manager v5.1.1 bundled, so users flashing a newly downloaded zip will not suffer from the bugs in the older versions. I'm constantly improving the Magisk Manager since the app code is a bit crappy (not an expert in Android Application development...), so each Magisk Manager update should come with many improvements and updates.

Several Announcements
It has been really busy for me lately, having a daytime job as an intern isn't that easy

Magisk Module Template v5 Removed
As stated in the previous beta release notes, the v5 module template is considered as a developer preview. I haven't fully tested the template yet, and apparently there are some critical bugs, so I temporarily removed v5 template from Github.

Documentation
I promised a documentation for quite a while, and it finally happened! The original Wiki thread here on XDA is discontinued, all new documentations are hosted on Github.
The links to the docs are in the OP, or here

Install Magisk With ADB: No Custom Recovery Needed!
A lot of work were already done to make patching boot images in a non-root shell work properly, even the Magisk binary itself has added some functionality to support it. However, it wasn't fully tested, and the instructions never came out. Since the busybox environment started from v13.5, a consistent shell was established, so I took a bit more effort to finalize the way to manually inject magisk into a boot image. The method is added to the Installation section in the OP, people interested can check them out!
Note: This new installation method only works on the beta version v13.6, go to the beta thread for more info

More Announcements
These few months has been really busy (I think I've said this for like 1000 times...), so I had little time to do proper Magisk maintenance. However, today is Solar Eclipse day (for those in the US), and also the Android O day, I guess I'll announce "something" to celebrate it!

Hiding Magisk Manager
Despite the limited free time, I managed to squeeze out this highly anticipated feature into Magisk Manager, thinking the implementation would be interesting but not too complicated.
Here is a demo video in action:
The method is far from perfect, but good enough to hide from many existing detection methods. As you can see in the video, after hiding Magisk Manager, it will automatically install a new app called "Unhide Magisk Manager". The cool stuff here is that the new app is given a new random package name and signed with test keys on-the-fly each time you hide Magisk Manager. This will prevent detection methods from detecting "Unhide Magisk Manager"'s' package name, a bit more "future-proof".
There are still some other stuffs I'd like to polish, expect this new feature to be available in the next beta release.

Pixel (XL) Support
People following me on Twitter might have known that I recently got my hands on a Pixel XL. After some brief research and investigation, the situation is not as complicated as I initially thought, so official Pixel support should be possible and pretty clean. However, it still requires quite a lot of adjustments, I wouldn't work on it until I have more free time, and also I would focus on pushing out a new stable release before I dive full in Pixel devices. In the meanwhile, Pixel (XL) users can use the unofficial builds if you want.

Unofficial Sites
I'm aware of some sites (such as https://magiskmanager.com) using the Magisk name to distribute Magisk. To be clear, all binary distribution are and will be hosted on XDA or my Github account, I do not own or be affiliated with these websites. I'm actually fine with websites like this using my project to gain ad revenue lol, but I still recommend users to download and seek for support from official sources, or even build Magisk yourself so it won't include any malware.

2017.9.6 Magisk v14.0
Finally got some free time to work on development! Before adding the Pixel (XL) mess into the mix, I figured I would focus on stabilizing the current version, and make installing easier and more robust.
There are tons of under-the-hood changes compared to the last stable version, here I'll summarize the changes (include those in the betas) all in one post.

Busybox is Back
I have constructed a setup to easily build busybox for Android, and it has been included into Magisk. Also, a cleverly crafted update-binary, a shell script that has busybox embedded and can extract binaries matching the architecture on-the-fly, is used as a basis for installing. That busybox binary will also be used in various places such as all boot scripts and Magisk Manager, but will not be exposed externally. In order to install busybox systemless-ly, please install the Busybox module from @osm0sis, which is available on the module repo.

Samsung Stock Kernel Workarounds
Tons of changes has been done to overcome some weird issues on Samsung devices, including exec and fork issues. All functionality are thoroughly tested to work on both Samsung and non-Samsung devices.

Hiding Magisk Manager
This new feature has been added to Magisk Manager. The approach is pretty naive, as it can be still detected in some way, but it should work in many cases. When select to hide Magisk Manager, it will randomly generate a new package name (so it can't be blacklisted) and install a new app called "Unhide Magisk Manager" to your device, then it will eventually hide itself. While Magisk Manager is hidden, root will work with apps that were granted before (the database is still there), but no new requests can work since the application itself is hidden and all components are disabled. To unhide Magisk Manager, simply just open "Unhide Magisk Manager", Magisk Manager will immediately be unhidden and started up, while the unhide app will automatically remove itself.

New Installation Method
Nearly a month ago, I introduced a way to install Magisk through ADB. This is nice for devices with no custom recovery support, or for people like me who wants to preserve stock recovery to apply OTAs. To make things even easier, I have added this feature natively into Magisk Manager. In Magisk Manager you can provide your stock boot image (in both raw image format or tar-ed up ODIN flashable format), the app will then patch the provided image. Other required files and scripts are extracted within the app's data, and will be picked up automatically while booting up once with a magisk patched boot image. Check the new instructions in the OP for more info.
Once your device has Magisk installed, you can install Magisk modules through Magisk Manager without custom recoveries. The powerful systemless interface means that you can literally do anything to your device - of course systemless-ly!

New Magisk Manager Features
Apart from the new installation method, some other new features are also added. You can now restore your stock boot image by selecting Uninstall > Restore Stock Boot. Personally I find it very useful: after restoring to stock boot image (without reboot), I can directly apply OTAs on my device. Of course, you need to have stock recovery installed (thanks to the new installation method, I refrain from installing custom recoveries), or if supported you can use Chainfire's FlashFire to apply the OTA. After applying the OTA, you have to re-root your device again, or if using FlashFire you can just choose to flash Magisk along with the OTA.

Another feature is the introduction of update channels. You can now opt-in to receive updates from the beta channel through Magisk Manager.

New Magisk Module Template - New Versioning Scheme
Modules Developers please pay attention to this part!
A new template has been pushed to the repo. Starting from this version, the template version (the template entry in module.prop), is now the minimum supported Magisk version code. So for this particular release, the template version will be "1400", which is the version code of Magisk v14.0 (1400).
The updated template comes with tons improvements here and there, so repo developers please migrate to the new template ASAP.
The reason why there is a minimum required Magisk version has been mentioned before: it is due to the fact that most installation logic is NOT in the modules, they are shipped in a universal script with Magisk.

Also, starting from v4, all previous versions will be preserved on the Github repo in the branch name in respect to its version.

The default branch, which should be the latest one, will only have two commits:
"Initial Commit" --> "Magisk Module Template <version_num>"
All changes are squashed into one single commit. It will be much cleaner for new module developers to start from

While other older branches will have three:
"Initial Commit" --> "Magisk Module Template <old_ver_num>" --> "Template <old_ver_num> -> <next_ver_num>"
The third commit is there to show the difference between the old and new version. This is useful for existing module developers to know what to update. If you are familiar with git, you can simply just cherry-pick this commit to finish the migration.

Small Update to MagiskHide
Some devices ships with broken kernels! These kernels will cause magisk.img fail to mount. Previously this will also cause MagiskHide refuse to work, since the hide list is stored in the image. With a small adjustment, MagiskHide now works fine without the requirement of the image to be mounted, but this also means that if you want to hide certain apps in addition to SafetyNet, you will need to manually add them each time you reboot, since the hide list only exists in memory. In other words, if your kernel cannot mount magisk.img, you are forced to run in core-only mode.

Pixel, Pixel, Pixel
If this update is working fine just as expected, I'll finally put full force into working on Pixel (XL) support. I've already done some brief research, hopefully I can pump out official support soon lol.

Below is the changelog from the previous beta:

• v13.6 -> v14.0
  - [Magic Mount] Fix a typo in cloning attributes
  - [Daemon] Introduce workaround on Samsung device with weird fork behaviors
  - [script] Simplify installation scripts
  - [script] Installation will migrate old or broken stock boot image backups to proper format
  - [script] Fix an issue with selabel setting in util_functions on Lollipop
  - [busybox] Bump version to 1.27.2
  - [MagiskHide] magisk.img mounted is no longer a requirement
  Devices with issues mounting magisk.img can now run in proper core-only mode

2017.9.28 Magisk v14.1/14.2

Hot Fix: Magisk v14.2 is released to the beta channel to fix a critical issue that breaks 99% of the modules, please upgrade ASAP!

Here comes the long anticipated release - Official Pixel family support!
I spent full-time on Pixel (trust me, I didn't do any proper work at that time...), then I took a vacation for a week. That's why tons of Magisk Module repo requests are not addressed. Please pardon me and I will add them in the next few days

Welcome, Pixel!
Due to the unique partitioning of Pixel devices, a lot of changes has to be done. First, the kernel has to be patched to boot with initramfs under all circumstances. Then, we need to replace the init binary to handle whether boot into recovery or system, construct the rootfs, and mount system properly. Finally, to remove dm-verity on vendor, we would need to patch the fstab placed in the dtb. There are many other quirks such as A/B partition detection, file based encryption, and the fact that sepolicy is no longer placed in rootfs - it is either pre-compiled in vendor, or split as several CIL source files in system and vendor. With all the hassle overcome, a fully working Magisk build for Pixel is here!

Introduce MagiskInit
The essence of the Pixel support is the newly introduced MagiskInit tool. This binary will replace the original init binary in the initramfs, and bring the device up booting. For those who don't know, the ramdisk in Pixel boot images are for recovery, the actual rootfs is stored in the system partition. What MagiskInit will do is that it will parse the kernel cmdline, and once it detected the device is doing a normal bootup, it will

1. Clear everything in rootfs (except overlay directory)
2. Mount sysfs to construct our target system and vendor block nodes (using the proper slot)
3. Mount system, clone the root structure to the actual rootfs
4. Move everything in overlay directory to rootfs. This is used to add addition files such as the magisk init script and magisk binary.
5. Patch the rootfs files (init, init.rc etc.) for Magisk support
6. Mount vendor, check whether exists pre-compiled sepolicy, if yes load the policies into memory, if no compile the CIL files into memory
7. Patch the sepolicy rules, and dump as monolithic policy into rootfs
8. Call the original init binary to continue the boot process

In a nutshell, ramdisk patching for the Pixel devices is actually easier than the traditional devices - we add additional files into the overlay folder, replace the init binary with MagiskInit then voilà! MagiskInit will handle the cmdline parsing, partition mounting, construction of rootfs, overlay files, patch files, and patch sepolicy - we don't need to patch anything while installation, everything happens at boot time! For those who are worried, I cannot perceive any delays while booting after doing these changes to my Pixel XL, so this should not be a concern.

Magisk Module Template Update
A new template (versioned 1410) is now live. Mostly small changes for Pixel support.
It is still not the default branch since v14.1 is a beta release, 1410 (or newer if bugs found) will become the default once the code hits stable channel.

Pixel Exclusive Features
Surprise surprise! Thanks to the A/B partition of Pixel devices, we can actually receive and apply OTAs seamlessly using the stock OTA mechanism and preserve Magisk at the same time! More info in the next section.

New OTA Installation Tips
I had added a whole new section in Magisk Documentations with tutorials for applying OTAs on your device. The step-by-step guide with screenshots can be found in the Useful Links section in the OP.
The guides include the Pixel exclusive method, FlashFire method, and general guidelines for all other non-supported devices.

Miscellaneous
There are some changes to the Magic Mount mechanism - it no longer uses dummy directories (/dev/magisk/dummy) to construct dummy skeleton, it directly mounts a new tmpfs onto the target, and construct the structure in place. This will reduce A LOT of duplicate/meaningless mounts.

Due to the significant changes, it has to go through the beta channel before it can drop to the stable channel even though it was quite thoroughly tested. Please try out the new release, even if you're not using Pixel, since the changes might have some regression on traditional devices that I haven't discovered yet.

Enjoy

2017.10.15 Magisk v14.3
Here is another release, which comes with quite a few exciting updates!

Introduce Invincible Mode
Let's get straight into the interesting part!
Due to the nature of Magisk, the daemon is responsible for everything: initial boot scripts, magic mount, root, MagiskHide, logging etc., so it is important to make sure it never fails. Even though I have spent A LOT of effort in making the daemon as stable as possible, there are still tons of probability that might cause the Magisk daemon to crash: modules that messes with the internal workings of Magisk; root apps that have unexpected behaviors etc.. With the daemon crashed, root will lost, and SafetyNet will no longer pass, which would be very annoying and frustrating.
Even though I personally never experienced any root loss issues, the number of complaints urged me to implement a "self recoverable" daemon, which I would like to call it "invincible mode". Basically, the system will make sure the Magisk daemon is always running, and will restart if crashes (or even manually force killing the daemon!). Most of the effort is to make the restart seamlessly: that is logging will continue, and MagiskHide will still start up if enabled.

Rewrite Magisk Logcat Handling
The daemon uses logcat in many different situations: the general logging (/cache/magisk.log), verbose boot+debug logging (/data/magisk_debug.log)(only in beta builds), and MagiskHide (monitor process startups). In the worst case scenario, the daemon will come along with 3 logcat child processes; in addition, each process will require its own implementation to handle logcat errors and restarting. In this new update, I created a single logcat subprocess for the daemon, and each worker threads that need logs can simply plug in its own listener on-the-go, and leave anytime if not needed. By doing so, each process can access the "real-time" logs (if starting a new logcat process, it will first dump logs in the buffer before showing the real-time logs), and don't need to worry about restarting logcat if anything happens.

Magisk Manager Now 100% FOSS
The Magisk Manager also got a pretty sweet update! Tons of improvements are added, check the changelog for the detailed new features. (The new manager will be pushed to stable channel)
One thing I would like to highlight is that - Magisk Manager is now officially 100% FOSS! You might be wondering: isn't Magisk already open source? The truth is that Magisk Manager contains part of Google's proprietary "Google Play Service SDK" for SafetyNet checking, which make Magisk Manager technically not "FOSS". It is quite stupid to lose the "FOSS" tag for such minor thing as SN checking, but I found it extremely convenient and didn't really want to remove this feature. So what I did is separate the proprietary part from the application, and let users decide whether to download an external code extension (contains GoogleApi) for SafetyNet checking, which actually is pretty challenging since it involves dynamic dex loading and uses quite a few reflection techniques, but it was a lot of Java fun lol.
This makes Magisk Manager feasible to be placed on F-Droid, I will find some time to publish to their repository.

Online Repo
Magisk Manager is now updated to reject all repos with the template version lower than 4. I already filed issues to the outdated repos, if no action is done, your repo will be removed very soon.
For the next stable release, I will push even further to require all repos to be at least version 1400. For developers not using my template, make sure to test your module against Magisk v14+, and please also remember to bump the template entry in module.prop to 1400 to prevent from blacklisting.
These measures are done to make sure developers keep up with the latest changes, and don't let online repos be filled with outdated, boot-loopable modules. Thank you for your cooperation!

If nothing catastrophic happens on this beta build, the new stable release is imminent

2017.11.23 Magisk v14.5
Many people dislike the direction Google is leading Android judging from the Pixel lineup. Inevitably we will see Pixel-2-like configurations on all newly released device at some point in the future, since any device shipping with Oreo will need to pass Google's new VTS. And for sure we start seeing cheap shots like lazy OEMs releasing new devices with outdated software, which I'm VERY disappointed to see the "highly praised" OnePlus 5T on the list, but I digress.
The introduction of Project Treble brings a huge change to how we mod our devices, and Magisk is exactly created to accommodate this nature: minimum intrusion with maximum versatility. It is sad to see people in the forums happily rooted their shiny new Pixel 2 XL, but immediately modify system files just like the good old days, completely ignoring what Magisk is created for in the first place. Not blaming anyone here, but I guess the systemless concept still requires some time to be widely accepted.

Forgive my little rant, let's get into the nitty-gritty , here's another release with exciting new features!

Dynamic Runtime Initramfs Setup
As mentioned, installing Magisk on newer devices starting from the original Pixel series requires special treatments, and this has led to two separate logic for installation. I have spend some time rewriting the startup process of Magisk, and unified the installation across all devices. The magisk binary and init scripts are embedded into magiskinit, and magiskinit will dynamically inject these files and patch (or construct in the case of skip_initramfs devices) initramfs and sepolicy on-the-go. The actual modifications done on the device is replacing init with magiskinit in ramdisk of boot.img , and additional dtb/kernel/dtbo patches if required.

MagiskHide - Even More Badass!
More and more apps (those that doesn't use Google's SafetyNet API to check device integrity) has been updated to detect Magisk, such as the popular game Fate Grand Order and a handful of banking apps. I got bored and had my hands on to fix this issue. The fix can be roughly split to two parts, both of them are future proof to a certain extent. There are still some stuffs that can be detected, but even if I can hide them easily I haven't bothered yet. Unless they come up with complete new innovative ways to detect Magisk, the new hiding method should work in all cases (at least for now).

The first part is that Magisk image's mount point is now moved under /sbin/.core (along with several internal paths) , from /magisk to /sbin/.core/img; a symlink (/magisk -> /sbin/.core/img) is still added for legacy support. However, the symlink could be temporarily removed when MagiskHide is working, so scripts that had hardcoded path "/magisk" should really start migrating to "/sbin/.core/img" since "/magisk" doesn't always exists. The result is that the existence of the folders will also be hidden with MagiskHide. Changing the mount point means some modules using bad techniques such as creating symlinks pointing into magisk internal paths might break! You shouldn't assume the Magisk mount point to always be /magisk. One possible way to overcome this is to NOT use symlinks but use hardlinks (command ln without the -s flag), but I still wouldn't recommended it since modules should not depend on Magisk's internal stuffs.
Some modules NOT using the util_functions.sh from Magisk will have high chances to break, please update accordingly, or migrate to use the global util_functions.sh so Magisk internal changes will reflect to your module

The second part of the puzzle is that Magisk Manager can now be properly hidden. Hiding Magisk Manager will now repackage itself with a randomly generated package name to replace the original one. The real magic and challenge here is to transfer root management from the old package name to the new one seamlessly. Even though I have put a ton of effort and this feature has been tested for quite a while, due to the complexity I would still only recommend enabling this if you ACTUALLY need it. If you face any issues, simply just reinstall the proper Magisk Manager back and re-hide again.

Welcome On Board, Pixel 2!
Lastly, let's welcome Pixel 2 (XL) on the official support list! One additional change to the Pixel 2 installation compared with v14.4 is that I added dtbo.img patching support to disable avb-verity of the vendor partition. You can now modify (though not recommended) the partition without issues. The DTBO is a separate partition on the device, and Magisk will backup the original one to /data/stock_dtbo.img.gz for restoration and uninstallation.

P.S. This release was meant to be a stable v15.0, but my testers suggested to remain as beta due to the couple big changes mentioned above. It is now a good time for Magisk Manager translators to submit your patches to Github and prepare for the upcoming stable release!

2017.12.22 Magisk v14.6
Previous implementation of the hiding Magisk Manager mechanism has flaws, the Magisk Manager lack the capability to recover from the repackaged state.
If you have hidden (repackaged) Magisk Manager on v14.5, you HAVE TO upgrade both Magisk Manager and Magisk VIA THE APP to not mess up!!
Please DO check the updated Notes & Troubleshoots section in the OP if you plan to use the Hide Magisk Manager feature!!!

This should be the most thoroughly tested release ever LOL.
Not that much new exciting features, but tons of improvements along the way!!

Project Restructure
For those following the Github source would realize that the project has gone through a major restructure - the whole Magisk source code is now a single Android Studio project. Since Magisk's code is starting to become overwhelmingly huge, and also Magisk Manager (Java) is so deeply integrated with the core C/C++ part, the burden to develop Magisk is becoming more and more annoying. I decided to utilize Android Studio's CLion (a C++ IDE) NDK integration to assist the development, and another advantage is that I can develop Magisk Manager (Java) side-by-side with the native C/C++ part. Those who are willing to dig through Magisk's source can simply select the whole folder in Android Studio, and you can start developing immediately!
Just keep in mind: don't build Magisk with the built-in gradle scripts, the building process is quite complicated and all handled through the Python script "build.py"

Stability Fixes
Invincible mode has been rewritten. A new daemon "magiskinit_daemon" (a fork of magiskinit) will maintain a socket connection with the main magisk_daemon, and once disconnected (which means the daemon unexpectedly terminated), it will respawn the magisk daemon right away. This is much more robust than the previous implementation which relies on a init rc script, and the additional daemon will consume no power and very little memory since it literally does nothing unless the socket connection is broken.
A bug in the logcat monitor (a very essential part of MagiskHide and logging) which causes spawning infinite logcat processes and exhaust all resources until system reboot (not very common but fatal) is resolved. It has also be rewritten to be more efficient.

Huge MagiskSU Improvements
Since I picked up phh's Superuser source code, I have massively rewritten all the daemon part (communication, database handling, mount namespace etc.), but really never touched the actual "su" implementation. All CM based root (phh, Lineage SU, and previous MagiskSU) inherently include the same incomplete daemon-based su implementation (required since Android 4.3+) across the board. For this update I referenced the official Linux su manpage and made the behavior of MagiskSU as close to the reference as possible. The most noticeable change is that environment variables are now preserved from the original shell to the root shell. This was originally a default behavior of all Linux process forks, but since we are calling a new shell via socket by the daemon, additional work has to be done. More detailed info are in the changelogs.

MagiskHide Improvements - Continuation
In the last release, I added the feature to repackage Magisk Manager, and also move the mount point to a volatile location so it can be hidden by MagiskHide. As a continuation in this release, all Magisk related files are moved to /data/adb, a folder that already existed which has access permission (700). By doing so, any non-root process can never know the existence of any possible Magisk file on the device. In theory this should eliminate ANY naive way to detect Magisk (at least not involving hardware based cryptography) from a target process, but I know several apps that still can detect Magisk. Those might have used some other approaches to detect root (e.g. spawn another process like SafetyNet), I'll try to crack them if I find the time to do so. For those worrying the changes might break stuffs, I had added symlinks for backwards compatibility (just like the previous /magisk symlink), so it should work "most of the time" (as long as MagiskHide isn't actively running a hiding session). A complete redesigned Module template will come out along with the stable release (very soon).

Installation Flags
A new install mode: ramdisk high compression mode is introduced. In real world tests, a Magisk installation will add at most 4XX KB to the compressed ramdisk. If a device has a very small and restricted boot partition size, this size change might actually make the patched boot image unable to fit in. Starting from this release, if the free space in the boot partition is lower than 500KB, high compression mode will be triggered, Magisk will recompress your whole ramdisk with xz (lzma2 alg.). In real world tests, this will typically create near 2MB free space, so this means that Magisk should fit any possible device. This is possible thanks to updates to magiskinit, which can dynamically decompress your ramdisk on-the-fly on boot. The KEEPVERITY and KEEPFORCEENCRYPT flags now have new default settings.
If dtbo.img is detected on your device, KEEPVERITY is enabled by default. If your device is already encrypted, KEEPFORCEENCRYPT is enabled by default.
These default values will show up in Magisk Manager, and will also affect the installation via recovery.

Magisk Manager
Probably the biggest improvement for this release should be Magisk Manager. Although nothing massive changed visually, TONS of bugs and improvements are done under-the-hood. Repackaging Magisk Manager now works much better and more reliably. Settings will be migrated from the original manager to the repackaged one, and it can properly handle duplicate Magisk Managers. Tons of compatibility code has been added to support all possible su database setups. Please check the changelog for the full list of changes.

2017.12.26 Magisk v15.0
Merry Christmas! And wow it has been quite some while since the last stable release. Well it's Christmas, let's drag Magisk out of the eternal beta!

To wrap up the changes from v14 to v15, there are two major parts: update Magisk to be modular and adaptive to follow Google's Pixel concept, and completely remove all possible traces of the existence of Magisk.
Ever since I added Pixel support to Magisk, I have been amazed by how Google has designed this whole new system: modding a device has changed completely. I am a strong advocate of these new changes, praising the effort Google has put into designing such weird but fascinating setup despite many view this as "moves against developers". With the announcement of Project Treble, all devices will go through the same "Pixel-ize" treatment, so this future is inevitable. Project Treble is all about "modular", and Magisk has been rewritten to embrace this concept. I have spent extra effort to backport the changes made requires to run on these new modern devices to downward support all devices, so we do not need 2 drastically different installation methods: every single device running Magisk shares the same setup. Most things are now all dynamic, a single binary can handle all sorts of configurations, constructing the environment adaptively, and for Treble enabled devices even works when modular parts are swapped out. Fun fact: for Pixel devices, we only need a single init binary to boot up and properly run Magisk!
The second major part is to theoretically hide Magisk from any possible detection methods. Tons of hints/signal/traces of the existence of Magisk are now removed, and Magisk Manager supports repackaging to completely hide from naive package name detections. These changes requires some major redesign in Magisk structure and previous paths.
The above is a quick recap of what has happened in the past 3 months. The following are some important announcements.

New Template 1500
Magisk v14.5+ has gone through some major redesigns, but thankfully backward compatibility is done to fully support down to vanilla 1400 template. Most existing modules using 1400 template as a base should still install and work fine, however module developers might need to do some minor updates to properly support v15.0, depending on how the developer has implemented things. The new 1500 template strips out even more logic within the module, making it nearly a stub to just call functions from the external util_functions.sh, a script which will be installed along with Magisk. This gives me the ability to fix issues and do adjustments in Magisk's implementation without modules needing to do any adjustments. The template is very unlikely to change in near future, so module developers feel safe to migrate all modules to the new template.

Some notes: in 1500 template, the entry "template" in module.prop is now changed to "minMagisk". Since some talented developers do not use the template, calling it "template" doesn't seem to make much sense to them, that's why I renamed them to "minMagisk", to what the value actually means: the minimum required Magisk version. But don't worry, the two keywords "template" and "minMagisk" is 100% interoperable, you can use either in your module.prop, choose the one that makes sense to you.

Magisk Repo Submission Server
Previously, adding a new module requires me to manually clone developers repo to the online repo, and manually add them to collaborators to allow upgrading. It is quite a pain, and if I was busy I don't even bother to do so, so this causes many submission requests to piled up. I written a server to fix this issue (the code of the server is also open source). The new server will not only monitor the requests and process them within seconds, but also acts as a moderator to make sure all submitted and existing repos are setup properly and not outdated. 10+ incorrectly configured/extremely outdated modules are already removed from the online repo.
New submissions should create issues here: Magisk_Repo_Submissions, the instructions are updated to assist developers to submit and properly maintain their modules. Please note that once you created a new issue for submission, it shall be addressed within seconds if my server is up. The server is currently running on my laptop, so it will not always be online, but overall your requests should be addressed in no more than a day (I don't think I will leave my laptop without Internet for more than a day lol)

This release mostly fixes some small but critical bugs present in the last beta, users running into issues should try out this build. Those coming from v14.6, check the changelogs for all the changes in detail.

2017.12.29 Magisk v15.1
The previous stable release has been put into extensive testing from my testers, and also very thoroughly tested on my side (4 different device setups, 4 Android versions), but still some issues are kept under the radar and went through all the testing......
Please accept my sincere apology! There were some faulty code in magiskboot, which in some cases will cause fstab to be corrupted, leading to bootloops. The issue is now identified, reproduced, fixed, and tested. In addition, with reports and feedback from users, Magisk Manager is also updated with bug fixes and more robust sudb management.

For a more complete release note, please check v15.0 Release Notes

I added a highly requested feature in Magisk Manager: sort repos with last update, hope you will enjoy, forgive me, and please don't hunt me down

2018.1.1 Magisk v15.2
What is a better way to celebrate 2018 than a Magisk update fixing bugs. This update mainly fixes these main issues:

I fixed fstab ramdisk patches in the last release, but forgot to update the dtb part (both uses the same patching logic), my bad. Recently devices are starting to move fstabs from ramdisks into dtbs like OP5/OP5T Oreo beta. Since Magisk's dtb verity removal code is broken in v15.1, this causes devices that triggers dm-verity using the new setup to stuck in a bootloop.
Another major update is that new sepolicy rules are added to support stock Samsung ROMs. Samsung users has been complaining MagiskHide broken since the introduction of the refined MagiskHide system, and finally I spent an excessive amount of time and found the root to the issue: SELinux.
Lastly, thanks to @shakalaca joining the forces, there are some devices in the wild using Treble-like split sepolicy setup on a traditional non skip_initramfs devices, this release is updated to support these Frankenstein configurations.

Sorry for the frequent updates recently, but I really want things to work out on all devices. Hopefully this will be the last update in this series of v15.X release, finger crossed!
For a more complete release note, please check v15.0 Release Notes

2018.1.12 Magisk v15.3
Another bug fix update! This should fix a rather small but pretty serious bug that causes only one script would be executed in bootscripts.

To make things not that boring though, I've bring a small suprise that I think no root management apps has done before (at least I'm not aware of) - Fingerprint Authentication for Superuser requests! Devices using Android 6.0+ with a fingerprint scanner, you can enable this in Magisk Manager's settings.

These bug fix releases on stable channel should come to an end, I'll start adding more experimental features/device support and those will be pushed through the beta channel before it hits the next major v16 release.

• Magisk v15.3
  - [Daemon] Fix the bug that only one script would be executed in post-fs-data.d/service.d
  - [Daemon] Add MS_SILENT flag when mounting, should fix some devices that cannot mount magisk.img
  - [MagiskBoot] Fix potential segmentation fault when patching ramdisk, should fix some installation failures
• Magisk Manager v5.4.4
  - Fix dtbo on-boot detection, should follow configured dtbo patching behavior on Pixel 2 devices
  - Add fingerprint authentication for Superuser requests

Lastly for interested developers out there, I've updated the documentations to fully match the latest Magisk v15, please spend some time read through the docs and also the elaborate procedure graphs I've made.

2018.1.13 Hotfix (1531 and v5.5.5):
There is a very minor bug in MagiskBoot, fixed it and updated the zip in the OP.
No notification will be pushed to the stable channel, and users that already have Magisk installed don't need to upgrade.
For Magisk Manager, an update is pushed to fix crashes on Android Lollipop and some devices not following AOSP standards.

2018.2.13 Magisk v15.4
Massive MagiskBoot Improvements
A lot more boot images are supported with magiskboot - I would love to say magiskboot could be the most powerful single binary to handle Android boot images! Huge props to @osm0sis with his assistance and his AIK project for making this possible - we have some plans coming

Massive Magisk Manager Optimizations
I've rewritten Chainfire's zipadjust (originally from OpenDelta project) into Java (also fixed a typo in his code ). This result in the removal of JNI in Magisk Manager, and great simplification in Magisk's building system for signing zips. Also, the portion of dealing with root is migrated to libsu, an Android Library I designed for root app developers, and for an exciting WIP project . I'll officially introduce libsu in a future post very soon, the documentations are not done yet, but developers interested can chime in the code and check out the cool features and designs.
There are also massive improvements in the way Magisk Manager handles the superuser database. It should be much more robust, fixes the bugs people has experienced, and make the repackaging of Magisk Manager (a.k.a hiding Magisk Manager) much more stable and error prone.

Socket Obfuscation
In previous Magisk releases (well, all CM based if not all root solutions), the daemon listens to a specific Unix socket, and requests can be sent via the socket to remotely start a root shell from the daemon and connect STDIN/OUT/ERR to the current terminal/process. So technically speaking, a process can directly talk to the socket instead of calling "su", since what "su" does can be oversimplified as basically establishing a socket connection to the daemon. This means that even if we have MagiskHide enabled, any app can discover the socket entry Magisk uses and detect, or even request root access. Starting from this release, the socket name will be randomly assigned each time the device boots up, so processes with MagiskHide enforced can effectively be blocked from root access.

Magisk Manager v5.6.0 is available through stable channel; Magisk v15.4 is currently in beta, and will soon be pushed to the stable channel once publicly tested.

2018.2.22 Magisk v16.0

F2FS Crash Fix
AOSP upstream updated SQLite to 3.21.0+, and starting from that version introduces a new atomic write ioctl to eliminate the use of journal files. That optimization is only available on F2FS filesystems. For some weird reason (@arter97 thinks it is F2FS bug or SQLite bug) the database setup will fail with a weird error code. I found a way to overcome the issue and so far tests are positive.

Welcome Huawei Treble Devices!
Thanks to @Chris@Honor_USA for reaching out and sent me a View 10 for development, support for Huawei/Honor Treble devices (Mate 10/10 Pro/View 10) is officially added to Magisk! It's quite interesting to see the differences between implementations of Treble

NDK Compiler Bug
Due to complicated reasons, Magisk release binaries are all compiled with the very old NDK r10e. However the x86/x64 compiler contains an optimization bug causing critical strings being stripped out of the binary, which wasn't fixed until r13 when Google switched from GCC to Clang. This causes some bootloops on some devices in v15.4, and by using a workaround, this issue was eliminated.

libsu
Here I officially announce that my Android library for root app developers - libsu, is finally fully documented and ready for a proper release! I extracted all the experience I gained from developing Magisk Manager over the past year and crafted it into an independent library for developers. It was designed to easily share an interactive root shell across the whole application, which many root apps fail to do so since it is pretty complicated to maintain. Using the high level APIs are so simple that you won't even notice you are sharing a shell!
I spent a lot of time re-creating many java.io.* classes so developers can directly use Java to do I/O operations with root access without messing with dirty command-lines. In addition, a lot of effort has put into optimizing the I/O streams so the performance is amazingly fast. It also comes with a bundled busybox binary and supports a lot more advanced feature for experienced developers.
Simple tutorial, example code, and full Javadoc are now all available: https://github.com/topjohnwu/libsu

Huge Announcement
Starting from Feb. 22nd (yes, I'm about to leave in a few hours....), I will start serving the mandatory military service for 4 months. In these 4 months I will be disconnected from the Internet... umm... actually, disconnected from the entire world should be more precise LOL. I worked full time the last few weeks in order to push out some quality stuffs before I leave for quite a long period of time. The submission server is not robust enough for me to deploy it on a remote machine, so the server will be down for most of the time in the following months. Occasionally when I have a few days off in the weekends, I will ramp up the server and gobble through the requests, and maybe check some easy issues if I found the time, but don't expect anything from me.

I hope this release is good enough for my temporary departure. Good bye Internet
Logout.

2018.3.11 Magisk v16.1
I'm supposed to be gone for a few months, but it turns out that I can leave the military camp every weekend, so hey why not do some updates

MagiskBoot Fixes
Thanks to @shakalaca and @worstperson (on Github) submitting patches, several bugs and new device has been supported! I also updated the logic detecting high compression mode, it should now properly detect whether high compression mode is necessary.

Android P Support
The big thing here is Android P Preview 1 support! As usual, a new version of Android means more security updates, so some additional patches are needed to run properly. Some fun things are undocumented weird changes such as weird SQLite behavior, renamed non-platform property contexts, and some tools replaced with new ones.

This version is tested on Pixel XL and Pixel 2 XL on Android P, and also backward tested on Android 5.0, so things should be relatively stable. But since I only have a few hours a week to work on development, I pushed it to public beta before doing a proper release. Gonna rush back to the camp in a few hours, bye guys

2018.3.18 Magisk v16.2
Fix module installation on Android P