# Wikimedia Commons Android app: uploading photos to Commons from a phone > The Wikimedia Commons Android app is a Kotlin application for pushing pictures from an Android phone or tablet to Wikimedia Commons, started by the Wikimedia Foundation and now maintained by grantees and volunteers. It ships through Google Play and F-Droid under Apache-2.0, with the architecture and release process documented in the repository itself. **commons-app/apps-android-commons** — The Wikimedia Commons Android app allows users to upload pictures from their Android phone/tablet to Wikimedia Commons - Repository: https://github.com/commons-app/apps-android-commons - Website: https://commons-app.github.io/ - Stars: 1,194 · Forks: 1,414 - Language: Kotlin - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/commons-app-apps-android-commons ## A single purpose upload client, not a Commons browser The README describes the app in one sentence: it allows users to upload pictures from their Android phone or tablet to Wikimedia Commons. That is the whole scope, and the narrowness is the point. Most people who want to put a photograph on Commons do it from a phone, right after taking it. The friction in that path is not the uploading itself, it is the surrounding work, moving the file to a computer, finding the right upload form, filling in the author and licence fields, describing the subject, and waiting for a category. An app that starts from the camera roll removes the transfer step and keeps the metadata entry on the device that took the picture. The project history is worth noting because it changes what the project is. It was initially started by the Wikimedia Foundation, and is now maintained by grantees and volunteers of the Wikimedia community. The README invites anyone to improve it by picking an open issue and sending a pull request. The foundation set the direction and the standards; the community now carries the work, which is a normal pattern for Wikimedia software and also a real continuity question for anyone depending on it. The distribution channels are Google Play under the package name fr.free.nrw.commons, and F-Droid under the same identifier. ## Gradle, Kotlin and a generated dependency graph The primary language is Kotlin, and the build is a modern Gradle one written in Kotlin DSL, with build.gradle.kts and settings.gradle.kts at the root alongside a gradle/ directory and the standard gradlew and gradlew.bat wrappers. Two files describe the shape of the build. jacoco.gradle wires up JaCoCo, which is the coverage tool, and the README carries a codecov badge pointing at the master branch coverage graph. dependency-injection.md at the repository root documents the dependency injection setup, and the developer documentation in the separate documentation repository has a Libraries Used page, which means the dependency set is documented rather than left implicit in the Gradle files. The gradle.properties file and the .idea/ directory are present, so the project is set up for IntelliJ-based development. The presence of a dependency-injection document is itself a design signal: an application with a login, an upload queue, media metadata and a category picker is a candidate for a layered architecture, and the DI container is the seam that lets the upload logic be tested without the network. A reader evaluating this codebase for reuse would look there first, since the repository root does not otherwise describe the internal architecture. ## Signing, the encrypted keystore and the release checklist Two top level files are unusual and worth explaining. nr-commons.keystore.enc and play.p12.enc are encrypted signing artefacts, and sign.sh is the script that presumably drives the signing step. Committing an encrypted keystore is a common practice in application repositories: the private key material is not in the repository in usable form, the decryption key lives in the environment or in the maintainers' hands, and the CI system can still produce a signed build. It is also a design decision with a cost. A developer cloning the repository cannot produce a release-quality signed build without the passphrase, so the release path is not fully reproducible from the repository alone. The process around it is documented in RELEASE-CHECKLIST.md at the root, which is the file to read before a release, and fastlane/ at the root indicates the release metadata and upload automation, which is the standard toolchain for Play Store submission. The CREDITS file and the CHANGELOG.md complete a release-adjacent set of files that a project takes seriously when it has to hand off to a review process. A smaller utility, find-broken-strings-variables.sh, suggests attention to localisation, which is the other recurring concern in a Wikimedia application. ## Good first issue, help wanted, and the contributor path The README's issue links are filtered rather than generic. The link to open issues is a query for open, unassigned issues, excluding the debated label, of type bug, excluding low priority and upstream labels. That is a deliberate curation of what a newcomer is pointed at. The repository also uses a good first issue label, and the topic list includes good-first-issue, help-wanted, gsoc and hacktoberfest, which are the labels a project uses to signal that it wants outside participation. The README says contributors should choose among the open issues and send a pull request, and points to a separate documentation repository with contributor documentation and a Volunteers Welcome page. The documentation repository splits into user documentation, contributor documentation, volunteer onboarding, and developer documentation including the libraries used. Keeping that material outside the code repository is a common Wikimedia pattern and keeps the application repository focused. The SECURITY.md file at the root is worth a mention for a Wikimedia project. The app handles account sessions for a public wiki, so a documented route for reporting a security issue is part of a responsible setup, and its presence signals that the project expects that conversation rather than hiding it. ## Preview builds without a device, and a fast release cadence The README links an Appetize.io badge labelled Preview the app, which is a way to run an Android build in a browser rather than on a physical device. For a project that takes contributions from people who may not own an Android phone, or that wants an issue to be reproducible by anyone, that is a meaningful piece of infrastructure rather than a badge. The release history is regular. v6.8.0 was tagged on 2026-10-14, preceded by a v6.8.0-beta on 2026-09-12 and v6.7.0 on 2026-08-18. The presence of a beta tag on the same version number as the final release, with a month between them, suggests the beta is used as a pre-release channel for the same version rather than as a separate line. The build status badge points at the android.yml GitHub Actions workflow on the main branch, so continuous integration runs on every push to the default branch. Combined with the codecov badge and the jaCoCo configuration, the project is measuring test coverage on each build. The last push was on 2026-10-15, one day after the v6.8.0 tag, so the repository is in active circulation rather than parked after a release. ## What the repository does not tell you The README is short, and for a project of this age and activity, most of the real information lives elsewhere. Being explicit about the gaps saves an evaluator a wasted afternoon. The repository does not describe the upload flow, the supported image formats, the maximum file size, or how the app handles EXIF metadata and licence selection. It does not list the API endpoints used, though the topic list includes wikimedia-api, and the developer documentation has a Libraries Used page that presumably covers the client libraries. It does not document offline behaviour or what happens to a queued upload when connectivity drops, which for a photographer on a train is the question that matters. It also does not state the minimum Android version supported, the target SDK, or the localisation coverage, even though the string-checking script implies a substantial translation set. The CREDITS file and the presence of translatewiki in the contributors table suggest a large translation effort, but the README does not quantify it. The dependency-injection.md file and the documentation repository are where these answers live. The README is an index, and treating it as the specification is the mistake here. ## Conclusion The Wikimedia Commons Android app is worth adopting if you photograph on an Android device and contribute media to Commons, because it removes the file transfer, metadata editing and licence selection steps that a browser upload imposes. It is the wrong tool if you need to batch upload from a desktop, or if you want to decide licence and authorship details on a larger screen, since the app is built for a single phone workflow. Before you install, note that the project moved from Wikimedia Foundation ownership to grantee and volunteer maintenance, so read CONTRIBUTING.md and SECURITY.md in the repository, and if you are a developer, check the sign.sh and RELEASE-CHECKLIST.md files to see how a signed build is produced. ## FAQ ### Where can I download the Wikimedia Commons Android app? The README links to Google Play and to F-Droid, where the package is listed as fr.free.nrw.commons, and it also offers an Appetize.io preview that runs the app in a browser without an Android device. ### Who maintains the Wikimedia Commons Android app now? It was initially started by the Wikimedia Foundation and is now maintained by grantees and volunteers of the Wikimedia community, who are invited to pick an open issue and send a pull request. ### What licence is the Wikimedia Commons Android app released under? The software is open source, licensed under the Apache License 2.0, with the licence text in the COPYING file at the repository root. ### How are releases built and signed for the Play Store? The repository contains sign.sh along with encrypted signing artefacts nr-commons.keystore.enc and play.p12.enc, a fastlane directory for upload automation, and a RELEASE-CHECKLIST.md describing the process. ### How do I start contributing to the Wikimedia Commons Android app? The README points contributors to the open issues, filtered to unassigned, non-debated bug issues excluding low priority and upstream, and to a separate documentation repository with contributor documentation and a volunteer welcome page. ## Sources - [commons-app/apps-android-commons on GitHub](https://github.com/commons-app/apps-android-commons) - [License: Apache-2.0](https://github.com/commons-app/apps-android-commons/blob/main/LICENSE) - [Project website](https://commons-app.github.io/) - [README](https://github.com/commons-app/apps-android-commons/blob/main/README.md) - [Releases](https://github.com/commons-app/apps-android-commons/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/commons-app-apps-android-commons