android-pass: The Kotlin Source of the Proton Pass Password Manager

One client in a family of Proton apps

This repository holds the source code for the Proton Pass Android application, and it is deliberately narrow. Proton Pass is a password manager whose topic tags include end-to-end-encryption and password-manager, and this repository is the Android client for it, not the service and not the other platforms. That distinction matters if you are trying to understand how Proton Pass works, because the encryption and sync behaviour that the application depends on lives elsewhere and is reached over the network. What this repository gives you is the part most Android developers would actually want to read: how a password manager handles autofill, how the vault is opened, how the interface is built and how the app is packaged for different stores. The application is listed on Google Play and on F-Droid, and the F-Droid listing has its own package name, which is the first sign of how the build matrix is organised.

A Gradle variant matrix instead of one build

The Makefile is the most informative file in the repository, because it exposes the build variants the project maintains. The default build target assembles a dev black debug variant, while the release target assembles a play prod release and a separate fdroid prod release. That is three distinct distribution channels with different configuration, and the difference is not cosmetic: a Play build and an F-Droid build differ in signing, in which proprietary libraries are included, and in what the application is permitted to do. The fourth variant is the payments build, which uses a dev prod variant with a distinct package name and a host URL derived from an environment variable, defaulting to a payments host and overridable with a PROTON_ENV argument. The presence of that switch suggests the payments build is compiled against several backend environments during development.

Building the app from the command line

Every target in the Makefile delegates to a Gradle wrapper invocation, so the build runs against a pinned Gradle rather than whatever is installed.

./gradlew :app:assembleDevBlackDebug

The release build targets the Play variant.

./gradlew :app:assemblePlayProdRelease

And the F-Droid variant is a separate target rather than a flag on the same one.

./gradlew :app:assembleFdroidProdRelease

The install targets mirror them, so a debug build goes onto a connected device with `./gradlew :app:installDevBlackDebug` and the release build with `./gradlew :app:installPlayProdRelease`. The repository also ships gradlew.bat for Windows, so the wrapper works on both platforms, and the readme points at docs/public/BUILD.md for the full local build instructions, which is where you should start since the Makefile covers only the common paths.

Modules, metadata and the tooling around the app

The top level shows a multi-module Gradle project. There is the `app/` module for the application itself, a `pass/` directory for the shared code, `build-logic/` for the convention plugins that hold the build configuration, and `tools/` for auxiliary tooling. There is also `metadata/` and an `appmacrobenchmark/` directory, the latter being a benchmark module for macro performance. The `metadata/` directory is worth noting for a different reason: it is where the store listing files live, so translations, descriptions and screenshots for Google Play and F-Droid are versioned alongside the code rather than kept in a separate dashboard. The build configuration uses Kotlin DSL with settings.gradle.kts and build.gradle.kts at the root and per module, plus a gradle.properties file, and a .pre-commit-config.yaml at the root means some checks run before a commit is created rather than only in continuous integration.

Linting, dependency guarding and the test split

Three quality targets exist and they check different things. Detekt runs as a multi-module task named multiModuleDetekt, which is the static analysis pass across the whole project rather than just the app module. The dependency guard target runs a Gradle task called dependencyGuardBaseline, which is the mechanism that keeps a dependency graph from drifting, by recording a baseline and failing when the resolved dependencies change unexpectedly. For a security-sensitive client that matters more than usual, since an unexpected new dependency in a password manager is worth noticing. Tests are split into unit tests and instrumentation tests: the unit target excludes the screenshot tests and disables the configuration cache, and the android target runs allDevicesDebugAndroidTest across the available devices. The CHANGELOG.md at the root is the record of what changed in each release.

What the repository does not contain

There is no server code here, no encryption library and no sync protocol implementation, and the absence is deliberate rather than an omission. The application is a client for a service, and the topic tags name the domains it works in, Android, Proton and end-to-end encryption, but the encrypted vault contents never leave the device in a form this repository could inspect. There is also no release history in the GitHub sense, since the repository publishes no GitHub releases and the shipped builds come from the store listings. The last push was on 2026-10-15, so the repository is actively worked on, and the .idea/ directory at the root means JetBrains IDE settings are committed, which is convenient for contributors but occasionally noisy in review.

The GPL-3.0 licence and what it means for the distribution

The code and data files are licensed under the GNU General Public License version 3, or at your option any later version, as published by the Free Software Foundation, with the full text referenced and the LICENSE file in the repository. For an application distributed through stores this is worth understanding precisely, because a GPL application distributed as a download has obligations that a web service does not. The stated terms permit redistribution and modification, and require that the licence and the notices travel with the work. Since the build matrix produces both a Play package and an F-Droid package from the same source, and F-Droid itself distributes free software, the two channels are consistent with the licensing. This is a statement of what the licence text says, not advice on how it applies to a particular redistribution.

Contributing, translating and where the entry points are

Three things are offered to outsiders. For anyone building locally, the readme points at the BUILD.md file under docs/public, which is the file to read before anything else because the Makefile only covers the common targets. For contributors, the CONTRIBUTING.md file holds the process, including how to set up a workspace and submit changes. For translators, there is a blog post explaining how to help translate the application, which is a reasonable thing for a client that ships in many languages to have documented outside the repository. Support for the app itself goes through Proton rather than this repository, and the Discussions and issue trackers are the places for problems with the client code. The readme is short on purpose, which fits a client that is one part of a larger service rather than a standalone product.

Editorial conclusion

android-pass fits a developer who wants to contribute to an end-to-end encrypted password manager on Android, or who wants to read how a Proton client is structured across app, shared and tooling modules. It is the wrong place to look for the cryptography or the sync protocol, since this repository is only the Android client, and the wrong choice if you want to run a Proton Pass server. Before you build, read docs/public/BUILD.md, and pick the variant you need, since the Makefile separates the Play, F-Droid and payments builds for a reason.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. protonpass/android-pass on GitHub
5. README