My name is Simon Müller and I have been modding my Android devices for over 9 years now.
As such, I’ve learnt a lot along the way, and would like to clear up some confusion and debunk some rumours that are often thrown around in the Android community, but which I also see here quite often.
This is a dynamic post, by which I mean that the content of this post may change over time - things will be added, removed, modified, etc. based on new information, corrections, etc.
With that out of the way, let’s get started
|Rootless||Without having to modify
|Reversible||Changes made can be easily undone|
The most used root solution in the Android world, which often gets confused for being just that and not more. Magisk is made up of a couple of components, primarily:
|MagiskSu||Root / Superuser Access|
|Magisk Modules||Make rootless and reversible changes to files on your system|
|MagiskBoot||A complete tool for unpacking, modifying and interacting with Android boot images.|
|Zygisk||Run code directly inside Android processes|
Put these four together and you get Magisk - The Magic Mask for Android
It’s a complete toolkit for modifying almost anything and everything on your Android device without ever directly modifying the system partitions, and it started the “trend” of rootless modding solutions on Android.
Many consider Magisk to be incompatible with Android Verified Boot, but this is incorrect.
AVB 2.0 expects the boot image to be signed either by the OEM or with keys set by the user. If you make a Magisk-patched boot image and sign it correctly, you can run Magisk with a locked bootloader and working dm-verity and verified boot. A project that implements this is AVBRoot
KernelSU is a new(er) superuser and module loader implementation that runs in the Linux kernel instead of the Magisk approach of adding extra init scripts and binaries to the boot image.
It is intended to be used with a relatively new Android feature called Generic Kernel Images (more below), which allows drivers and device-specific libraries to be decoupled from the Linux kernel.
It shares some features with Magisk, most notably the root/super-user aspect (duh) and the ability to install modules to modify system files reversibly and rootlessly. While it doesn’t support Zygisk or similar out of the box, an additional module can be installed to add Zygisk support to KernelSU.
Like Magisk, KernelSU can be used with Android Verified Boot using something like AVBRoot. The same conditions apply to KernelSU as to Magisk.
In an effort to make porting newer Linux kernels easier, Google has separated device drivers from the Linux kernel. This means that the Linux kernel used behind the scenes in Android can be easily updated and modified separately.
One project that takes advantage of this is KernelSU, which provides GKI images with root access.
Around the time Android 10 was launched, Google introduced a new idea called the “super partition”. This is a single partition that includes various parts of the Android operating system, including the
system partition or
vendor partition, which can be resized dynamically as required. This was implemented in preparation for another feature called “Virtual A/B Partitioning”, which will be explained later.
Changing super partitions requires a new function known as “fastbootd” or “Fastboot in Userspace”, which is further elucidated below.
The idea is very straightforward: copy the “system” and “vendor” partitions so that one is being utilized while the other is not. This is to update the inactive partition, then switch the active partition between A and B or the other way around when restarting. Updates are quicker after restarting, without the need for lengthy installation times. Yet, this additionally implies that the system’s size is doubled.
Virtual A/B Partitioning aims to enable uninterrupted system updates without the need for double the storage space, by utilizing Super Partitioning. This method involves creating a substitute B partition for updates, which is then switched with the original partition layout upon rebooting
Performing specific tasks through a Terminal in the background, particularly those that demand root access, can be tedious for app developers and can also involve violating the Android Security Model. Which is why the Shizuku App along with Shizuku API was designed to aid App developers can use this tool to incorporate various functions that would typically require the use of ADB or Root. The tool provides a Java API, eliminating the need for Terminal commands in the background.
In practice, you can run Shizuku by connecting to your PC and using actual ADB once, or use Android’s “wireless debugging” feature to do it completely without a PC (Android 11 and above).
Note that if you restart your device, you need to run Shizuku again.
This is basically the alternative for rooted devices to Shizuku. It uses the Shizuku API by utilizing Magisk’s Zygisk function, injecting code directly into Android. This gives it full integration with the system. In addition, because it runs on top of a Magisk / KernelSu module, it has extra permissions to perform some functions that Shizuku alone cannot.
Unlike Shizuku, Sui does not need to be rerun when restarting or turning off the device since it is integrated through Magisk.
Custom Kernels modify the Linux Kernel in Android by adding extra patches that help with tasks such as overclocking, supporting KernelSU or OverlayFS, and more. These Kernel Managers are usually used to handle them.
Kernel Management Apps are basic programs that help you control multiple kernel features, such as CPU and GPU clock speed, I/O settings, and others. They often provide features to check and enhance battery performance or run scripts, which can be set to run automatically when the device is turned on.
- Added Shizuku, Sui, Custom Kernels and Kernel Managers sections
- Added Sections about A/B Partitioning, Virtual A/B and Super Partitioning