Switch from background service to some system-wide Android feature

The Issue

Currently LBRY on Android creates a foreground service reportedly to provide a better user experience. That allows the app to load data even when the app is not on the foreground. This is a complete bad practice.

Foreground services must only be used when the user can notice if it is running. Typical examples are music or video players. Background services can be used for features which user cannot notice directly.

The feature which LBRY tries to provide can (and should) be implemented by a background service. Android is already offering a few options for this:

• Sync Adapters, which are called by the system itself at least every 15 minutes, even if the app is not running
• Simple background service, which can be developed in a way where the system will ask it to do its jobs in a periodic way. If using WorkManager API, the system will even delay the call if there is no network available

Expected behaviour

Don't use a foreground service

Actual behaviour

App is using a foreground service, even user is not going to notice it is running. Notification shows it is running but that's not the way foregrounbd services should be used on Android.

Anything Else

I propose a roadmap where first current implementation is moved into a background service which uses WorkManager to get the system ask it to do the background sync. As currently LBRY is already using accounts, the next step would be to implement a Sync Adapter, which would just leverage the previous phase but moving the preference settings into the Android native Account Manager.

EDIT: This would only affect the app while not on the foreground. The LbrynetService would still be syncing as it is already doing while LBRY is being shown on the screen. App would switch to the WorkManager when user is not seeing it on the screen.

I could be working on this in the future, if it is seen as something worth to be done. I would fork this repo and do the corresponding PRs.

Internal Use

Acceptance Criteria

Definition of Done

• Tested against acceptance criteria
• Tested against the assumptions of the user story
• The project builds without errors
• Unit tests are written and passing
• Tests on devices/browsers listed in the issue have passed
• QA performed & issues resolved
• Refactoring completed
• Any configuration or build changes documented
• Documentation updated
• Peer Code Review performed

Start by tracing the LbrynetService and the existing foreground-sync path, then review the proposed WorkManager and Sync Adapter approaches in the issue. Done would mean background syncing no longer uses a foreground service, foreground syncing remains available, and the project builds with the required tests and device checks passing.