Support TUS upload protocol like iOS and desktop client do

[zerox80]

When uploading ZIP files or large folders (e.g., WhatsApp Media) via the Android App, the upload consistently fails.

ZIP files are attempted to be uploadded twice and then the upload aborts.
When uploading the Whatspap media (images) folder (< 2GB) the upload fails with lot of "Folder Error" Messages.

To Reproduce:
Select a ZIP File in the App (e.g., 2GB, but preferably more)
Start upload.
Upload fails: the app tries twice to upload the file, then aborts.

Alternativly: Select the Whatsapp media (images) folder and start upload -> Around 80% of the files fail, even when i have background activity unrestricted and have always on Display (no timeout). I even had left my phone and kept the app open until it is done.

Expected behaviour:
ZIP Files (up to the configured server limit of 20gb) should upload without errors.
Folder uploads should complete succesfsfully without "Folder Error".

Smartphone
Device: Google pixel 9
os: android 16
app version: newest from playstore, 1.0.0

My server is behind nginx reverse proxy, and those ZIP uploads worked on the Website of my opencloud instance. So it is nothing wrong with my setup. It has to be a Bug in the app.

I reinstalled the app multiple times, issue persists.
Happens regardless of file size (also fails with 2gb zip)

[zerox80]

My setup uses bunny.net as CDN in front of the origin. Bunny confirmed their origin response timeout is hard-limited to 60 seconds and cannot be increased. Large/long-running uploads over the CDN path therefore get terminated around 60s, which matches the app behavior (second attempt, then abort / “Folder Error”).
As a workaround I’m routing uploads directly to the origin (separate subdomain), while keeping downloads behind the CDN.

[zerox80]

i think the app needs to chunk the uploads. Could u look into that?

In the web interface (also on Chrome for Android) large ZIP uploads work fine, because they are chunked into smaller requests. In the Android app, however, large uploads fail after ~60 seconds, which matches the proxy timeout limit. That’s why I think the app needs to implement proper chunked upload as well.

[guruz]

You are unfortunately right, this is lacking in Android right now. I guess the workaround is to increase timeouts/limits on all layers until it works for your desired file size.

Developer reference:
iOS: https://github.com/opencloud-eu/ios-sdk/blob/main/OpenCloudSDK/TUS/OCTUSJob.h
desktop: https://github.com/opencloud-eu/desktop/blob/main/src/libsync/propagateuploadtus.cpp
https://tus.io/protocols/resumable-upload

[zerox80]

Thanks for confirming. Unfortunately I can’t raise the proxy/CDN origin response timeout beyond 60s (Bunny hard limit). That’s why “increase timeouts” isn’t a viable workaround here.

In the web UI and desktop client, large uploads succeed because they are chunked and resumable (short per-request durations). The Android app seems to push large files in long-running requests, which exceed the 60s window and then get retried (and ultimately fail) behind any standard CDN/WAF.

Could you implement proper chunked/resumable uploads in the Android client (similar to web/desktop), with configurable chunk size, concurrency, and per-request timeouts? Even a simple bounded multipart approach (e.g., 5–50 MB chunks) or adopting a standard like tus/multipart-resumable would solve this for all CDN users.

[zerox80]

Thanks for the clarification and the references 🙏

I saw that both Desktop (propagateuploadtus.cpp) and iOS (OCTUSJob.h) are already using the tus resumable upload protocol
. That explains why uploads work fine there behind proxies/CDNs.

On Android, since tus is not implemented yet, large files are pushed in long-running requests → they regularly exceed Bunny’s 60s origin timeout, get retried, and ultimately fail.

Proposed solution: adopt tus-java-client
(and tus-android-client
in the Android app, similar to Desktop/iOS. This would provide:
• Proper chunking (configurable chunk size, e.g. 5–50 MB)
• Short per-request durations (<60s)
• Resumable uploads with URL store (no full restart after error)
• Independent retries per chunk instead of whole file
• Seamless handling of authentication headers

With this in place, the Android client would be production-ready behind CDNs and WAFs, consistent with the web and desktop experience.

Happy to help test Android builds once this is in progress!

[zerox80]

#32 look into this, it is really good and it works for me!

[zerox80]

#36

hey, i made new pull. This one works out of box, with lot of logging. Try it out ur self. It also fixes the blank screen at initial start of the app

[guruz]

This is done, thanks @zerox80 for the contributions.
We're just fixing up some smaller issues.