[Magisk] pndwal:
For those interested in the Magisk inner workings (nuts and bolts):

Evolution of the Android and Magisk booting process and architecture

Android devices can be divided into 3 basic boot types (° represents Magisk Booting steps):

A) - Legacy ramdisk

• Original Android boot method

• Kernel uses initramfs (ramdisk) as rootdir, and exec /init in rootfs to boot

° Pre-Init: magiskinit replaces init as the first program to run, then carrys out the additional Pre-Init processes listed below*

• rootdir is always rootfs

B) - Legacy SAR (System As Root)

• From Pixel 1

• Kernel directly mounts the system partition as rootdir and exec /init to boot

° Pre-Init: magiskinit replaces init as the first program to run, creates early-mount support and switches root to system, then carrys out the additional Pre-Init processes listed below*

• rootdir is always system

C) - 2SI ramdisk SAR (Two Stage Init)

• From Pixel 3 (after A10 DP and retrofit upgrade)

• Kernel uses initramfs (ramdisk) as rootdir and exec /init in rootfs. This init mounts the system partition and uses that as the new (second stage) rootdir, then exec /system/bin/init to boot.

° Pre-Init: Original init in rootfs is patched to execute magiskinit as 2nd stage init. Original init is executed to mount partitions before calling magiskinit (as stage 2 init) to carry out the additional Pre-Init processes listed below*

• Initial rootdir is rootfs, Final rootdir is system

° Further Magisk booting steps​

Pre-Init​

*magiskinit processes continued:

-Magisk services are injected into init.rc

- On devices using monolithic policy, sepolicy is loaded from /sepolicy; otherwise nodes in selinuxfs are hijacked with FIFO, LD_PRELOAD is set to hook security_load_policy and assist hijacking on 2SI devices and a daemon is started to wait until init tries to load sepolicy.

- The original or original second stage init is executed to continue the boot process

- Daemon: Patch sepolicy rules. If “hijack” method is used, patched sepolicy is loaded into kernel, init is unblocked and daemon is exited

post-fs-data​

post-fs-data (when /data is decrypted and mounted) triggers launching of the main Magisk daemon, magiskd, post-fs-data scripts are executed and module files are magic mounted

late_start​

Late in the booting process the class late_start is triggered and Magisk “service” mode is started. (In this mode service scripts are executed)

------------​

Magisk has needed to adapt for SAR and its successor 2SI (a form of, or at least a progression from, SAR) and the way we inject (replace original init with) magiskinit, but forms of system as root exists on all modern Android devices. (SAR should not be confused with gaining superuser rights or root permissions.)

The above is a very simplistic summary of booting methods used in Android devices extrapolated from John's documents linked below.

I highly recommend John's Android Booting Shenanigans as well as Internal Details (despite being listed as "for developers") for anyone wanting the most concise-without-missing-essentials summaries of both Android and Magisk boot and other mechanisms you'll find anywhere, or just some light reading 🙂

For the really adventurous, Developer Guides sheds light on BusyBox, Magisk Module, Boot script and Root Directory Overlay System functions, and Magisk Tools covers usage for the binaries magiskboot, magiskinit, magiskpolicy and magisk as well as the magisk applets resetprop and su.

... Thanks John!

👀 PW