Give users control about using the foreground service

[HenrikJannsen]

Currently we only show the overlay for the permissions about the notifications.
The foreground service is always used.

I think that is problematic for users with limited data plans of if they are low on battery.
When Bisq runs in background Tor and the P2P network and basically all core services are keep running, consuming bandwidth and CPU. Thus I think we need to tell the user about the consequences and allow them to opt out.

Of course the trade off is that he need to bootstrap each time when opening Bisq. And of course the OS can kill the service anyway, but that is nothing we need to communicate to the user.

I would recommend to combine that with the notification permission as this feature requires the foreground service and most users will likely have both, or none. They could also change notifications only in the OS settings if they want to turn off but still want to use foreground service. I think we need to provide an option in settings to turn off the foreground service.

I am not much familiar with the foreground service implementation, but I guess in case it cannot be turned off dynamically, we could just deactivate the service by sending an intent once the app goes into background if user opt out of that.

The overlay should then explain in simple terms the trade offs of both options and let the user choose.

[rodvar]

I am all in for this one, we need to provide a way for users to disable the background service.

The implementation tries to use foreground service and defaults to background service when the running Android OS does not support it (which shouldn't happen often for node given the target OS versions)

We use to leave this to be handled by the OS - having a dismiss button enabled on the foreground notification to kill the background service (and most of the time also killed the app) but it got turned off with recent changes in the implementation. In the notification with no-dismiss mode, even if the user swipes off the foreground notification the service is still running until the user comes back to the app.

The launch and dispose of the foregroound service is controlled by our app so if we were to add a setting to enable/disable it, that's enough simply by using that flag to avoid running the stop/start service code.

I think we can create an issue from this discussion to implement this, maybe check with poems to avoid comes and gos in terms of design?

An enhancement in terms of UX would be to ask for the permissions exactly when its needed, in our current impl case it would be

• user creates his first offer successfully -> Enable background connection to receive trade requests?
• user takes his first offer successfully -> Enable background connection for instant offer updates?

maybe check with poems to avoid comes and gos in terms of design later on?

[wodoro]

dismiss label is not descriptive enough for the action, and it wasn't implemented properly as far as I remember
but I agree having such button is helpful

[rodvar]

all good wod, I think the new impl has its benefits too.

Its much more resilient... at least in Android 15 I left an open trade the whole night and when I woke up I've got a notification to progress it, I tap on it and the app was there working perfectly

With the previous (dismiss-enabled) impl, I woud woke up seeing the foreground notification I left and when opening it would go through bootstraping.
We should find a middle ground I think by keeping this new impl but providing the user a way to disable it if he wants to , I'll create an isssue for it 👍