Android: "Unresponsive App" error popup when syncing

[danielb42]

Actual behaviour

• When manually syncing a large and partially-synced directory, Android O will complain about "App not responding [Close/Wait/Report]" after about 5-20 seconds. This does not happen when the process encounters new/modified files early enough, i.e. before the "unresponsive"-popup occurs. I think, every encountered new/changed file resets some kind of timeout of the popup.
• Even when selecting "wait", the Nextcloud app seems to be closed after some moments when not encountering new/changed files (even if there are plenty to be found later down the tree), thus stopping all sync activity. So the wild guess is that Android misinterprets the idle-ness of "nothing to download" as "app is stuck" and gives up waiting anyways after asking the user once?

Expected behaviour

• No error popup about unresponsive app when syncing large directories

Steps to reproduce

1. Have a large directory tree with mostly un-synced files
2. Tap it -> Menu -> Synchronize
3. wait for error popup

Environment data

Android version: 8.0.0

Device model: Moto Z Play

Stock or customized system: Stock

Nextcloud app version: 3.2.0

Nextcloud server version: 13.0.4

[danielb42]

Is there anything wrong with this issue?
@tobiasKaminsky

[tobiasKaminsky]

Nothing wrong, we just had not the time to look into it.
It seems that it is a problem with the enhanced doze mode of android 8.

[danielb42]

Got a new phone meanwhile: Samsung A8 (2018, SM-A530F). Still same problem with Android 8/Nextcloud 3.2.1. "Standby-Mode" and "Battery Optimization" for Nextcloud App both off.

How can nobody else be affected by this? It's cross-vendor..

[danielb42]

Same problem with Galaxy S9 and current server/app versions. As it seems like I am the only one affected, I have to assume it's more likely related to my server setup than to client-side? Any thoughts or news on this?

[tobiasKaminsky]

This needs to be changed on our side.
Currently we use an old system for uploading/syncing.
This needs to be changed so that the new doze system can interact with it and start/stop/pause sync/download.

[danielb42]

Glad to hear you have lead on this one, thanks!

[rcmcronny]

You are not alone, i have this issue also with a bigger folder, i need to tap 5-10 times to wait more, to let it begin to sync finally, very annoying.

[danielb42]

Hi people.

What is the general plan to handle the (reproducible) ANR on syncing large|many files? I understand that fixing this can be complicated when Android is behaving crappy here (as recent issues about the timeouts suggest). But in the end it is a defect of the NC app imho, which might even scare new users away from using NC at all. At least I can imagine happily setting up NC, trying to initially sync all my stuff, getting a whole lot of ANRs, rant a little and never come back. Or worse, fall back to the big cloud providers because their stuff "at least works blah blah".

Likewise, in the recent past I had to convince people several times in person not to scrap NC because of those ANRs. Telling them there's this github thing and there are actual people working on this very problem can soften some of the frustration and gain patience. I am not sure, however, how often one can repeat that trick before losing the folks.

@tobiasKaminsky In 2018 you said in several issues that this could still be fixed on NC-side. Is this optimism still justified? Asking because this issue is actually the only one still open about this, all the others up to went stale in the meantime. :/

(Also interested in what @AndyScherzinger thinks about this these days.)

Regards, and thank you!

[ericzolf]

In case of doubt, you're not the only one affected (LineageOS 16 on bq Aquaris X Pro, but the issue was the same on LineageOS 15.1).

I had assumed that it was rather a thread issue where the UI thread would be stuck for too long, instead of having long running tasks in a separate thread to unstuck the UI thread, but whatever gets the issue away is good to me.

[fin-ger]

I stopped using the nextcloud app because of this issue.

I am using this app to sync my music, which fails horribly with ~50GiB. I am using the web ui with manual downloads instead now. This is not a real solution, but the only one I came up with for android. As long as this issue is unresolved, this app is useless to me.

Is there a plan to fix this or is my use-case rare?

[rcmcronny]

i use it also for music sync to my handy and car radio. So you are not alone for bigger directories (mine is ~ 30GB für syncing, i keep it low to minimize the anoying "unresponsive app" messages.
I would really be nice, if i can trust the sync and the messages would not displayed of course. Bonus would be a "set this folder to auto sync" every hours/days whatever.

[danielb42]

Is my use-case rare?

Maybe - but doesn't matter as the bug also occurs with file counts and sizes far below your specific use case. I have been unable to fully sync a folder with ~50 files (mostly tiny plaintext, one or two 500MB files) ever since 3.2.0 (or so).

[tobiasKaminsky]

The main problem here is time.
There are many things piling up right now, and one of the most important things is now to have a replacement for the outdated jackrabbit webdav app.

After this I can tackle this, or if anyone wants to give it a try…I can assist in some way.

[siebica]

Hi @tobiasKaminsky,

The issue lies in the way the SynchronizeFolderOperation starts the SYNC_FOLDER operation service. It was initially started as a normal service but was changed to start as a foreground service. While this is not an issue on itself, if this service takes more time to complete it will trigger an ANR.