Keepass2Android: the same KeePass database, two different network contracts

The password database file is the product, not the app

The unit of storage is a file called the database, secured with a strong key, and the app exists to store and retrieve passwords and other sensitive information from it. That single design decision explains most of what the project is and is not. There is no server account to create and no proprietary container format to migrate away from, because the file is the whole thing.

The same file can be synchronized across different devices. The project says this works best using one of the built-in cloud storage options, and can also be performed with third-party apps. Since the file is what travels, the sync method is interchangeable, and the compatibility claim follows from the format: KeePass 2.x and KeepassXC on PCs are both supported, along with many other KeePass ports for a variety of platforms. Write the database on a desktop, and the phone is reading the same bytes.

Two Play listings, and the flavor variable is where they split

Regular stable releases are published on Google Play as two apps, Keepass2Android and Keepass2Android Offline. Beta builds come from opting in to a Beta testing channel, and each listing has its own channel, so there are four combinations to choose from rather than two.

The split is a build flavor, and the build system makes it explicit. The Makefile documents a Flavor variable passed with /p:Flavor= to the dotnetbuild command, with a worked example:

make Configuration=Release Flavor=NoNet

There is also a Configuration variable, passed as /p:Configuration= to the dotnetbuild command. A manifestlink target creates a symlink to the AndroidManifest corresponding to the selected Flavor, which is how a single src/ tree produces two different applications. The naming matters when you read build instructions later: the offline flavor is the one called NoNet, and it is the flavor whose permissions and behavior differ from the default.

make all means the APK, and the native and java libraries are separate targets

The Makefile is written to run on both unix-like systems with make and on Windows with GNU make, which it explains at the top of the file. The target list separates the build into stages rather than presenting one monolithic command: all for everything including the APK, apk as a synonym for all, native for the native libs, java for the java libs, nuget for restoring NuGet packages, and dotnetbuild for the project itself.

That staging has practical consequences. On Windows the file detects OS and switches the shell to cmd, because the user may not have a POSIX shell installed, and it swaps rm, cp and related commands for their Windows equivalents. It also disables built-in rules with MAKEFLAGS += --no-builtin-rules, which the file notes speeds up processing, for example when running make java on Windows where startup can take about 10 seconds more than on Linux. The cleanup targets are layered to match: clean_native, clean_java, clean_nuget, clean_dotnet, and a distclean that runs git clean -xdff.

Plugins are a documented path, and the wiki is where the answers live

There are three ways to contribute. The first is translation, routed through a Crowdin project page rather than through pull requests, so translators never touch the source tree. The second is code, either by creating a plugin or by opening a pull request, with the maintainer asking that you make contact first so efforts can be coordinated. The third is money, through GitHub Sponsors or a donation page.

Note what that list contains and what it does not. Plugins are a documented way to add features, with a creating-a-plugin guide linked from the README (How-to-create-a-plug-in_.md). Documentation, meanwhile, is a single pointer: the wiki, under a Documentation page in the GitHub wiki. Anything about database internals, sync provider configuration, or autofill behavior has to come from there, since the README itself is short.

The disclaimer is a liability waiver, not a security statement

The project distributes under the GNU General Public License v3.0 and states plainly that the software is provided as is, without warranties or conditions of any kind, either express or implied. The author or authors do not accept liability for damages of any kind resulting from use of the software, except as required by applicable law, with the parenthetical covering intent, gross negligence, and injury to life, body or health. Use is entirely at your own risk.

Read this for what it is: a waiver of warranty, not an audit. Nothing in it makes a claim about encryption strength, key derivation, or how the database file is protected in storage. The security story of this app rests on the KeePass format and the strength of the key you choose, and the license text is careful to promise none of it. Donations carry their own clarification, described as voluntary contributions that do not constitute a purchase, contract, or entitlement to specific features, services or support.

Autofill, passkeys and keyboard behavior are not answered anywhere in here

The questions people bring to a password manager tend to be about the platform features rather than the file format, and the README does not answer them. Whether autofill works, whether passkeys are supported, which keyboard the app registers, and how it compares against KeePassDroid or Bitwarden all fall outside what the README covers.

The same gap applies to the desktop question. Compatibility is stated as KeePass 2.x and KeepassXC on PCs plus many other KeePass ports for a variety of platforms, which is a claim about file compatibility rather than about feature parity. A file that opens in one port may still carry settings, or entry types, that the other handles differently. Treat every question about platform integration as a wiki question, and treat the plugin mechanism as the place where capabilities beyond the core app would come from.

The repository keeps license headers enforced with hooks and PowerShell

The root of the tree carries the housekeeping for a GPL project: GPLv3.txt with the license text, license.md, and a crowdin.yml for translation sync. Two less obvious entries do the enforcement. There is a .pre-commit-config.yaml, and add-license-hook.ps1 plus setup_format_and_license.ps1 are PowerShell scripts whose names point at license-header and formatting tooling.

The rest of the layout is straightforward for an Android app: src/ for the code, docs/ for documentation that lives in the repository rather than in the wiki, graphics/ for assets, android-licenses/, and a .gitmodules file. There is also a .github/ directory and a build status link in the README that points at the Actions runs. A Makefile at the root is the entry point for all of it, and it works under both make and GNU make on Windows.

Editorial conclusion

Keepass2Android suits someone already living in the KeePass file format who wants their Android phone to open the same database as their desktop, and who is comfortable picking up build details in the wiki rather than in the README. Before you rely on it, decide whether you need the offline edition or the networked one, confirm your sync provider actually handles the file the way you expect, and read the GPLv3 disclaimer, which offers no warranty and pushes liability onto the user.

Frequently asked questions

Official sources

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