[CLOSED][OUTDATED][2017.2.7][GUIDES & DOCS] Magisk All-In-One Wiki

Status
Not open for further replies.
Search This thread

topjohnwu

Senior Recognized Developer / Inactive RC
Jan 31, 2012
1,849
61,299
Taipei
This thread is outdated and will never be updated
Please check the official Magisk documentation on Github!



Magisk All-In-One Wiki

Table of Contents
  • Module Creation And Online Repos
    • Create your first Magisk Module; Submit to Magisk Module Repo
    • Notes Regarding Magisk Module Repos
  • Magisk Guides and Tricks
    • How Do Magic Mount Behave
    • Manipulate system props (build.prop)
    • Remove files / folders
    • Cache mounts
  • Magisk Details (DEV)
    • sepolicy-inject tool
    • Work flow
    • File structure
    • Boot stages

Module Creation And Online Repos

Create your first Magisk Module; Submit to Magisk Module Repo
Details are all listed in the module template on Github.​

Notes Regarding Magisk Module Repos
Magisk module can be different kinds, for example it can be used to debloat your system; it can be used to install your favorite application into system to give it the privilege of system apps.; it can be a full custom rom; it can also be cool mods like Xposed and root. However I view the "Magisk Module Repo" as a platform to share modules that can be used on lots of devices, preferably universal to all Android devices. Device specific modules are OK if stated clearly in the descriptions, and actually doing something that is non-trivial.
I will moderate the "Magisk Module Repo" in my personal preference and standard, here are some that will not be included:
  • Modules that are too large. A full custom rom, for example, is too large to be hosted on Github effectively. You can share them on XDA forums in your device specific forums
  • Modules that are too trivial. For example: mods that simply just add apps to system; debloating selective apps; doing things that can be done in simple boot scripts. I'll add more here if when I face requests that I consider "trivial"
  • Modules that contains copyright property (unless given permission)
  • Modules that violates XDA rules
 
Last edited by a moderator:

topjohnwu

Senior Recognized Developer / Inactive RC
Jan 31, 2012
1,849
61,299
Taipei
This thread is outdated and will never be updated
Please check the official Magisk documentation on Github!



Magisk Guides and Tricks

How Do Magic Mount Behave
  • Magic Mount by default merges the files in $MODPATH/system into the real /system. You can think as it dirty flashes the contents into /system.
    Existing files will be replaced; new files will be added; will not remove any files
  • Directories under $MODPATH/system that contains a file named ".replace" will NOT merge into the system. It will directly replace the correspond directory in /system.
    In the module template, you can list them in "config.sh", the scripts will create the ".replace" file automatically for you.
    You can think as it wipes the existing folder, and then adds contents to that folder in /system.
    The directory that contains ".replace" will replace the one in /system, all contents originally in the folder will be discarded
  • Adding items to system is relatively expensive, Magisk would need to do many under-the-hood tasks to achieve it (thus, called "Magic Mount")
    Furthermore, the higher level the file is added, the more it effects the overall system
    Only add new items if necessary! Think twice before adding items to /system root!
  • Replacing a whole folder is recommended if viable, it reduces the complicated process and speed up the booting time

Manipulate system props (build.prop)
Since the early days of XDA, people love "build.prop" mods. It can bring cool effects to our devices.
build.prop files are loaded early in the boot process, and once read-in, the values cannot be modified... in theory.
Magisk included a tool called "resetprop", it can modify any system props you want easily.
In the module template, you can set PROPFILE=true, then add your props into the file common/system.prop
Magisk by default reads the system.prop of each module and set the props.
Further resetprop options:
Code:
usage: /data/magisk/resetprop [-v] [-n] [--file propfile] [--delete name] [ name value ] 
   -v :
      verbose output (Default: Disabled)
   -n :
      no event triggers when changing props (Default: Will trigger events)
   --file propfile :
      Read props from prop files (e.g. build.prop)
   --delete name :
      Remove a prop entry

Remove files / folders
  • It is complicated to actually remove a file (possible, not worth the effort). Replacing it with a dummy file should be good enough
    Add an empty file with the same name and path into your module (easy way), or add this code to the updater-script to create it at flash time
    Code:
    # Example: you want to remove /system/media/audio/alarms/Argon.ogg
    # Note: mktouch is a function defined in my updater-script, it is not a standard command!
    mktouch $MODDIR/system/media/audio/alarms/Argon.ogg
  • It is complicated to actually remove a folder (possible, not worth the effort). Replacing it with an empty folder should be good enough
    Add the folder to the replace list in "config.sh" in the module template, it will replace the folder with an empty one

Cache mounts
Some files requires to be mounted much earlier in the boot process, currently known are bootanimation, and some libs (most users won't change them).
You can place your files into the corresponding location under /cache/magisk_mount, Magisk will automagiskally manage selinux contexts, permissions and the mounting for you. For example, you want to replace /system/media/bootanimation.zip, copy your new boot animation zip to /cache/magisk_mount/system/media/bootanimation.zip, Magisk will mount your files in the next reboot​

More to come ...
 
Last edited by a moderator:

topjohnwu

Senior Recognized Developer / Inactive RC
Jan 31, 2012
1,849
61,299
Taipei
This thread is outdated and will never be updated
Please check the official Magisk documentation on Github!



Magisk Details (DEV)

sepolicy-inject
  • Before starting, check the complete document from Chainfire
    SELinux Policy Section in How-To SU
  • The included sepolicy manipulation tool is called "sepolicy-inject", it supports live patching, and also supports policy statements following the same syntax as supolicy:
    Code:
    sepolicy-inject [--live] [--minimal] [--load <infile>] [--save <outfile>] [policystatement...]
    
      --live: directly load patched policy to device
      --minimal: minimal patches for boot image to let Magisk live patch on boot
    
    Supported policy statements:
    
    "allow #source-class #target-class permission-class #permission"
    "deny #source-class #target-class permission-class #permission"
    "auditallow #source-class #target-class permission-class #permission"
    "auditdeny #source-class #target-class permission-class #permission"
    "create #class"
    "permissive #class"
    "enforcing #class"
    "attradd #class #attribute"
    "typetrans source-class target-class permission-class default-class (optional: object-name)"
    
    source-class and target-class can be attributes (patches the whole group)
    All sections (except typetrans) can be replaced with '*' to patch every possible matches
    Sections marked with '#' can be replaced with collections in curly brackets
    e.g: allow { source1 source2 } { target1 target2 } permission-class { permission1 permission2 }
    Will be expanded to:
    allow source1 target1 permission-class permission1
    allow source1 target1 permission-class permission2
    allow source1 target2 permission-class permission1
    allow source1 target2 permission-class permission2
    allow source2 target1 permission-class permission1
    allow source2 target1 permission-class permission2
    allow source2 target2 permission-class permission1
    allow source2 target2 permission-class permission2

Work flow

Code:
                  --------post-fs---------                        
(Device Boots) -> Mount Magisk cache files -> (build.prop and persist prop loads) ->


   -----------------------------post-fs-data---------------------------------
-> Live patch sepolicy -> mount magisk.img -> Preparation -> 5 stage of tasks ->

                        --------------late_start--------------
-> (System Start Up) -> run all service.sh -> Start Magisk Hide
                     -> (Parallel with other processes....)
  • (Preparation) Magisk will travel through all enabled module directories to collect info
  • (1st stage) Mount system (vendor) mirrors. This is used to revert dummy files
  • (2nd stage) Clone the system structure, and mount the dummy directories to provide a dummy skeleton
  • (3rd stage) Mount module items into the system (and dummy skeletons)
  • (4th stage) Execute scripts
  • (5th stage) Mount the mirror items back to the remaining dummy files

File Structures
  • A "Magisk Module" is a subfolder under magisk root directory
  • The structure of a Magisk Module do not have a strict restriction. However, here are some key files / folders:
    Code:
    /magisk
      |
      |-.core               <--- Magisk auto-generated files. Do not mess with them :)
      |  |
      |  | 
      |  |-hosts            <--- This file will be mounted to /system/etc/hosts to enable 
      |  |                       systemless support for AdBlocker apps.
      |  |-magiskhide       <--- This folder holds the hide list and add/rm/list/enable/disable scripts 
      |  |  |                    Include the magiskhide binary
      |  |  |-magiskhide
      |  |  |-hidelist
      |  |  |-add
      |  |  |-rm
      |  |  |-list
      |  |  |-enable
      |  |  |-disable
      |  |
      |  |-su               <--- This folder holds the MagiskSU binaries and scripts
      |  |  |                    Include the magiskhide binary
      |  |  |-su
      |  |  |-magisksu.sh
      |  |  |-sbin_bind     <--- This folder will bind mount to /sbin
      |  |    |-.....
      |  |
      |  |-post-fs-data.d   <--- Place scripts that should be executed at post-fs-data here
      |  |  |-.....
      |  |
      |  |-service.d        <--- Place scripts that should be executed at late_start service here
      |     |-.....
      |
      |
      |-other_module
      |  |-.....
      |
      |-your_module
      |  |
      |  |-auto_mount       <--- If this file exists, auto mount is enabled
      |  |
      |  |-disable          <--- If this file exists, the module is disabled
      |  |
      |  |-remove           <--- If this file exists, the whole module folder
      |  |                       will be removed in the next reboot
      |  |-module.prop      <--- This files stores the info of your module
      |  |
      |  |-system.prop      <--- This file will be read by resetprop
      |  |
      |  |-post-fs-data.sh  <--- This script will be executed in post-fs-data
      |  |
      |  |-service.sh       <--- This script will be executed in late_start service
      |  | 
      |  |-system           <--- If auto mount is enabled, Magisk will "Magic Mount" this folder 
      |  |  |-....
      |  |  |-....
      |  |  |-....
      |  |  |-....
      |  |
      |  |-vendor           <--- Auto generated. A symlink to $MODID/system/vendor 
      |  |                       Dealing with separate vendor partitions
      |  |-.....            <--- Any other files/folders are allowed
      |
      |-another_module
      |  |-.....
      |-...
  • Other important folders (under /dev), these will be created every boot
    Code:
    /dev/busybox    <--- Busybox applet symlinks will be created here
         |-....          Will be bind mounted to /system/xbin if enable busybox in Magisk Manager
         |-....
         |-....
    
    
    /dev/magisk
      |
      |-dummy       <--- Lies all cloned dummy structures
      |  |               Folders in here will be mounted to /system
      |  |-.....
      |
      |-mirror      <--- Lies all mirrors
      |  |
      |  |-system
      |  |  |-....
      |  |
      |  |-vendor   <--- Could be a symlink to /dev/mirror/system/vendor
      |     |-....
      |
      |-mnt         <--- Lies all mounting info
         |
         |-dummy    <--- Lists all dummy mounts
         |  |-....
         |
         |-mirror   <--- Lists all mirror mounts
         |  |-....
         |
         |-system   <--- Lists all /system mounts
         |  |-....
         |
         |-vendor   <--- Lists all /vendor mounts
            |-....

Boot Stages
If you are working on complicated projects, you shall need more control to the whole process.
Magisk can run scripts in different boot stages, you can fine tune exactly what you want to do.
  • post-fs mode:
    • This stage is BLOCKING. Boot process will NOT continue until everything is done, or 20 seconds has passed
    • Happens after most partitions are mounted, except /data
    • Magisk will bind mount items in: /cache/magisk_mount/system (*1)
  • post-fs-data mode:
    • This stage is BLOCKING. Boot process will NOT continue until everything is done, or 60 seconds has passed
    • Happens after /data is ready (including encrypted data)
    • Happens before Zygote is started (which means pretty much everything)
    • /data/magisk.img will be mounted to /magisk
    • Magisk will bind mount items in: /magisk/$MODID/system (*2)
    • Magisk will run script: /magisk/$MODID/post-fs-data.sh
    • Magisk will run scripts in: /magisk/.core/post-fs-data.d
  • late_start service mode:
    • This stage is NON-BLOCKING, it will run parallel with other processes
      Put time consuming but non time critical tasks here. In other modes, the boot process will be stuck if it took too long to finish your tasks.
    • Happens when class late_start is started . Most things are are loaded/loading in this case.
    • Magisk will run script: /magisk/$MODID/service.sh
    • Magisk will run scripts in: /magisk/.core/service.d
(*1) Bind mounting in post-fs only support simple bind mounts, which mean you cannot add files or replace directories.
It will only mount files that exist in the current system.
(*2) Bind mounting in post-fs-data support complex bind mounts. Please refer to the "Magic Mount" section
 
Last edited by a moderator:

anantharam

Senior Member
Apr 6, 2013
193
44
Thanks for this @topjohnwu.
If github is the where all modules need to be hosted, how do we plan on supporting closed source modules?
Or is closed source modules not supported?
 

ibrokemypie

Senior Member
Jul 20, 2016
435
211
@topjohnwu is there any thought about aroma installers being supported? is this already possible? or are you planning to add something similar?
 

topjohnwu

Senior Recognized Developer / Inactive RC
Jan 31, 2012
1,849
61,299
Taipei
Thanks for this @topjohnwu.
If github is the where all modules need to be hosted, how do we plan on supporting closed source modules?
Or is closed source modules not supported?

You can host closed source binary on Github.

@topjohnwu is there any thought about aroma installers being supported? is this already possible? or are you planning to add something similar?

You can flash the Magisk Module template in aroma with the same method to flash SuperSU. However if the module itself is made with aroma, it will not be able to flash in Magisk Manager

I've tried to build a v7-compatible zip file for an app and Magisk Manager kept crashing with the following in its module.prop:

Is it supposed to be a single round number (like a versionCode for Android apps)?

Yes, the versionCode is the similar concept of Android application's version code. It has to be a single number. You can place your long version number into version, which supports any string.
 
  • Like
Reactions: clownchico

priZrakinside

Member
Dec 26, 2013
10
0
i have a problem with MagiskManager 2.0 launch.... app stopped after open it.
Zenfone ZE520KL...
Also, plz help - where can i found new supersu 2.78 for magisk?
 
Last edited:

ahrion

Retired Forum Moderator / Recognized Developer
Jul 19, 2013
3,102
5,125
I need to patch in lines to audio_effects.conf rather than replace the file. Is there any way to do a systemless merge of lines within a conf with Magisk?
 

ryanguy426

Senior Member
Jul 18, 2013
160
44
Hello, I'm trying to bring the OnePlus Camera to Magisk, and I'm having issues. I feel that I understand how to create a Magisk module from following your tutorial on Github, but apparently I don't. I just spent about 25 minutes trying to figure this out on my own, and couldn't.

When I flash my zip, I get error 255 in TWRP. It claims "/tmp/updater" doesn't exist. Magisk Manager also claims it's not a Magisk module when trying to manually add it in the app.

Below is the recovery.log, and link to the Github repo for what I'm working on. Any help is appreciated! :)

Source: https://github.com/ryanguy426/OnePlus-Camera-Magisk
recovery.log (PasteBin): http://pastebin.com/z0B9jaSM
 
  • Like
Reactions: Bintang Krisna
When I flash my zip, I get error 255 in TWRP. It claims "/tmp/updater" doesn't exist. Magisk Manager also claims it's not a Magisk module when trying to manually add it in the app.
Source: https://github.com/ryanguy426/OnePlus-Camera-Magisk
recovery.log (PasteBin): http://pastebin.com/z0B9jaSM

AFAIK If you use the Magisk v7 template (from github), you do not flash resulting ZIP in recovery. Also, I'm not sure if just downloading the ZIP file from github will do, AFAIK doing that creates a nesting folder which is probably why Magisk refuses to add the module.

I can create the correct ZIP and I would have tried it on my phone, but I followed your support link and it leads to the generic Magisk thread and doesn't list specific models it's compatible with, so I refrained.

PS. Fix REPLACE in your config.sh
 
Last edited:

ryanguy426

Senior Member
Jul 18, 2013
160
44
AFAIK If you use the Magisk v7 template (from github), you do not flash resulting ZIP in recovery. Also, I'm not sure if just downloading the ZIP file from github will do, AFAIK doing that creates a nesting folder which is probably why Magisk refuses to add the module.

I can create the correct ZIP and I would have tried it on my phone, but I followed your support link and it leads to the generic Magisk thread and doesn't list specific models it's compatible with, so I refrained.

PS. Fix REPLACE in your config.sh

I haven't created a support thread yet, as XDA doesn't allow placeholder threads. I'll create the thread when the module works.

I'll start over with it, and see if I can get it working. They're for the tips!
 
Sep 14, 2015
5
0
I have created a module that will enable miracast by adding a line to the build.prop. When I try to manually add the module to magisk I get an error saying "This zip is not a magisk module!!" Can someone please tell me what I'm doing wrong.

Here is the module : github.com/blake1029384756/EnableMiracast
 

ibrokemypie

Senior Member
Jul 20, 2016
435
211
I have created a module that will enable miracast by adding a line to the build.prop. When I try to manually add the module to magisk I get an error saying "This zip is not a magisk module!!" Can someone please tell me what I'm doing wrong.

Here is the module : github.com/blake1029384756/EnableMiracast

If you are downloading the zip from github it nests a folder within it which magisk doesnt like, you need to zip up the files in the root of the zip.
 

Iceyogurt

Senior Member
Mar 5, 2013
63
19
I need to patch in lines to audio_effects.conf rather than replace the file. Is there any way to do a systemless merge of lines within a conf with Magisk?
Just make a copy of the file as /magisk/your_mldule/system/etc/audio_effects.conf, and modify the fake aidio_effects.conf which will be mounted during boot.
But the weird thing is that some setprop commands don't work when it is written in post-fs-data or post-fs, at least under Magisk v6 OnePlus 3 Oxygen OS. I have to write the setprop modifications in a fake build.prop instead.
Here is the module that I transplant from guitardedhero's ViPER4Audio_5.4_Stock.zip. Maybe it would help.
BTW: The attachment doesn't work well on v7, it stuck at boot animation. While it works well on v6.
 

Attachments

  • v4a_5.4_stock_magisk_build_v5.3_test.zip
    1.1 MB · Views: 189

ahrion

Retired Forum Moderator / Recognized Developer
Jul 19, 2013
3,102
5,125
Just make a copy of the file as /magisk/your_mldule/system/etc/audio_effects.conf, and modify the fake aidio_effects.conf which will be mounted during boot.
But the weird thing is that some setprop commands don't work when it is written in post-fs-data or post-fs, at least under Magisk v6 OnePlus 3 Oxygen OS. I have to write the setprop modifications in a fake build.prop instead.
Here is the module that I transplant from guitardedhero's ViPER4Audio_5.4_Stock.zip. Maybe it would help.
BTW: The attachment doesn't work well on v7, it stuck at boot animation. While it works well on v6.
Perhaps you might be able to tell me why Magisk Manager isn't recognizing my zip as a Magisk module...https://github.com/therealahrion/Audio-Modification-Framework
 

Iceyogurt

Senior Member
Mar 5, 2013
63
19
Perhaps you might be able to tell me why Magisk Manager isn't recognizing my zip as a Magisk module...https://github.com/therealahrion/Audio-Modification-Framework
It is not easy to find a bug in my mobile browser. I'll try to look through your script more carefully when I get a PC. Now there is a mistake in the config.sh.

Code:
# This is an example
REPLACE="
/system/app/Youtube
/system/priv-app/SystemUI
/system/priv-app/Settings
/system/framework
"

# Construct your own list
REPLACE="
/system/etc
/system/vendor/etc
"

The first variable REPLACE is an example, so just delete it.(oh sorry, I forget it will be revalued because of the second one) And leave the second REPLACE void.
Code:
# Construct your own list
REPLACE=""

Since the value of REPLACE are folders, it mean replace an existing folder with a same-name-folder. The modified fake audio_effects.conf file will be mounted to replace the existing file automatically. No need to replace a whole folder.
 
Last edited:

Iceyogurt

Senior Member
Mar 5, 2013
63
19
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 58
    This thread is outdated and will never be updated
    Please check the official Magisk documentation on Github!



    Magisk All-In-One Wiki

    Table of Contents
    • Module Creation And Online Repos
      • Create your first Magisk Module; Submit to Magisk Module Repo
      • Notes Regarding Magisk Module Repos
    • Magisk Guides and Tricks
      • How Do Magic Mount Behave
      • Manipulate system props (build.prop)
      • Remove files / folders
      • Cache mounts
    • Magisk Details (DEV)
      • sepolicy-inject tool
      • Work flow
      • File structure
      • Boot stages

    Module Creation And Online Repos

    Create your first Magisk Module; Submit to Magisk Module Repo
    Details are all listed in the module template on Github.​

    Notes Regarding Magisk Module Repos
    Magisk module can be different kinds, for example it can be used to debloat your system; it can be used to install your favorite application into system to give it the privilege of system apps.; it can be a full custom rom; it can also be cool mods like Xposed and root. However I view the "Magisk Module Repo" as a platform to share modules that can be used on lots of devices, preferably universal to all Android devices. Device specific modules are OK if stated clearly in the descriptions, and actually doing something that is non-trivial.
    I will moderate the "Magisk Module Repo" in my personal preference and standard, here are some that will not be included:
    • Modules that are too large. A full custom rom, for example, is too large to be hosted on Github effectively. You can share them on XDA forums in your device specific forums
    • Modules that are too trivial. For example: mods that simply just add apps to system; debloating selective apps; doing things that can be done in simple boot scripts. I'll add more here if when I face requests that I consider "trivial"
    • Modules that contains copyright property (unless given permission)
    • Modules that violates XDA rules
    51
    This thread is outdated and will never be updated
    Please check the official Magisk documentation on Github!



    Magisk Guides and Tricks

    How Do Magic Mount Behave
    • Magic Mount by default merges the files in $MODPATH/system into the real /system. You can think as it dirty flashes the contents into /system.
      Existing files will be replaced; new files will be added; will not remove any files
    • Directories under $MODPATH/system that contains a file named ".replace" will NOT merge into the system. It will directly replace the correspond directory in /system.
      In the module template, you can list them in "config.sh", the scripts will create the ".replace" file automatically for you.
      You can think as it wipes the existing folder, and then adds contents to that folder in /system.
      The directory that contains ".replace" will replace the one in /system, all contents originally in the folder will be discarded
    • Adding items to system is relatively expensive, Magisk would need to do many under-the-hood tasks to achieve it (thus, called "Magic Mount")
      Furthermore, the higher level the file is added, the more it effects the overall system
      Only add new items if necessary! Think twice before adding items to /system root!
    • Replacing a whole folder is recommended if viable, it reduces the complicated process and speed up the booting time

    Manipulate system props (build.prop)
    Since the early days of XDA, people love "build.prop" mods. It can bring cool effects to our devices.
    build.prop files are loaded early in the boot process, and once read-in, the values cannot be modified... in theory.
    Magisk included a tool called "resetprop", it can modify any system props you want easily.
    In the module template, you can set PROPFILE=true, then add your props into the file common/system.prop
    Magisk by default reads the system.prop of each module and set the props.
    Further resetprop options:
    Code:
    usage: /data/magisk/resetprop [-v] [-n] [--file propfile] [--delete name] [ name value ] 
       -v :
          verbose output (Default: Disabled)
       -n :
          no event triggers when changing props (Default: Will trigger events)
       --file propfile :
          Read props from prop files (e.g. build.prop)
       --delete name :
          Remove a prop entry

    Remove files / folders
    • It is complicated to actually remove a file (possible, not worth the effort). Replacing it with a dummy file should be good enough
      Add an empty file with the same name and path into your module (easy way), or add this code to the updater-script to create it at flash time
      Code:
      # Example: you want to remove /system/media/audio/alarms/Argon.ogg
      # Note: mktouch is a function defined in my updater-script, it is not a standard command!
      mktouch $MODDIR/system/media/audio/alarms/Argon.ogg
    • It is complicated to actually remove a folder (possible, not worth the effort). Replacing it with an empty folder should be good enough
      Add the folder to the replace list in "config.sh" in the module template, it will replace the folder with an empty one

    Cache mounts
    Some files requires to be mounted much earlier in the boot process, currently known are bootanimation, and some libs (most users won't change them).
    You can place your files into the corresponding location under /cache/magisk_mount, Magisk will automagiskally manage selinux contexts, permissions and the mounting for you. For example, you want to replace /system/media/bootanimation.zip, copy your new boot animation zip to /cache/magisk_mount/system/media/bootanimation.zip, Magisk will mount your files in the next reboot​

    More to come ...
    23
    This thread is outdated and will never be updated
    Please check the official Magisk documentation on Github!



    Magisk Details (DEV)

    sepolicy-inject
    • Before starting, check the complete document from Chainfire
      SELinux Policy Section in How-To SU
    • The included sepolicy manipulation tool is called "sepolicy-inject", it supports live patching, and also supports policy statements following the same syntax as supolicy:
      Code:
      sepolicy-inject [--live] [--minimal] [--load <infile>] [--save <outfile>] [policystatement...]
      
        --live: directly load patched policy to device
        --minimal: minimal patches for boot image to let Magisk live patch on boot
      
      Supported policy statements:
      
      "allow #source-class #target-class permission-class #permission"
      "deny #source-class #target-class permission-class #permission"
      "auditallow #source-class #target-class permission-class #permission"
      "auditdeny #source-class #target-class permission-class #permission"
      "create #class"
      "permissive #class"
      "enforcing #class"
      "attradd #class #attribute"
      "typetrans source-class target-class permission-class default-class (optional: object-name)"
      
      source-class and target-class can be attributes (patches the whole group)
      All sections (except typetrans) can be replaced with '*' to patch every possible matches
      Sections marked with '#' can be replaced with collections in curly brackets
      e.g: allow { source1 source2 } { target1 target2 } permission-class { permission1 permission2 }
      Will be expanded to:
      allow source1 target1 permission-class permission1
      allow source1 target1 permission-class permission2
      allow source1 target2 permission-class permission1
      allow source1 target2 permission-class permission2
      allow source2 target1 permission-class permission1
      allow source2 target1 permission-class permission2
      allow source2 target2 permission-class permission1
      allow source2 target2 permission-class permission2

    Work flow

    Code:
                      --------post-fs---------                        
    (Device Boots) -> Mount Magisk cache files -> (build.prop and persist prop loads) ->
    
    
       -----------------------------post-fs-data---------------------------------
    -> Live patch sepolicy -> mount magisk.img -> Preparation -> 5 stage of tasks ->
    
                            --------------late_start--------------
    -> (System Start Up) -> run all service.sh -> Start Magisk Hide
                         -> (Parallel with other processes....)
    • (Preparation) Magisk will travel through all enabled module directories to collect info
    • (1st stage) Mount system (vendor) mirrors. This is used to revert dummy files
    • (2nd stage) Clone the system structure, and mount the dummy directories to provide a dummy skeleton
    • (3rd stage) Mount module items into the system (and dummy skeletons)
    • (4th stage) Execute scripts
    • (5th stage) Mount the mirror items back to the remaining dummy files

    File Structures
    • A "Magisk Module" is a subfolder under magisk root directory
    • The structure of a Magisk Module do not have a strict restriction. However, here are some key files / folders:
      Code:
      /magisk
        |
        |-.core               <--- Magisk auto-generated files. Do not mess with them :)
        |  |
        |  | 
        |  |-hosts            <--- This file will be mounted to /system/etc/hosts to enable 
        |  |                       systemless support for AdBlocker apps.
        |  |-magiskhide       <--- This folder holds the hide list and add/rm/list/enable/disable scripts 
        |  |  |                    Include the magiskhide binary
        |  |  |-magiskhide
        |  |  |-hidelist
        |  |  |-add
        |  |  |-rm
        |  |  |-list
        |  |  |-enable
        |  |  |-disable
        |  |
        |  |-su               <--- This folder holds the MagiskSU binaries and scripts
        |  |  |                    Include the magiskhide binary
        |  |  |-su
        |  |  |-magisksu.sh
        |  |  |-sbin_bind     <--- This folder will bind mount to /sbin
        |  |    |-.....
        |  |
        |  |-post-fs-data.d   <--- Place scripts that should be executed at post-fs-data here
        |  |  |-.....
        |  |
        |  |-service.d        <--- Place scripts that should be executed at late_start service here
        |     |-.....
        |
        |
        |-other_module
        |  |-.....
        |
        |-your_module
        |  |
        |  |-auto_mount       <--- If this file exists, auto mount is enabled
        |  |
        |  |-disable          <--- If this file exists, the module is disabled
        |  |
        |  |-remove           <--- If this file exists, the whole module folder
        |  |                       will be removed in the next reboot
        |  |-module.prop      <--- This files stores the info of your module
        |  |
        |  |-system.prop      <--- This file will be read by resetprop
        |  |
        |  |-post-fs-data.sh  <--- This script will be executed in post-fs-data
        |  |
        |  |-service.sh       <--- This script will be executed in late_start service
        |  | 
        |  |-system           <--- If auto mount is enabled, Magisk will "Magic Mount" this folder 
        |  |  |-....
        |  |  |-....
        |  |  |-....
        |  |  |-....
        |  |
        |  |-vendor           <--- Auto generated. A symlink to $MODID/system/vendor 
        |  |                       Dealing with separate vendor partitions
        |  |-.....            <--- Any other files/folders are allowed
        |
        |-another_module
        |  |-.....
        |-...
    • Other important folders (under /dev), these will be created every boot
      Code:
      /dev/busybox    <--- Busybox applet symlinks will be created here
           |-....          Will be bind mounted to /system/xbin if enable busybox in Magisk Manager
           |-....
           |-....
      
      
      /dev/magisk
        |
        |-dummy       <--- Lies all cloned dummy structures
        |  |               Folders in here will be mounted to /system
        |  |-.....
        |
        |-mirror      <--- Lies all mirrors
        |  |
        |  |-system
        |  |  |-....
        |  |
        |  |-vendor   <--- Could be a symlink to /dev/mirror/system/vendor
        |     |-....
        |
        |-mnt         <--- Lies all mounting info
           |
           |-dummy    <--- Lists all dummy mounts
           |  |-....
           |
           |-mirror   <--- Lists all mirror mounts
           |  |-....
           |
           |-system   <--- Lists all /system mounts
           |  |-....
           |
           |-vendor   <--- Lists all /vendor mounts
              |-....

    Boot Stages
    If you are working on complicated projects, you shall need more control to the whole process.
    Magisk can run scripts in different boot stages, you can fine tune exactly what you want to do.
    • post-fs mode:
      • This stage is BLOCKING. Boot process will NOT continue until everything is done, or 20 seconds has passed
      • Happens after most partitions are mounted, except /data
      • Magisk will bind mount items in: /cache/magisk_mount/system (*1)
    • post-fs-data mode:
      • This stage is BLOCKING. Boot process will NOT continue until everything is done, or 60 seconds has passed
      • Happens after /data is ready (including encrypted data)
      • Happens before Zygote is started (which means pretty much everything)
      • /data/magisk.img will be mounted to /magisk
      • Magisk will bind mount items in: /magisk/$MODID/system (*2)
      • Magisk will run script: /magisk/$MODID/post-fs-data.sh
      • Magisk will run scripts in: /magisk/.core/post-fs-data.d
    • late_start service mode:
      • This stage is NON-BLOCKING, it will run parallel with other processes
        Put time consuming but non time critical tasks here. In other modes, the boot process will be stuck if it took too long to finish your tasks.
      • Happens when class late_start is started . Most things are are loaded/loading in this case.
      • Magisk will run script: /magisk/$MODID/service.sh
      • Magisk will run scripts in: /magisk/.core/service.d
    (*1) Bind mounting in post-fs only support simple bind mounts, which mean you cannot add files or replace directories.
    It will only mount files that exist in the current system.
    (*2) Bind mounting in post-fs-data support complex bind mounts. Please refer to the "Magic Mount" section
    4
    Just Install SuperSU from PlayStore problem solved.
    Which is a totally appropriate response in the Magisk forum. Before anyone mentions it I know SuperSU can work with Magisk, but seriously, if the OP wanted to install SuperSU then he wouldn't be asking why Magisk isn't working for him.
    3
    Hi...all,
    I want to build Magisk from source.
    Please Guide link me.

    •••

    It's literally in the README... https://github.com/topjohnwu/Magisk/blob/master/README.MD