Mastodon for Android: build, distribution and the tight contribution policy

Mastodon servers only: the team closes off-topic compatibility pull requests

This is the official Android client for Mastodon. The Introduction section of the README makes the scope explicit: the app is intended to be used with Mastodon servers, and the team does not have bandwidth to ensure compatibility with other server software. Pull requests focused on that compatibility goal will be closed, because the project has defined compatibility with non-Mastodon ActivityPub implementations as out of scope.

That boundary matters for anyone running or connecting to a server that extends the Mastodon API or uses compatible but distinct software. Features or behaviors specific to those servers are not something this project intends to handle, regardless of how common those servers are.

v2.13.3, published on 2026-09-04, is the current version, the source is under the GPL-3.0, and the last push was on 2026-10-06.

Google Play, F-Droid and a direct APK are the three install paths

End users have three options for getting the app. Google Play carries it at org.joinmastodon.android. F-Droid carries the same identifier at f-droid.org/packages/org.joinmastodon.android/. Beyond those two, the README links to the project's GitHub download assets for a direct APK.

Each path suits a different context. F-Droid serves users who avoid Google services. Sideloading the direct APK allows pinning to a specific version. No documentation describes which channel receives updates first, and no checksum guidance accompanies the direct APK option. Anyone using that path should cross-check the file against the corresponding tag on GitHub before installing.

The package identifier org.joinmastodon.android is the same across all three paths, so a device that switches channels must uninstall and reinstall rather than update in place.

JDK 17 is the only non-standard build requirement

Building the app requires JDK 17 or newer because the code uses Java 17 language features. Beyond that version floor, the build is standard Gradle and can run in Android Studio or from the command line:

./gradlew assembleRelease

After the JDK 17 requirement, the README calls the rest of the build "pretty standard," with that phrase appearing in the same paragraph as the version floor. The top-level entries show build.gradle, settings.gradle, gradle.properties, gradle/, gradlew and gradlew.bat, with the application module under mastodon/. No signing configuration, ProGuard settings, or alternate build configurations are documented anywhere in the README.

UI contributions face a core team design review and are mostly rejected

User interface changes do not follow the standard pull request path. They go through a design process involving core team review, and the README explicitly says most UI changes of this kind will not be accepted as community contributions. For the rare ones that do pass, they will take time to go through review.

This keeps the app's look and behavior under centralized control, which makes sense for an official client. Practically, a developer who wants a UI change that the upstream project would reject has one option: fork the source under its copyleft terms and distribute a rebranded build. Forking is permitted under the source terms but the trademark section, covered in the next section, requires the fork to use a name and icon that are distinct from Mastodon's.

Code changes that are not UI changes are not mentioned under this restriction. The Contributing guide lives at github.com/mastodon/.github/blob/main/CONTRIBUTING.md, in a separate organization-level repository.

Translations use Crowdin; pull requests that modify non-English string files are blocked

Localization follows a separate path from code contributions. Contributors who want to translate the app into their language go to crowdin.com/project/mastodon-for-android. A Crowdin badge at the top of the README shows the current translation progress. If a language is missing from the Crowdin project, the README asks for a GitHub issue to add it rather than a direct contribution.

The crowdin.yml file at the repository root configures the Crowdin integration. Pull requests that modify strings.xml files for any language other than English are not accepted; non-English strings are expected to come through Crowdin, not through the pull request queue. This separates the translation workflow entirely from code review, which means translation reviewers and code reviewers work in different systems.

Modified forks need a rebrand: the Mastodon name and logo are trademarks

The source can be forked and redistributed under the project's copyleft terms, which require derivative builds to be available under the same terms. The README adds a separate trademark requirement on top of that: the Mastodon name and logo are trademarks of the Mastodon non-profit organization. Any modified version that is distributed must use a unique name and icon and must not mistakenly imply official connection with or endorsement by that organization.

These two requirements operate independently. Meeting the source-sharing requirement of the copyleft terms is not enough on its own. A fork that ships under the name Mastodon or with the recognizable elephant icon would conflict with the trademark terms regardless of how the source is handled. Both need to be satisfied before distributing a modified build to other users.

Gemfile and fastlane in the repository root signal an automated publication pipeline

The top-level repository entries include Gemfile, Gemfile.lock and a fastlane/ directory alongside the standard Java build files. Gemfile and Gemfile.lock are Ruby dependency manifests, and their presence in an Android project whose primary language is Java indicates that at least one Ruby-based tool is part of the workflow. fastlane is a deployment automation framework used in mobile development, and the fastlane/ directory holds its configuration. An updateChangelog.sh script at the repository root is another component of that tooling.

That matters when setting up a full build environment. Running ./gradlew assembleRelease needs only JDK 17 and an Android SDK. Reproducing the full automated pipeline that produces the signed, distributed APKs requires the Ruby runtime, the bundler gem, and the fastlane configuration as well. Nothing in the repository documents what fastlane commands are run or what they produce.

Editorial conclusion

Use this app if you need an official Android Mastodon client on Google Play or F-Droid and are willing to work within tight contribution limits. Skip it if your server runs non-Mastodon ActivityPub software, since the project explicitly limits scope and closes off-topic contributions. Before contributing UI changes, read the guide at github.com/mastodon/.github/blob/main/CONTRIBUTING.md: most are rejected. Any modified build you distribute must carry a different name and icon to avoid trademark conflicts with the Mastodon non-profit.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. mastodon/mastodon-android on GitHub
3. Project website
4. README
5. Releases