Magisk's support for Android Lollipop has been pretty broken for a while without it being noticed. Also, none of the active developers of Magisk have actual hardware to run Android Lollipop. We rely on using the official Android emulator for regression testing on older platforms, however Google never shipped a Lollipop emulator image with SELinux support, leaving us with no option but to drop Lollipop support since we don't feel comfortable supporting Android Lollipop without adequate testing.
Magic Mount, the feature that make modules modify partitions, has gone through a major rewrite. The existing implementation doesn't work well with OEMs injecting overlays into their system using overlayfs. The new implementation fundamentally changes how filesystem mirrors are created, giving us a more accurate clone of the unmodified filesystem.
Magisk allows modules to provide custom SELinux patches by including the file sepolicy.rule. Due to the complicated nature of SELinux patching, the compatibility of this functionality has been pretty spotty; many devices are not supported. In this release, a brand new pre-init partition detection mechanism has been designed to support even more devices. Due to complicated reasons, this detection mechanism cannot be performed in a custom recovery environment.
The new Zygisk API v4 is now live! It comes with new features and a refined PLT function hook API. The implementaton of Zygisk has also gone through some major refactoring, including new code loading/unloading mechanisms and a new PLT function hook implementation.
A significant portion of magiskinit (the critical software that runs before your device boots up) is completely rewritten from scratch. Ever since Android introduced Project Treble in Android 8.0, Magisk has been constantly fighting against the increasingly complex partitioning and early mount setups of all kinds of devices, sometimes with weird OEM specific implementations. It got to a point that magiskinit had become so complicated that few people (including myself!) were aware of every detail, and maintaining this piece of software like this was clearly not sustainable. After many months of planning (yes, this whole re-architecture has been in my head for a long time) and some help from external contributors, a whole new sepolicy injection mechanism is introduced into Magisk, solving the "SELinux Problem" once and for all.
Since this is a full paradigm shift on how Magisk hot-patch the device at boot, several behaviors that many developers implicitly relied on might not exist. For example, Magisk no longer patches fstabs in most scenarios, which means AVB will remain intact; some custom kernels rely on AVB being stripped out for them by Magisk.
Many might not realize, but using a trusted, unmodified Magisk app is really important. Magisk's root daemon treats the Magisk app differently and gives it blanket root access without any restrictions. A modded Magisk app can potentially backdoor your device.
And in case some of you are about to put on your tin foil hats, this is not designed to "vendor lock-in"; the goal is to make sure your root management app comes from the same developer of the underlying root implementation. Magisk's build system allows custom distributors to use its own signing keys, and in addition, I am also providing official debug builds which skips any signature verification for development.
I did something obviously stupid (and worse, don't remember what) and ended up in a situation that Magisk manager wouldn't respond, in the sense it wouldn't show any modules. I tried changing update channels to download another manager but no luck (this was canary manager)
Whatever way your Android supports, open the App info page for your Magisk manager app, force stop the app, and clear its data/storage. Reboot (optional). Now launch the Magisk Manager app. If the problem still persists, follow the steps below.
You can do so from Magisk Manager app by chosing "Uninstall Magisk" at its home page/launching page. While you're at it, also remove the Magisk files and modules saved under /data/adb. I don't know whether they would be automatically removed by Magisk Manager app upon uninstallation, so it doesn't hurt to purge the directory by yourself.
If the uninstall option is not available in Magisk Manager app, than manually restore the stock (unpatched, that is) boot image to your currently active boot slot. You can restore the stock boot image using a custom recovery, or using fastboot, or if su (root access) is still working, than using dd. If you don't have a custom recovery, you may find this Q&A helpful: How do you root a device with Magisk when it doesn't have a custom recovery
Note: if you had installed Magisk using a custom recovery earlier or had upgraded Magisk from Magisk Manager app, you would be having a backup of stock boot image under /data/ with directory name(s) starting as magisk_backup_ followed by some random characters. If you fail to find that backup, than search the internet to get a legitimate full OTA / fastboot image for your currently installed Android build. The boot image there is your stock boot image and can be flashed instead.
Assuming that you have successfully restored the stock boot image and rebooted the device to a running Android, you need to install Magisk again. Magisk is a work in progress, and its preferred method of installation may change in future, so I suggest you follow its FAQ for installation.
If you have followed the installation steps, you should have a working Magisk modified boot image and a companion Magisk Manager app. Try launching the app to see if everything is working as you would want it to be.
Before, when we rooted our Android, we used to have to face up to the problem of having to modify the System folder. The arrival of Android Marshmallow introduced the possibility of not having to do so through alternative methods as well as unstable mods. Magisk Manager APK is a mod manager that allows us to install them from a single interface. Therefore, once we download Magisk Manager Android we can make the most of systemless methods by being able to revert the root process whenever we want. This will help us, for instance, to avoid applications that are blocked on handsets that have been rooted.
However, to be able to work correctly, you're going to need to unlock the bootloader and install the SuperSU application. Nevertheless, it's definitely not a tool for beginners as it's going to demand certain knowledge about how an operating system works.
03c5feb9e7