GMR Guidelines

Note: You can browse and install those modules via the MMRL and MRepo project.

Module Submissions

Create an issue on this repository with [Module] <Your module's name> in the title and include the link to your repo in the content, then wait for a moderator to approve or deny your module. Once approved, a moderator add your module. You still maintain your personal repo.

Submission Guidelines

We want to make sure that there are no dangerous modules on the repo. Please abide by these guidelines.

General Guidelines

  • Your module must be a valid Magisk/Zygisk module. See the Developer Guide for more info.
  • Your module must have a README.md file in English with information about the module.
  • Device-specific modules are allowed. Make sure to mention that they are device-specific in the README.
  • "Trivial" modules are allowed. This includes simple boot scripts.
  • No malicious modules (deleting core files, breaking system intentionally, adware, spyware, or any kind of module harmful to the end user).
  • No broken modules (doesn't do what it says it will, or doesn't define correctly compatible devices).
  • Module ID must match repo name. In the event that this isn't the case, your new module repo's name will be the same as the module ID.
  • The issue author must be the owner of the module being submitted, or have permission from the owner.

Source Code Guidelines

  • You must provide the source code for any executables or APK files included in your submission. If you absolutely need to compile your code, please provide reproducible build instructions. An exception can be made for modules that provide compiled packages/binaries from trusted sources such as recognized developers on the Play Store. In such a case, you cannot modify the provided APKs unless doing so does not infringe on the author's copyright and you must provide the source code/APKtool configuration for modifications performed, if any.
  • You must not obfuscate the source code of the scripts and ModConf scripts you provide or any binaries/packages provided unless you are providing a trusted third-party's binary/package where the source has been obfuscated by the third-party at the source.

You can provide the source code in various ways, including, but not limited to:

  • On the project's Wiki page
  • As a separate repository
  • On a separate, empty branch
  • Directly in the main branch, with instructions in customize.sh that delete it during installation

We recommend that you publish your module under a license that explicitly permits redistribution of the software, such as the GPLv3 license. Any other FOSS license should work as well. Make sure the license is compatible with all code/binaries you provide — this is especially important if you provide a proprietary package with your module.

Concluding remarks

It is worth noting that the final approval decision comes from our moderators. If they do not see your module as being fit for the repo, they have the choice to deny it. However, they are encouraged to stay unbaised when approving or rejecting modules.

Failure to abide by the guidelines will be pointed out after moderator review. In cases of larger problems, you may be asked to re-submit the module after corrections in a new issue. Infractions on the "no malicious modules" guideline (or straight up distributing malware) will result in a permanent ban from submitting new modules as well as the removal of ones previously submitted by the offender.

You should maintain your module for as long as possible and remove your repository if it stops working completely and you can't maintain it. We may perform changes without developer approval on any broken modules that are abandoned by their maintainers. This only includes simple fixes, heavily broken, unmaintained modules will simply be deleted.

These guidelines are effective as of 2024-03-07