seadroid: the Android client for a self-hosted Seafile server

A client for a server you host yourself

Seadroid is the Android client for Seafile. That is the whole scope, and it is a scope worth being precise about, because Seafile is a self-hosted sync and share platform rather than a consumer service with a public API and a matching app.

The application is published on the market for easy access, with badges for Google Play and for F-Droid, and both point at the same package id, com.seafile.seadroid2. The F-Droid listing matters more than it might for a project like this, because a self-hosted platform user is often running F-Droid already and does not want to install an app from a store account tied to a corporate policy.

The primary language is Java, and the build is a Gradle project with the standard Android layout, an app/ directory, a root build.gradle, settings.gradle, gradle.properties and the gradlew wrapper scripts for both platforms.

Licensing is the one thing to read carefully. GitHub could not classify the licence, which means it is a custom one, and the repository holds a LICENSE.md file and a separate THIRD_PARTY_LICENSE.md for the bundled third party components. A team embedding this client, or redistributing a modified build, needs to read those two files rather than assume an open source licence.

The audience is therefore developers and administrators rather than end users, mostly: people who want to build the client themselves, contribute to it, or add a translation.

A release build needs a keystore and a key.properties file

The build instructions in the README are short and assume you already have the Android SDK installed.

You cd into the seadroid directory, then create a key.properties file, or simply rename key.properties.example and change the configurations to match yours. If you do not have a keystore yet, the README gives the command that creates one:

keytool -genkey -v -keystore app/debug.keystore -alias AndroidDebugKey -keyalg RSA -keysize 2048 -validity 1 -storepass android -keypass android -dname "cn=TEST, ou=TEST, o=TEST, c=TE"

That is a debug-grade keystore, with the passwords spelled out, and the validity of one day is a reminder that it is for local builds rather than for anything you publish.

The actual build is one Gradle command:

./gradlew assembleRelease

And the artefact lands at a predictable path:

app/build/outputs/apk/seafile-${versionName}.apk

The ${versionName} placeholder comes from the project version, so the file name changes with each release, which is a detail worth knowing if you script a CI job that picks up the output.

The wrapper scripts gradlew and gradlew.bat are both in the repository, so a Windows machine can build the Java side without installing Gradle separately. It is only the native library build further down that has a platform restriction.

HEIC support is native code, and rebuilding it is macOS only

The app uses native libraries for HEIC and HEIF image format support. Prebuilt libraries are included in app/src/main/cpp/libheif/, and the README explains when you would need to rebuild them yourself.

The stack that gets compiled is worth listing, because it explains the size and the build time. libjpeg-turbo is the JPEG image codec, x265 is the H.265 and HEVC video encoder, libde265 is the H.265 and HEVC video decoder, and libheif version 1.20.2 provides the HEIF and HEIC image format support. The libraries are built for the armeabi-v7a and arm64-v8a ABIs.

The build script does the work. You make it executable and run it:

chmod +x build_libheif.sh
./build_libheif.sh

It downloads and compiles the libraries, copies them into app/src/main/cpp/libheif/lib/, strips debug symbols to reduce size, and keeps the source code in libheif-android-build/src/ for future builds. The README warns that the process may take 30 to 60 minutes depending on your system.

The prerequisite list is where the friction is. The native build is macOS only, as the README puts it, currently. You need the Android NDK, with r21 or later recommended, and command line tools installed through Homebrew:

brew install cmake ninja pkg-config git
brew install nasm  # Optional, for libjpeg-turbo optimization

Environment variables are optional because the script auto-detects them, but the accepted names are worth copying:

export ANDROID_NDK_HOME=/path/to/ndk
export ANDROID_NDK=/path/to/ndk
export ANDROID_SDK_ROOT=/path/to/sdk

So the practical rule is that a Linux or Windows developer can build the APK, because the prebuilt libraries are in the repository, but cannot easily rebuild those libraries.

Three variables decide what build_libheif.sh produces

If you do need to rebuild the native stack, the README points you at the build script itself, because that is where the configuration lives. The variables are the Android API level, the target ABIs and the libheif version:

# Android API level (default: 28)
export ANDROID_API=28

# Target ABIs (default: armeabi-v7a, arm64-v8a)
ABIS=(
    "armeabi-v7a"
    "arm64-v8a"
)

# LibHeif version (default: v1.20.2)
LIBHEIF_VERSION="v1.20.2"

Each one has a sensible default, so the common case is running the script untouched. The API level of 28 sets the minimum Android version the native code is compiled against, which is worth checking against the minimum your own build declares.

The ABIs list is the one that matters most for distribution. Shipping both armeabi-v7a and arm64-v8a covers 32 bit and 64 bit devices, and narrowing the list to arm64-v8a alone will cut the size of the package noticeably, at the cost of dropping 32 bit devices.

The libheif version is pinned by default to v1.20.2, and changing it means the script downloads a different upstream release, which also changes what x265 and libde265 versions it pulls in.

The output of a successful run is one shared object per library per ABI:

app/src/main/cpp/libheif/lib/{ABI}/libheif.so
app/src/main/cpp/libheif/lib/{ABI}/libde265.so
app/src/main/cpp/libheif/lib/{ABI}/libx265.so
app/src/main/cpp/libheif/lib/{ABI}/libjpeg.so

Where {ABI} is one of armeabi-v7a or arm64-v8a.

Two ways into the IDE, and one of them is a different branch

The README describes two development environments, and the second one is a different branch of the repository rather than a different import procedure.

For Android Studio, the prerequisites are Android Studio and OpenJDK 17 or OracleJDK 17. The import steps are: open Android Studio, import the project, select the seadroid directory, choose import from gradle, and click next until the import is completed. That is the standard Gradle import, and the JDK version requirement is the only thing that might trip you up if your studio is still configured for an older runtime.

For IntelliJ and Eclipse users, the README says that for those using maven build structures, check out the project from the maven branch. The branch is linked in the README as the seadroid repository's maven branch.

That arrangement is worth understanding rather than just following. The default branch is a Gradle build, and the maven branch exists for people whose tooling expects a Maven project. The consequence for a contributor is that work on one branch does not automatically apply to the other, so the choice of branch is effectively a choice about which build system the project will live on, at least for your change.

Continuous integration is configured through Travis CI, with a build status badge at the top of the README and a .travis.yml file in the repository root, so both build paths have had automation around them at some point.

The .github directory is also present, so the project has moved some of its automation to GitHub Actions as well.

Translations go through Transifex, not through pull requests

Internationalization is handled on Transifex, and the README documents the join process step by step, which is a little unusual for a project that otherwise takes pull requests.

The steps are: visit the Transifex project page for haiwen/seadroid, click the Join this project button in the bottom right corner, use an email or GitHub account, with the GitHub option marked as recommended, to create an account, select a language and click Join project to join that language translation, and after being accepted by the project maintainer, upload the file or translate online.

The repository supports this arrangement with a .tx/ directory, which is the Transifex client configuration, so a contributor can pull the translation resources locally with the standard tooling if they prefer to work offline.

The acceptance step is the notable part. Translations are not merged on request, they are released by the maintainer after review, which is the usual Transifex model and keeps the string files consistent for the release pipeline.

For anyone reading the codebase to understand the app's structure, the translation resources are also a map of the user interface, since the strings are the closest thing the project has to a feature list.

The repository layout tells the rest of the story. Alongside the Gradle files there is a root build_libheif.sh script, gradle.properties, the app/ directory, and the two licence files, LICENSE.md and THIRD_PARTY_LICENSE.md, the second of which exists because the app ships third party native libraries.

A steady release line and a custom licence to read

The release history shows a project in its fourth major version, shipping regularly through the 4.0 line. v4.0.12 is dated 2026-08-22, v4.0.13 on 2026-09-02, and v4.0.14 on 2026-09-28. The last push to the repository was on 2026-10-19, so the branch has moved about three weeks past the newest tag.

The upgrade path for an end user is therefore the app store, not a build, and the app is on both Google Play and F-Droid. For a developer, the gap between the tag and the branch is the interesting part, since the native library work and the translation updates land on the branch first.

Licensing deserves a second look because it is the one thing about this project that is not self-evident. The repository is marked with a custom licence that GitHub cannot classify, and the README does not summarise it. The presence of both LICENSE.md and THIRD_PARTY_LICENSE.md tells you the project itself distinguishes its own code from the bundled native components such as libheif, libjpeg-turbo, x265 and libde265. If you intend to ship a modified build inside a product, read both files.

The rest of the tree is conventional: app/ for the application module, a root build.gradle with settings.gradle and gradle.properties, the gradle/ directory with the wrapper, and the.gitignore and.github directories.

The contributors are credited through a contributors graph linked from the README rather than a hand-maintained list, so the credit lives on the platform rather than in the file.

Editorial conclusion

seadroid suits teams that run their own Seafile server and want an Android client they can rebuild, patch or translate, and it suits anyone who needs HEIC images handled on the device. It does not suit a user who just wants a Seafile client on their phone, since the published app is already on both Google Play and F-Droid and rebuilding it buys you nothing in that case, and it does not suit a developer on Windows or Linux who wants to rebuild the native image libraries, because the README states the native build is currently macOS only. Check three things before you start: that you have a keystore and a key.properties file, since a release build needs signing, that the NDK and command line tools you have are recent enough, with the NDK r21 or later recommended, and that the app/src/main/cpp/libheif prebuilt libraries match the ABIs you ship. The most recent release is v4.0.14 from 2026-09-28 and the last push to the repository was on 2026-10-19.

Frequently asked questions

Official sources

1. haiwen/seadroid on GitHub
2. Issues
3. README
4. Releases