submission

What the submission repo is

The submission repository is the entry point for publishing Xposed modules into the Xposed-Modules-Repo organization. Rather than asking authors to set up infrastructure themselves, it uses a bot driven workflow. To submit a module, you open an issue with the title [submission] packagename, where packagename is the package name of your module. The bot then automatically creates a new repository for that module and invites you to be its admin. This keeps the publishing path uniform across every module in the org and removes the manual setup that would otherwise slow contributors down. The README also covers transfers: if you already have a repo you want to move into the org, you open an issue titled [transfer] packagename and transfer ownership of your original repo to the organization. The approach is deliberately simple, since the only required action from a developer is a well-formed issue. The repository metadata records 127 stars and 25 forks, with a last update on 2026-08-24, showing steady interest in the Android modding ecosystem the org serves. For a module author the benefit is clear: no servers to run and no custom CI to wire up before their work appears in the public catalog that the organization maintains for end users. Because updates trigger a build that shows the module within about five minutes, authors see their changes reflected quickly after they publish a correctly tagged release with the apk attached.

Repository structure and content

The README specifies what each module repository should contain. The title is the package name of the module, such as com.example.xposedmodule, and the description is the module's display name. Collaborators list the authors, and the release title is the version name while the release content is the changelog. The release tag follows a version code and version name format, and if you create the release along with apk assets the bot updates the tag automatically. The repository content includes a SUMMARY that shows on the front page and a README.md with the full description of the module. The README points to an example repository for the full set of available meta files. Because the structure is fixed, the org can render every module consistently and surface the same fields on its listing pages. This discipline is what lets the bot build a coherent catalog from many independent authors without a custom editorial step. The cost is that contributors must follow the naming and tagging rules exactly for their module to appear and update correctly. The example repository gives a concrete template that removes most of the guesswork about which files and fields are expected for a compliant submission. The README warns that an incomplete repository will not be shown at all, so authors must fill in the required meta files before their module appears in the public catalog.

Update behavior and caveats

The README explains how updates flow once a module is in the org. Updating your repository automatically triggers a build and the module shows up within about five minutes. The important note is about tagging: if you submit a release with the apk, the bot updates your tag automatically, but if you edit a release by only changing the apk, the bot cannot detect that edit and the tag will not update, because GitHub webhooks do not report asset changes reliably. The practical advice is to always submit a release with a valid apk so the version stays in sync. It also warns that an incomplete repository will not be shown at all, so authors must fill in the required meta files. These rules exist because the system is automated end to end and depends on GitHub's event signals. The repository carries no stated license in the metadata, which is typical for an organizational submission helper rather than a shippable library. For an Android user browsing the org, the result is a continuously rebuilt catalog of modules where each entry's version and changelog come straight from the author's tagged releases, and a correctly tagged apk is what keeps that listing accurate over time. A transfer path lets an existing repo move into the org through a titled issue, after which ownership is handed to the organization and the bot takes over the upkeep.

Editorial conclusion

The repository records 127 stars and a last update of 2026-08-24, and the README describes a bot that creates a module repo from a single submission issue.