Bitwarden for Android: Building the Password Manager and Authenticator from Source

Two apps, one Kotlin codebase, and the people it is built for

The repository at bitwarden/android is not a single application. The top-level layout separates app/, authenticator/, authenticatorbridge/, core/, data/, network/, ui/, cxf/, annotation/ and testharness/ as distinct Gradle modules, and the release tags confirm two shipping products: v2026.9.0-bwpm for the Password Manager and v2026.9.0-bwa for the Authenticator, both published on 2026-09-18. The README describes the project as "Bitwarden mobile apps (Password Manager and Authenticator) for Android." If you are looking for the desktop or browser client, this is the wrong tree.

The audience is narrower than the app's user base. Someone who wants a password manager on a phone installs the published build from the store; nothing here helps them. The people who need this repository are Android engineers maintaining an internal or self-hosted fork, security reviewers reading the client that handles vault decryption, and contributors upstreaming changes. The topic list (android, bitwarden, compose, jetpack, kotlin) matches that readership rather than end users.

That framing matters because the setup path assumes you already have an Android toolchain. There is no script that produces a signed, installable artifact for a casual user, and the README never pretends otherwise.

How the modules fit together and where the SDK comes from

The architecture visible from the repository root is a layered Android application. ui/ and app/ carry the Compose interface and application wiring; data/ and network/ handle persistence and remote calls; core/ holds shared logic; authenticator/ is the second app and authenticatorbridge/ is the piece that lets the two cooperate. annotation/ and testharness/ exist to support the rest rather than ship to users.

The dependency list in the README is a fair map of what the runtime leans on. AndroidX Room is described as "a convenient SQLite-based persistence layer for Android," AndroidX Security as the way to "safely manage keys and encrypt files and sharedpreferences," AndroidX Credentials for "unified access to user's credentials," AndroidX Autofill for "tools for building inline autofill UI," and AndroidX Camera for "display and capture images for barcode scanning." Compose is listed as "a Kotlin-based declarative UI framework." Read together, that is a client that stores a vault locally in SQLite, protects keys through the platform keystore, integrates with the system autofill and credential providers, and scans QR codes for setup flows.

The unusual part is the SDK. The user.properties file accepts a localSdk boolean, and the README says it determines "if the SDK should be loaded from the local maven artifactory," which it calls "particularly useful when developing new SDK capabilities." In other words, the crypto and vault logic can come from a published artifact or from a locally built one. That is convenient for SDK work and a source of confusion for everyone else, because a fresh clone with localSdk=true and no local artifact will not resolve.

Installing the toolchain and making a first build

The README's setup section is a five-step sequence, and step two is the one that stops most first attempts. Clone the repository first:

git clone https://github.com/bitwarden/android

Then create user.properties in the project root. The README requires a classic GitHub Personal Access Token with the read:packages scope, in the form gitHubToken=gph_xx...xx, and optionally localSdk. Without the token, Gradle cannot authenticate to GitHub Packages and dependency resolution fails:

gitHubToken=gph_xx...xx
localSdk=false

JDK 21 is required. In Android Studio the README points to Preferences > Build, Execution, Deployment > Build Tools > Gradle, then the Gradle JDK selector, where you pick a 21.x version or download one. Code style is enforced through docs/bitwarden-style.xml, imported under Preferences > Editor > Code Style via the Manage button next to Scheme, importing "from" BitwardenStyle "to" BitwardenStyle.

The optional detekt hook is the only runnable script the README provides, and it is worth noting that it overwrites any existing pre-commit hook:

cat << 'EOL' > .git/hooks/pre-commit
#!/usr/bin/env bash
echo "Running detekt check..."
OUTPUT="/tmp/detekt-$(date +%s)"
./gradlew -Pprecommit=true detekt > $OUTPUT
EOL
chmod +x .git/hooks/pre-commit

After that, the README does not spell out an assemble command. The gradlew wrapper and settings.gradle.kts are present at the root, so the task names come from the Gradle configuration rather than from the documentation, and a reader should treat the missing build command as a gap to close by inspecting the module list.

Where the build breaks and when this is the wrong repository

The first failure mode is authentication. A fine-grained GitHub token will not do; the README asks specifically for a classic PAT with read:packages. Teams that block personal tokens or route package access through a proxy will hit a wall that has nothing to do with the code.

The second is the SDK split. Setting localSdk=true without a locally published SDK artifact leaves resolution broken, and the README's only guidance is a link to the contributing site's "Linking SDK to clients" page. Nothing in this repository explains how to produce that artifact.

The third is signing. keystores/ exists as a directory, but the README documents no signing configuration, no keystore properties, and no release build instructions. Anyone expecting to produce a distributable APK from a clean clone will not find the path in the documentation.

Finally, platform floor. Minimum SDK 29 means Android 10, and the README lists target SDK 37 with phone and tablet form factors in portrait and landscape. If you need to support older devices, or if you are building for a form factor the README does not list, this client will not cover you. And if what you actually want is a working password manager rather than a codebase, the published apps are the correct answer; this repository is a source tree, not a distribution channel.

Bitwarden Android against building on the platform autofill APIs directly

The realistic alternative is not another password manager repository; it is writing your own Android client on top of the AndroidX libraries this project already depends on. AndroidX Autofill, AndroidX Credentials and AndroidX Biometrics are public, Apache 2.0 licensed, and documented by Google. A team that only needs to fill credentials into its own app, or that wants a thin internal credential store, can build against those APIs without inheriting a GPL-3.0 codebase, a two-app module graph, or a GitHub Packages dependency.

The difference in approach is scope. Bitwarden's repository gives you a complete product: a Room-backed vault, keystore-protected keys, barcode scanning for setup, an autofill service, and a companion Authenticator app, all wired together and maintained upstream. Building on the platform APIs gives you only the integration surface, and you supply the vault, the sync, the encryption design and the maintenance. The first is the right trade when you want the product; the second is the right trade when you want a small surface you fully control. Choosing Bitwarden's tree and then stripping out the vault, the sync and the Authenticator would be the worst of both.

Licence terms, upgrade cadence and what a fork costs to keep

The repository is GPL-3.0. That is a copyleft licence, and it governs the code you build from this tree, not the published apps you install from a store. A fork that you distribute carries obligations that a private internal build does not, and the specifics depend on your jurisdiction and your distribution model. This is a description of the licence identifier, not legal advice; if you plan to ship a modified client, have counsel read GPL-3.0 against your plans.

Upgrade cost is the more practical concern. The release history shows a monthly rhythm: v2026.8.1-bwpm on 2026-09-03, then v2026.9.0-bwpm and v2026.9.0-bwa together on 2026-09-18, with the last push to main on 2026-09-21. A fork that tracks upstream will rebase against that cadence roughly every month, across a module graph that includes both applications. The README's request to keep formatting changes out of logical commits exists precisely to make that rebasing survivable.

There is also a translation surface. crowdin.yml sits at the repository root and a Gemfile is present, which indicates localization strings are managed through an external translation service rather than edited in place. A fork that changes user-facing strings should expect that pipeline to be part of its maintenance, not an afterthought.

Editorial conclusion

Adopt this repository if you are an Android developer maintaining a fork, auditing the client, or building a self-hosted Bitwarden deployment where you control the APK. Do not adopt it if you want a password manager on your phone: install the published app instead, because the source tree gives you no build without a classic GitHub PAT carrying read:packages and no release signing material. Before your first build, verify that your GitHub account can authenticate to GitHub Packages, that your Gradle JDK is set to a 21.x version, and that your device or emulator runs Android 10 or newer, since the manifest targets SDK 37 but will not install below SDK 29.

Frequently asked questions

Official sources

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