Keepass2Android: A KeePass 2.x Client for Android with Cloud Sync and Autofill

The problem Keepass2Android solves for KeePass 2.x users on Android

A KeePass 2.x database is a single encrypted file. On a desktop that is convenient: one file, one master key, copy it wherever you like. On Android the file becomes the hard part. You need an app that can decrypt the same format, a way to move the file between phone and PC without corrupting it, and a keyboard path that fills credentials into other apps instead of forcing you to retype a 30-character password.

Keepass2Android targets exactly that gap. The README describes it as a password manager app that stores and retrieves passwords and other sensitive information in a database file secured with a strong key, and states that the file can be synchronized across devices, best through the built-in cloud storage options or otherwise through third-party apps. Compatibility is explicit: KeePass 2.x and KeePassXC on PCs, plus many other KeePass ports. So the audience is not someone shopping for a new password manager. It is someone who already has a KeePass 2.x database and wants the Android client to be a peer of the desktop, not a separate vault that has to be reconciled by hand.

The two published builds split that audience further. The regular app and the Offline variant are both on Google Play, and the offline package name (keepass2android.keepass2android_nonet) signals the difference: one build is expected to talk to storage backends, the other is for people who want the database to stay on the device.

How the app handles the database, cloud storage and autofill

The architecture visible in the repository is a .NET/Android application under src/, with native and Java components built separately. The Makefile names the stages directly: native builds the native libs, java builds the java libs, nuget restores NuGet packages, dotnetbuild builds the project, and apk is the same as all. There is also a manifestlink target that creates a symlink to the AndroidManifest corresponding to the selected Flavor, which tells you the flavour choice is not cosmetic. It selects which manifest the build uses, and therefore which capabilities the resulting APK declares.

That flavour mechanism is how a single codebase produces both the network-enabled app and the Offline build. The Makefile documentation shows the invocation pattern with Configuration and Flavor passed through to the dotnet build, and gives NoNet as the example flavour value. In other words, the offline behaviour is a build-time decision, not a runtime setting you toggle after install. If you want the non-network build, you have to obtain or produce that flavour.

The data flow itself is conventional for a KeePass client: the app opens the database file, derives the key from your credentials, decrypts entries, and serves them to the UI and to autofill. Synchronization is delegated. The README says syncing works best using the built-in cloud storage options and can otherwise be performed with third-party apps. That is a deliberate division of labour: the app is responsible for reading and writing a valid KeePass 2.x file, and the storage provider is responsible for moving bytes. It also means conflict handling is largely a property of the storage backend, which the README does not discuss.

Installing Keepass2Android and opening a database for the first time

The README does not publish an APK download. It directs regular stable releases to Google Play, listing Keepass2Android and Keepass2Android Offline as separate packages, and points beta releases at the Google Play beta testing channel for each. That is the supported install path, and it is the one to use unless you are building the app yourself.

If you are building from source, the repository ships a Makefile that works on unix-like systems with make and on Windows with GNU make. The documented invocation passes Configuration and Flavor through to the dotnet build, and the example in the Makefile header uses Release and NoNet:

make Configuration=Release Flavor=NoNet

According to the Makefile comments, the all target produces everything including the APK, and apk is an alias for all. The individual stages are available when you want to isolate a failure:

make native
make java
make nuget
make dotnetbuild

The manifestlink target is the one that matters when you switch flavours, because it creates the symlink to the AndroidManifest matching the selected Flavor. Cleaning is split along the same lines, with clean_native, clean_java, clean_nuget and clean_dotnet, plus a distclean target that the Makefile documents as running git clean -xdff to remove everything not in the git tree. Treat distclean as destructive: it deletes untracked build output.

For a first real use, install from Google Play, point the app at an existing KeePass 2.x database, and enter the master credentials. The README does not walk through the in-app screens, so the wiki at the project's documentation link is the place to look for the setup flow rather than the README.

Where Keepass2Android is the wrong tool

The first limitation is format. Keepass2Android is compatible with KeePass 2.x and KeePassXC, and the README frames it as a port that reads those databases. If your vault lives in a different password manager's format, this app is not a migration path; there is no import story in the README at all.

The second is the plugin surface. KeePass 2.x on Windows has a plugin ecosystem, and the README's contribution section explicitly invites people to add features by creating a plugin, linking to a guide on how to create a plug-in. That is a statement about the Android app's own extension model, not about compatibility with desktop plugins. Nothing in the README claims that a KeePass 2.x database relying on desktop plugin behaviour will behave identically here.

The third is distribution. There is no APK in the repository and no release artifact described in the README; stable and beta builds are distributed through Google Play. If your environment cannot use Google Play, your only documented route is building the APK yourself through the Makefile, which means standing up the native, Java and NuGet toolchains. That is a real cost, and the README does not present a prebuilt alternative.

Finally, the README does not document rollback, database conflict resolution, or what happens when two devices write the same file through a sync provider at once. Those are the questions that decide whether a sync setup is safe in practice, and they are absent from the top-level documentation the project publishes.

Keepass2Android compared with KeePassDX and KeePassDroid

KeePassDX is the comparison people reach for, and the difference is visible in how each project positions itself rather than in a feature list the README provides. Keepass2Android's pitch is compatibility plus built-in cloud storage: the README states that synchronization works best using one of the built-in cloud storage options, which means the app ships storage integrations rather than leaving you to place the file somewhere yourself. If your workflow is a database in a cloud drive that several devices open, that built-in path is the reason to pick this app.

KeePassDroid is the older, narrower option in the same space. The README's compatibility claim is specifically KeePass 2.x and KeePassXC, and Keepass2Android is a C#/.NET Android application with native and Java components, which is a heavier stack than a plain Android client. The practical consequence is the build: reproducing the APK means handling the native, Java and NuGet stages described in the Makefile, not a single Android build.

Against KeePassXC, the difference is platform, not philosophy. KeePassXC is named in the README as a desktop peer that shares the database format. Keepass2Android is the Android side of that pair. If you want one application across desktop and phone, you are choosing a database format and then a client per platform, and this repository is the Android client for that format.

Licence and the cost of keeping a GPL-3.0 Android build current

Keepass2Android is distributed under GPL-3.0, and the repository carries GPLv3.txt and license.md at the top level. The README's disclaimer states the software is provided as is, without warranties of any kind, and that use is entirely at your own risk. For an individual installing from Google Play, the licence is mostly a statement about source availability. For anyone redistributing a modified APK, GPL-3.0 is a copyleft licence, and the source obligations attach to what you distribute. That is a description of the licence, not legal advice; if you plan to ship a fork, read the licence text in the repository.

The README also separates donations from purchases: payments to support the project are described as voluntary contributions that do not constitute a purchase, contract, or entitlement to specific features, services, or support. So there is no paid tier to budget for and no support contract to fall back on.

Upgrade cost depends on which side you are on. If you install from Google Play, updates arrive through the store, and the repository shows a steady release cadence with v1.15-r3 published on 2026-07-20 and v1.15-r2 on 2026-05-29, following v1.16-pre1 on 2026-05-11. The last push to the repository was on 2026-09-17. If you build your own APK, every upstream release is a rebuild across the native, Java and NuGet stages, plus the flavour and manifestlink step, and your users get nothing until you do that work. That is the recurring cost of self-hosting this app rather than installing it.

Editorial conclusion

Adopt Keepass2Android if you already keep a KeePass 2.x database on a PC and want the same file on Android with cloud sync and autofill; the Offline build is the right pick when the device should not reach the network. Do not adopt it if you need a database format other than KeePass 2.x, or if you expect the repository to hand you a signed APK, since the README points to Google Play and the beta channel instead. Before committing, verify the flavour you intend to build (NoNet versus the network-enabled one), the GPL-3.0 obligations that apply to any redistribution, and whether your KeePass 2.x file uses plugins that the Android client does not implement.

Frequently asked questions

Official sources

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