DAVx⁵ OSE: CalDAV and CardDAV sync for Android without a vendor account

The gap DAVx⁵ OSE fills on Android

Android ships with calendar and contacts providers, and most phones are set up to fill them from a single vendor account. If your calendar lives on a Nextcloud instance, a mailbox provider that speaks CalDAV, or a server you run yourself, there is no built-in path from that server into the system apps. DAVx⁵ OSE exists to be that path. It is a sync client, not a calendar: after setup, events and contacts appear in whichever Android apps already read the system providers. The README describes it as a "CalDAV/CardDAV suite and sync app" and lists contacts, calendars and tasks sync as key features, with self-hosted servers named explicitly. The audience is narrow and specific. Someone who has a CalDAV or CardDAV endpoint and wants Android to treat it as a first-class account. Someone who does not want a vendor account in the middle. The OSE suffix matters here: this repository is the open-source edition, licensed GPL-3.0, and the README points readers to the project's web site for the tested-services list, manual and FAQ rather than reproducing them in the repository.

How sync actually flows: DAV discovery, local providers, and the outsourced libraries

The mechanism is DAV. The app discovers a server's CalDAV and CardDAV collections, then keeps local Android content in step with those collections. The repository shows this is not one monolithic codebase. Three libraries are maintained separately and pulled in as submodules or dependencies: dav4jvm, described as the WebDAV/CalDAV/CardDAV framework; synctools, handling iCalendar and vCard processing plus content provider access; and cert4android, for custom certificate management. That split tells you where the hard parts live. Parsing iCalendar and vCard and writing them into Android's providers is synctools' job. Speaking the DAV protocol is dav4jvm's. Certificate handling, which matters the moment someone points the app at a server with a self-signed certificate, is cert4android's. The app module itself is app-ose, with shared code in core. Build logic is factored into build-logic, and there is a synctools directory at the top level alongside the app and core modules. For anyone reading the source, that layout is the map: protocol in one library, data conversion in another, trust in a third. The README also notes WebDAV file access over the Storage Access Framework, meaning remote files are exposed to Android's file picker rather than through a separate file browser inside the app.

Installing DAVx⁵ OSE and connecting a first account

The README does not contain build or install instructions for end users. It links to the project web site for downloads and to F-Droid for the package, and it names the package identifier at.bitfire.davdroid in the F-Droid badge. So the practical install path is F-Droid or the download page, not a command you type. Building from source is a Gradle affair: the repository carries gradlew, gradlew.bat, settings.gradle.kts and a build-logic directory. The README does not document the build steps, so treat the wrapper as the entry point and expect the submodules to be required.

git clone https://github.com/bitfireAT/davx5-ose.git
cd davx5-ose
git submodule update --init --recursive
./gradlew assembleOse

The clone brings the repository; the submodule step matters because the README states that parts of DAVx⁵ have been outsourced into cert4android, dav4jvm and synctools. The Gradle task name above is illustrative of the app-ose module rather than a documented target, so check settings.gradle.kts for the real module and task names before relying on it.

For normal use, install the app, then add an account and enter the server URL. The README advertises "easy setup with automatic configuration", which means the app attempts to discover the service from the URL you give it. If discovery succeeds you will see the calendars and address books the account exposes and can choose which to sync. If it does not, the README's own pointer is the manual on the project web site, which is where service-specific instructions live. That is the honest boundary of this repository: it holds the code, and the operating instructions sit on the web site.

Where DAVx⁵ OSE is the wrong tool

The clearest limitation is that it is an Android sync client and nothing else. The related searches include "DAVx5 for iPhone", and the repository gives no indication of an iOS client. If your team is mixed-platform, this solves the Android half only. The second limitation is that it is a bridge, not a destination. It writes into Android's providers, so the quality of your calendar experience depends on the app you read those providers with. Anyone expecting DAVx⁵ to be a calendar app with its own interface is looking at the wrong project; the README's feature list is about synchronization and file access, not about a UI for editing events. Third, the WebDAV file access is delivered through the Storage Access Framework, which is a real constraint rather than a detail. Files reached that way are mediated by Android's document provider model, so behaviour depends on how the consuming app uses SAF and on connectivity at the moment of access. The README documents the mount feature and links to a manual page for it, but does not discuss offline behaviour or conflict handling for files. That silence is worth respecting: if your workflow assumes local copies and merge rules, verify it against your own server before committing.

How it differs from putting a provider's own client on the phone

The obvious alternative is the vendor route: use the calendar and contacts client that comes with whichever service hosts your data, or a hosted calendar app that syncs its own account. The difference is architectural, not cosmetic. A vendor client typically authenticates against that vendor's API and stores data in its own account, which may or may not surface into Android's system providers. DAVx⁵ inverts that. It speaks CalDAV and CardDAV, the protocols your server already implements, and writes into the system providers so that any Android app reading them sees your data. The practical consequence is portability: changing servers means changing the URL in DAVx⁵ rather than migrating between two proprietary APIs. The cost is that you need a server that speaks DAV and you need discovery to work. A second alternative for self-hosters is to skip the system integration and use a dedicated app that talks to your server directly. That gives you a purpose-built interface, but it also means your calendar lives inside that app rather than in the provider that other apps, widgets and assistants read. DAVx⁵'s bet is that system-level integration is worth more than a bespoke UI, and for a phone that already has a calendar app you like, that bet is usually right.

Maintenance, releases and what the GPL-3.0 licence implies

The repository is not archived, and the last push was on 2026-09-24, days before this writing. Recent releases show a steady cadence: v4.5.19-ose on 2026-08-03, then v4.5.20-beta.1-ose on 2026-09-05 and v4.5.20-beta.2-ose on 2026-09-16. The pattern is a stable release followed by betas for the next version, which is a normal shape for an app that has to keep pace with Android platform changes. Upgrade cost for a user is low: installs come from F-Droid or the download page, and there is no server component of DAVx⁵'s own to operate. The cost that does exist is upstream: the app depends on cert4android, dav4jvm and synctools, so a change in how Android handles content providers or certificates propagates through those libraries before it reaches a release. The licence is GPL-3.0, which is a copyleft licence. If you are an individual installing the app, that is unremarkable. If you are a company considering embedding this code in a product, the GPL-3.0 terms govern distribution of derivative works, and the README's donation and purchase links indicate the project also distributes a paid build. That is a question for your own legal review, not something this article can settle.

Editorial conclusion

Adopt DAVx⁵ OSE if you already run a CalDAV or CardDAV server such as Nextcloud and want Android's own calendar and contacts apps to use it, with the app obtained from F-Droid or the project's download page rather than a store bundle. Skip it if you want a calendar UI of its own, if your data lives in Google or Exchange and you intend to stay there, or if you need iOS. Before you migrate anything, verify that your server's discovery endpoint answers, that the app's automatic configuration finds your service, and that the WebDAV mount behaves the way your file workflows need, because the README documents the feature but not its failure modes.

Frequently asked questions

Official sources

1. bitfireAT/davx5-ose on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases