How To: Develop a Magisk Module for Injecting Custom System Services and Daemons

Introduction to Magisk Modules and System Service Injection

Magisk has revolutionized Android customization by providing a powerful, systemless framework for modifying your device. Its elegance lies in its ability to inject changes into the boot image without altering the system partition, thus preserving the integrity of over-the-air (OTA) updates. Beyond simple modifications, Magisk modules offer an unparalleled opportunity to inject custom system services and daemons, running processes in the background with elevated privileges to perform complex, persistent tasks. This advanced guide will walk you through the intricate process of developing such a module, enabling you to run your custom logic at boot time, effectively turning your Android device into a more capable, specialized system.

Prerequisites and Tools

Before diving into module development, ensure you have the following:

Rooted Android Device with Magisk: Essential for flashing and testing your module.
Basic Linux Shell Scripting Knowledge: Understanding variables, loops, conditional statements, and common commands is crucial.
Android Debug Bridge (ADB): For interacting with your device, pushing files, and debugging.
Text Editor: Any code editor (VS Code, Sublime Text, Notepad++) will suffice.
ZIP Archiver: For packaging your module correctly.

Understanding the Magisk Module Structure

A Magisk module is essentially a ZIP archive containing a specific directory structure and a few key files. Magisk uses these files during installation and boot to apply your desired modifications systemlessly. Understanding this structure is fundamental to developing effective modules.

Key Module Files and Directories

module.prop: This file contains essential metadata about your module, such as its ID, name, author, and description. Magisk Manager uses this information.
customize.sh: An optional but powerful script executed during the module’s installation. It can perform custom checks, modify files, or install binaries.
post-fs-data.sh: Executed very early in the boot process, right after the /data partition is mounted but before Zygote starts. This is ideal for early file system modifications or setting up symlinks.
service.sh: This script is executed much later in the boot process, after the Android framework (including Zygote) has fully started. This is the primary location for initiating long-running services or daemons, as the system environment is more stable.
system/: This directory (and its subdirectories like system/bin, system/etc) contains files that Magisk will overlay onto the real /system partition. For injecting daemons, you might place your daemon binaries or scripts here.
META-INF/: Contains standard ZIP archive metadata for Magisk’s installer. You typically don’t need to modify its contents directly.

Crafting Your Custom Daemon/Service

Our custom daemon will be a simple shell script that runs continuously in the background, performing a placeholder task. For a real-world scenario, this script could monitor system events, modify network configurations, or interact with specific hardware.

Example Daemon Script (`myservice.sh`)

Create a file named myservice.sh inside a directory, for example, /system/bin/. This script will log a message every 10 seconds to demonstrate its persistent operation.

#!/system/bin/sh# This is our custom daemon scriptTAG="MyCustomService"LOG_FILE="/data/local/tmp/myservice.log"# Ensure log file exists and is writableif [ ! -f "$LOG_FILE" ]; then  touch "$LOG_FILE"  chmod 666 "$LOG_FILE"fi# Loop indefinitelywhile true; do  log_message="$(date +'%Y-%m-%d %H:%M:%S') - My custom service is running!"  echo "$log_message" >> "$LOG_FILE"  log -p i -t "$TAG" "$log_message"  sleep 10done

This script logs to both a file and Android’s `logcat`. Remember to make it executable:

chmod +x /system/bin/myservice.sh

Integrating the Daemon with Magisk’s `service.sh`

The service.sh script is the entry point for starting your daemon systemlessly. It runs after most of the system has initialized, providing a stable environment. We will use it to call our myservice.sh script, ensuring it runs in the background and is not terminated when service.sh finishes.

Modifying `service.sh`

Create a file named service.sh in the root of your module directory (/service.sh).

#!/system/bin/sh# This script is executed on boot after Zygote has started# Set paths to ensure our custom binary is foundMODDIR=${0%/*}BIN_PATH="$MODDIR/system/bin"# Add our module's bin directory to PATH for convenienceexport PATH="$BIN_PATH:$PATH"# Wait for boot completion. This is optional but can prevent race conditions.while [ "$(getprop sys.boot_completed)" != "1" ]; do  sleep 1fi# Start our custom service as a background process using nohupnohup "$BIN_PATH/myservice.sh" > /dev/null 2>&1 &

Let’s break down the critical line:

nohup: This command ensures that the process continues to run even if the terminal or parent process (service.sh) exits. It also redirects output that would normally go to the terminal to a file named `nohup.out` by default.
> /dev/null 2>&1: This redirects both standard output (> /dev/null) and standard error (2>&1) to /dev/null, preventing the creation of large log files from the nohup command itself.
&: This crucial symbol runs the command in the background, allowing service.sh to complete without waiting for myservice.sh.

Ensure service.sh is also executable:

chmod +x /service.sh

The `module.prop` File

This file provides Magisk Manager with information about your module. Create module.prop in your module’s root directory.

id=customserviceinjectname=Custom System Service Injectorauthor=Your Namedescription=Injects a custom background service at boot.version=v1.0versionCode=10minMagisk=20400

Packaging and Installation

With all the components in place, it’s time to package your module into a flashable ZIP file.

Module Directory Layout

Your module directory should look something like this:

customservice_module/├── module.prop├── service.sh└── system    └── bin        └── myservice.sh

Creating the ZIP Archive

Navigate to the parent directory of customservice_module in your terminal and create the ZIP archive:

zip -r customservice_module.zip customservice_module/

Flashing via Magisk Manager

Transfer customservice_module.zip to your Android device.
Open Magisk Manager.
Go to the Modules section.
Tap

Android Mobile Specs & Compare Directory

Are you researching mobile hardware properties, processor SoCs, GPU chipsets, or RAM configurations? Access our complete specs catalog to compare up to 5 devices side-by-side!
Compare Devices Specs →