Foreground services

[di72nn]

Normal non-foreground services are somewhat downgraded in modern Android versions: there are some background restrictions starting from Android 8, the services can't be started from background (#784), they can be killed by the system.

#931 replaces the service implementation, but still uses the same non-foreground services.

Here are some thoughts on how this should be fixed.

One of the main obstacles to simply replacing non-foreground services with foreground services is the requirement to display a notification. Not only it would be annoying for the user (to see a notification pop up even for short actions), but it also requires to rewrite the way notifications are displayed in the wallabag app.
Another reason against dumb transition to foreground services is the reason that not everything should be handled by foreground services.

In accordance with the docs, foreground services should handle long running immediate tasks.
I think in case of the app the only task that qualifies is the synchronization. Maybe also image fetching (or maybe it can be done with a WorkManager job).

Other short actions (like article modifications) should still be handled by background services, which should do fine under normal conditions. If such tasks are blocked by some other background operation (sync), the background service executing them should promote itself to a foreground service (in order to not be killed and lose data).

Some of the tasks (like background sync triggered by schedule or network events) should be done using WorkManager jobs. Now that the task logic is moved out of services it shouldn't be too hard.

For a while in the app the tasks haven't been not explicitly synchronized with each other. The synchronization relies on the fact, that the tasks are executed sequentially by a single service.
Introducing multiple task executors (foreground, background, WorkManager) requires to explicitly synchronize task execution. Maybe an exclusive SQLite write transaction is enough, maybe explicit locks are a better choice, I haven't look into it much yet.

As usual, these are notes for anyone willing to do some development.

[shtrom]

I think I ran into this issue when setting up a new client, and the app would never succeed to do the initial sync and fail with a java.io.InterruptedIOException

As a workaround, disabling battery optimisations for Wallabag worked for this initial sync, and it seemed to be better able to do the rest of the sync later on.

[shtrom]

Changed phone (Android 13), and ran into this issue again. FWIW, this time just allowing Unrestricted background traffic wasn't sufficient. I was getting the same error message, but slow-running scripts on the server side.

Ultimately, I fixed it, this time, by increasing the proxy timeout in the webserver's (Apache 2) VirtualHost:

    ProxyTimeout 900