Module Requirements

Last Updated: October 30, 2021

Below you will find the list of requirements for the Androidacy Modules Repository. These have been largely adapted from the deprecated official Repository guidelines by John Wu, who does not endorse or is otherwise affiliated with the Androidacy Modules Repository. MUST, MUST NOT, SHOULD, SHOULD NOT, and other terms are used as described in RFC2119.

Modules already present in the old Repository have been ported over to the Androidacy Repository, and current versions are not bound by the Androidacy guidelines. Future updates to those modules, and new submissions, MUST follow our guidelines, and updates to any modules MUST comply with the guidelines published at that time. Androidacy is under no requirement to notify module developers of an update to the guidelines, so we advise you to check back regularly.

Androidacy follows a three (3) strike system. The first infraction shall result in a warning issued to the module developer, and no action against their module(s). The second infraction shall result in temporary removal of the offending module(s) until an update is published to remedy the alleged infractions. The third infraction will result in permanent removal of the offending module(s) and at Androidacy’s discretion, further action against the module developer.

Developer requirements

We have some miscellaneous requirements of all developers who contribute to or are part of any Androidacy project, including the repository.

  • Androidacy requires all developers to have an account on file.
  • All developers MUST have up to date contact information.
  • Developers SHOULD have an established history and credibility outside of Androidacy.

Compatibility requirements

To ensure an optimal experience for all users, observe these guidelines:

  • Developers MAY NOT publish any module that has device specific requirements without a) ensuring those requirements are outlined in the appropriate documentation, and b) ensuring installation is not possible on incompatible devices.
  • Developers SHOULD attempt to ensure compatibility with the current stable android version, and attempt to maintain compatibility with all current versions supported by AOSP (Android Open Source Project).
  • Developers MUST have compatibility with the current stable release of Magisk, and SHOULD test against the current Canary (pre-release) release.
  • Developers MUST thoroughly test any release before publishing it.

Template requirements

In order to ensure that modules follow standards set by upstream, we’ve instituted the following requirements:

  • All zips MUST follow the structure outlined here
  • All modules MUST have a descriptive README.md located at the root of the repository.
  • Modules SHOULD publish a changelog letting users know what’s new on each release.

Authorship and originality

As in any open source software, keeping commit history and not blindly copying others is important. Here’s some principles we’d like you to follow:

  • All authorship MUST be preserved.
  • Commit history MUST be preserved.
  • When using another person’s work, no matter how small, credit MUST be given where it’s due.
  • Modules MUST NOT be a copy of or close resemblance of another module already in the Repository.

What modules will and will not be accepted

In order to prevent low quality modules from proliferating the Repository, here’s our expectations regarding what we will and won’t accept:

  • Font or emoji changing modules (where it’s their primary purpose) WILL NOT be accepted. Please instead apply for your font or emoji set to be included in Font Manager.
  • Modules that closely mimic or copy existing modules, whether the other module is in the Repository or not, WILL NOT be accepted.
  • Modules MUST be the submitters own work or be submitted with permission from the author.
  • Simple boot script or prop editing modules SHOULD NOT be submitted but may be accepted at the sole discretion of Androidacy, on a case-by-case basis.

Malicious modules

From time to time, we get requests for inclusion from modules that are either intentionally or unintentionally malicious or harm an end-users experience. To protect our users, follow these guidelines:

  • Modules SHOULD NOT mess with kernel parameters. We believe that is best left up to end-users or kernel developers.
  • Modules MUST NOT collect any users’ personal information such as IMEI, phone number, or any other unique identifier, without explicit consent and a valid purpose.
    • Androidacy will review any modules with extra attention, and may reject any module that collects any information we deem unnecessary for the module’s work.
  • Modules MUST NOT give module developers remote access to the device. There are absolutely no exceptions to this rule, for any reason.
  • Modules MAY be scanned from time to time with a service such as VirusTotal, and any module that raises a red flag with our security vendors will be immediately removed and manually investigated.
    • Confirmed malware or similar will result in an immediate ban from our repository, whether on purpose or not. Please thoroughly check any code you push.

This is the current document for our expectations, and we hope it has been clear and wish you luck in the application process and with maintaining!

Get notified for news and updates?    OK Not now