owncloud/android: the official Android client for ownCloud servers

What owncloud/android actually is, and who it is for

This repository is the official ownCloud Android app, described in the README as "the primary mobile client for Android users". It connects to two server products: ownCloud Infinite Scale (oCIS) and ownCloud Classic. That distinction matters more than the feature list. A user with an oCIS deployment and a user with an older Classic deployment are hitting different backends through the same client, and the README names both as supported targets rather than treating one as legacy.

The feature set the README lists is file browsing, photo galleries, Spaces, sharing, passcode lock and biometric authentication. Spaces is the oCIS-era concept for shared workspaces, so its presence in the list is a signal that the app is not frozen at the Classic feature set. The app is distributed through Google Play and F-Droid, with package name com.owncloud.android in both listings.

The audience is narrow and worth stating plainly. This is for people who already have an ownCloud server and want the vendor's own client on Android. It is also for developers who want to modify that client, which is why the repository ships SETUP.md, CONTRIBUTING.md, TROUBLESHOOTING.md and a user_manual/ directory. It is not a service you can adopt on its own. Installing the APK without a server gives you a login screen and nothing to log into.

How the client is structured: modules, data flow and the Kotlin stack

The top-level layout is a multi-module Gradle project, and the module names describe a layered architecture. owncloudApp/ holds the application, owncloudComLibrary/ holds shared UI components, owncloudData/ holds the data layer, owncloudDomain/ holds domain models, and owncloudTestUtil/ holds test helpers. settings.gradle ties them together; build.gradle and gradle.properties sit at the root.

That split gives a caller a predictable direction of dependency: the app depends on domain and data, the domain layer does not depend on Android UI, and the data layer is where server communication lives. The README does not spell out the internal call graph, so treat the module boundaries as the documented contract rather than a claim about every class.

The repository also carries sbom.json and a sbom/ directory alongside THIRD_PARTY.txt and dependencies.txt. For a client that talks to a self-hosted server, a machine-readable software bill of materials is a practical artifact: it lets an operator answer what libraries ship inside the APK without reading Gradle files. The presence of detekt in the CI workflow badges suggests static analysis runs on pull requests, and the badge list also names unit tests, instrumented data tests and a conventional-commits check.

One architectural consequence worth naming: because the data layer is separate from the app module, a fork that needs to change how requests are issued has a defined place to do it. A fork that needs to change the UI has a different one. That is the main benefit of the layout, and it is a real one.

Building owncloud/android from source with Gradle

The README's Getting Started section is short and points elsewhere for detail. It says to read SETUP.md for development environment setup, fork the repository and clone it locally, open the project in Android Studio, and build and run using a Gradle wrapper task. The exact command given is:

./gradlew assembleDebug

Run it from the repository root on a machine with a JDK and the Android SDK installed. The wrapper script gradlew is committed at the top level, so the Gradle version is pinned by the repository rather than by whatever is installed globally. A successful run produces a debug APK under the app module's build output; the README does not state the exact output path, so check the build log rather than assuming one.

SETUP.md is the file to read before this command, because the README defers environment setup to it. The README does not reproduce the required JDK version, Android SDK levels or Android Studio version, and it would be wrong to guess them. If the build fails on a missing SDK component, SETUP.md and TROUBLESHOOTING.md are the two documents the repository provides for that.

If you only want to use the app rather than build it, the README points to Google Play and F-Droid, and it describes a beta channel on both: on Play Store you scroll to the beta section and tap "I'm in", and on F-Droid you open the ownCloud tab and download the latest beta version. For contributing, the workflow rules are stricter than average. Commits must be PGP/GPG signed and carry a DCO sign-off line, and the README gives this example:

git commit -s -S -m "your commit message"

The same section states a rebase workflow ("Rebase Early, Rebase Often!") and a GitHub Actions policy restricting workflows to actions owned by owncloud, created by GitHub under actions/*, or verified in the GitHub Marketplace.

Where owncloud/android is the wrong choice

The clearest limitation is that this is a client with no server in the repository. If you do not already operate ownCloud Infinite Scale or ownCloud Classic, the app has nothing to connect to. There is no bundled backend, no local-only mode described in the README, and no hosted service offered by the project. Anyone looking for a self-contained way to sync files between Android devices should look at a different class of tool entirely.

The second constraint is the contribution gate. Signed commits and DCO sign-off are not optional here; the README states that all commits must be PGP/GPG signed and that every commit must carry a Signed-off-by line. A contributor without a GPG key configured cannot land a patch until that is set up. Translation changes are excluded from the normal pull request path: the README asks that translations go through Transifex and explicitly says not to open pull requests for them. A developer who wants to fix a single mistranslated string has no direct route.

Third, security reports do not go through GitHub issues. The README says not to open a public issue for vulnerabilities and directs reports to security.owncloud.com, with a bug bounty program on YesWeHack. That is a reasonable policy, but it means a casual user who spots something odd has to leave GitHub to report it.

Finally, the licence is in transition. The README states the current licence is GPL-2.0 and describes a strategic relicensing toward Apache 2.0 driven by the OSPO. The LICENSE file reflects current status, not the target. Anyone planning to reuse code needs to read that file rather than the roadmap.

How owncloud/android differs from a generic sync client

The obvious alternative category is a general-purpose file sync client that speaks a vendor-neutral protocol, for example an Android client built around WebDAV or a sync daemon such as rclone on a desktop. The difference is not feature count; it is where the protocol knowledge lives.

A generic WebDAV client treats the server as a filesystem with a URL. It does not know about Spaces, it does not know about oCIS-specific sharing semantics, and it cannot present a photo gallery that understands the server's own structure. The owncloud/android README lists Spaces, sharing, photo galleries and biometric authentication as first-class features, and those are server-aware behaviours. That is the trade-off: the app is coupled to ownCloud's server APIs, and in exchange it can expose concepts a generic client cannot see.

The reverse trade-off is portability. A WebDAV client works against many servers; owncloud/android works against the two ownCloud server products named in the README. If your organisation runs Nextcloud, this is not the client for it, and the repository gives no indication that it is intended to be. If you run ownCloud, the vendor-maintained client is the one that will track server-side changes first.

There is also a distribution difference worth noting. Because the project publishes to F-Droid as well as Google Play, there is a build path that does not depend on Google's store, which matters to users who avoid Play Services. The README does not claim the app is free of Google dependencies, so verify that yourself if it is a requirement.

Maintenance, releases and what the licence migration means for forks

The repository is not archived, and the last push was on 2026-09-23. Recent releases are v4.8.4 on 2026-08-31, v4.8.3 on 2026-07-21 and v4.8.2 on 2026-07-01. The cadence visible in those three tags is roughly monthly, and the gap between the newest tag and the last push is short. That is a normal maintenance rhythm for a vendor client, and it is the only maintenance signal available here; the README does not publish a support window or an end-of-life policy for older app versions.

Upgrade cost is low for users, since Google Play and F-Droid handle it, and the beta channels described in the README are opt-in. For a fork, the cost is different. Because the project uses a rebase workflow and signed commits, a long-lived fork will accumulate divergence that is awkward to rebase, and its own commits will need signing and sign-off to be mergeable upstream. The Android build also pins its Gradle version through the committed wrapper, so a fork inherits the repository's build tooling rather than choosing its own.

The licence situation is the part to read carefully. The README states the current licence is GPL-2.0 and that GPL-2.0 is Category X under the Apache Software Foundation's third-party licence policy, meaning it cannot be included in Apache-2.0 works. The stated prerequisites for migrating this repository are CLA or DCO coverage from all past contributors, a copyleft dependency audit, a KDE heritage review for code carrying KDE-era copyrights, and full relicensing of all files. Until that completes, the LICENSE file governs. This is not legal advice; if you plan to redistribute a modified build, take your own advice on what GPL-2.0 requires of you. The README names [email protected] as the contact for licensing questions.

Editorial conclusion

Adopt owncloud/android if you already run an ownCloud Infinite Scale or ownCloud Classic server and want the vendor's own Android client, or if you intend to modify that client. Do not adopt it as a standalone file service: it stores nothing itself and needs a server it can reach. Before building, verify that your Android Studio and Gradle toolchain satisfy SETUP.md, and check the current licence in LICENSE.txt rather than assuming the Apache 2.0 target has landed.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. owncloud/android on GitHub
4. README
5. Releases