Magisk uninstaller 20201228 zip - Magisk Manager (2024)

guides.md

Notes

– When your module is downloaded with Magisk Manager, `update-binary` will be **forcefully** replaced with the latest [`module_installer.sh`](https://github.com/topjohnwu/Magisk/blob/master/scripts/module_installer.sh) to ensure all installer uses up-to-date scripts. **DO NOT** try to add any custom logic in `update-binary` as it is pointless.
– Due to historical reasons, **DO NOT** add a file named `install.sh` in your module installer. That specific file was previously used and will be treated differently.
– **DO NOT** call `exit` at the end of `customize.sh`. The module installer would want to do finalizations.

Submit Modules

You can submit a module to **Magisk-Module-Repo** so users can download your module directly in Magisk Manager.

– Follow the instructions in the previous section to create a valid installer for your module.
– Create `README.md` (filename should be exactly the same) containing all info for your module. If you are not familiar with the Markdown syntax, the [Markdown Cheat Sheet](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) will be handy.
– Create a repository with your personal GitHub account, and upload your module installer to the repo
– Create a request for submission via this link: [submission](https://github.com/Magisk-Modules-Repo/submission)

Module Tricks

Remove Files

How to remove a file systemless-ly? To actually make the file *disappear* is complicated (possible, not worth the effort). Replacing it with a dummy file should be good enough! Create an empty file with the same name and place it in the same path within a module, it shall replace your target file with a dummy file.

Remove Folders

Same as mentioned above, actually making the folder *disappear* is not worth the effort. Replacing it with an empty folder should be good enough! A handy trick for module developers is to add the folder you want to remove into the `REPLACE` list within `customize.sh`. If your module doesn’t provide a corresponding folder, it will create an empty folder, and automatically add `.replace` into the empty folder so the dummy folder will properly replace the one in `/system`.

Boot Scripts

In Magisk, you can run boot scripts in 2 different modes: **post-fs-data** and **late_start service** mode.

– post-fs-data mode
– This stage is BLOCKING. The boot process is paused before execution is done, or 10 seconds have passed.
– Scripts run before any modules are mounted. This allows a module developer to dynamically adjust their modules before it gets mounted.
– This stage happens before Zygote is started, which pretty much means everything in Android
– **Run scripts in this mode only if necessary!**
– late_start service mode
– This stage is NON-BLOCKING. Your script runs in parallel along with the booting process.
– **This is the recommended stage to run most scripts!**

In Magisk, there are also 2 kinds of scripts: **general scripts** and **module scripts**.

– General Scripts
– Placed in `/data/adb/post-fs-data.d` or `/data/adb/service.d`
– Only executed if the script is executable (execution permissions, `chmod +x script.sh`)
– Scripts in `post-fs-data.d` runs in post-fs-data mode, and scripts in `service.d` runs in late_start service mode.
– Modules should **NOT** add general scripts since it violates encapsulation
– Module Scripts
– Placed in the folder of the module
– Only executed if the module is enabled
– `post-fs-data.sh` runs in post-fs-data mode, and `service.sh` runs in late_start service mode.
– Modules require boot scripts should **ONLY** use module scripts instead of general scripts

These scripts will run in Magisk’s BusyBox `ash` shell with “Standalone Mode” enabled.

Root Directory Overlay System

Since `/` is read-only on system-as-root devices, Magisk provides an overlay system to enable developers to replace files in rootdir or add new `*.rc` scripts. This feature is designed mostly for custom kernel developers.

Overlay files shall be placed in the `overlay.d` folder in boot image ramdisk, and they follow these rules:

1. All `*.rc` files in `overlay.d` will be read and concatenated **AFTER** `init.rc`
2. Existing files can be replaced by files located at the same relative path
3. Files that correspond to a non-existing file will be ignored

In order to have additional files that you want to reference in your custom `*.rc` scripts, add them in `overlay.d/sbin`. The 3 rules above does not apply to everything in this specific folder, as they will directly be copied to Magisk’s internal `tmpfs` directory (which used to always be located at `/sbin`).

Due to changes in Android 11, the `/sbin` folder is no longer guaranteed to exist. In that case, Magisk randomly generates the `tmpfs` folder. Every occurrence of the pattern `${MAGISKTMP}` in your `*.rc` scripts will be replaced with the Magisk `tmpfs` folder when `magiskinit` injects it into `init.rc`. This also works on pre Android 11 devices as `${MAGISKTMP}` will simply be replaced with `/sbin` in this case, so the best practice is to **NEVER** hardcode `/sbin` in your `*.rc` scripts when referencing additional files.