Magisk, a suite of open source tools for customizing Android (definition taken from the official GitHub repository), is considered by many android enthusiasts as the most complete and feature-rich rooting solution for Android devices. With millions of total downloads and still counting from its official release page, Magisk is miles ahead of all other rooting solutions available in the market. This number will again increase if you count the downloads from several unofficial websites that are aiming to monetize the popularity of that open source project.
Magisk Modules
Other than providing a free, open-source, and extremely powerful rooting solution, Magisk installation in an android device also comes with a feature-complete BusyBox binary (a software suite that provides several Unix utilities as a single executable file) as well as a highly versatile module concept. The advantages of Magisk and its system-less behavior have been extensively discussed in our previous articles. A lot of users still (blindly) believe that the concept of the Magisk module is too complicated for them. Despite it being somewhat true from the development side, setting up a module to make some basic tasks on a Magisk powered device is pretty simple and straightforward. Therefore, the focus of this article is completely devoted to teaching our readers to manually create his/her first Magisk module, locally within the mobile device.
Magisk modules allow one to easily modify otherwise untouchable (that is read-only) partitions on an android device, such as the /system or /vendor. The real efforts to achieve the above task is extremely tremendous and beyond the scope of this article. Thanks to the developer of Magsik for keeping everything as simple as possible, a root user can achieve this task without much hassle by following a few simple steps. We will now discuss the necessary steps to be done to successfully create a Magisk module in the following section.
Creating a Module
Technically, Magisk modules are folders bearing certain structures placed inside the module path of Magsik (/data/adb/modules). Magisk Manager (the official application to manage Magisk) shall consider each folder found inside the above-mentioned path (we will represent this path as MODPATH in this article) as a module as long as it satisfies the necessary conditions. The most important condition is the existence of “MODPATH/module.prop” with the following contents.
- “id” – a string matching the regular expression of ^[a-zA-Z][a-zA-Z0-9._-]+$. Technically, the unique identifier of a module. It is highly advisable to keep this id the same as that of the MODPATH (that is, the name of folder placed inside /data/adb/modules) especially if you wish to see your module in the official Magisk Module Repository. There are few more requirements that need to be considered before deciding an id and are available in the official documentation.
- “name” – another string, which is literally, the name of the module. This string will be displayed in the module section of Magisk Manager.
- “version” – a string representing the version name of your module. It could include alphabets, numbers, or special characters, such as a ‘dot’ and many more. Moreover, this string will also be displayed in the module section of Magisk Manager.
- “versionCode” – an integer (and the only integer found on this file) mainly used for Magisk Manager to decide the update status of your module. For a module already available in the official Magisk Module Repository, this integer will be occasionally compared with the one from the respective url.
- “author” – the name of the developer or the company behind the module.
- “description” – a short description about your module in a single line (though you can use the Unix style page breaks).
A more realistic example is provided below
id=TechArena name=Tech Arena version=v1.0 versionCode=1 author=sunilpaulmathew @ Tech Arena description=An example module created by Tech Arena for the purpose of demonstration
Upon placing a “module.prop” file with the above content inside “/data/adb/modules/TechArena” (that is, the MODPATH in our case), the module section of Magisk Manager will display a new module as seen in the screenshot.
Use of Modules?
Now, the question is what kind of stuff a Magisk module really offers. In fact, the answer is what not. For an advanced user with a deep knowledge on the android ecosystem, or someone with a strong base on the Unix command line, can do a whole bunch of things without really touching the dedicated and read-only file systems of their device. Some of the examples includes
- Debloat unwanted system apps (or basically any system files) in a system-less manner by placing a dummy file or folder (please see our earlier article for more details).
- Manipulating the “build.prop” of your device by creating “MODPATH/system.prop” containing the new values.
- Executing shell commands on device booting, either in an early stage (post-fs-data mode), or a later stage (late_start service mode), by placing a “post-fs-data.sh” or a “service.sh” inside the MODPATH.
- Much more things that are probably beyond the scope of this article.
Fortunately, the official developer guide provided by the Magisk development team listed a whole lot of stuff capable to achieve by a Magisk module. Please be noted that the creation of an installable (via Magisk Manager or a custom recovery) module requires little more work and is also found on the developer guide. It is highly advised to read the same at https://topjohnwu.github.io/Magisk/guides.html
