API 26 Compatibility: Comply with background execution limits

[mikehardy]

This is an enhancement request but any move to targetSdk of API 26 will be blocked until it is implemented

Applications that target API 26 have background execution limits applied to them.

It is no longer allowed to start an IntentService in the background.

Migration to JobIntentService from the compat library is the likely path to achieve compatibility

https://developer.android.com/reference/android/support/v4/app/JobIntentService.html
(background reading here: https://developer.android.com/about/versions/oreo/background.html#services)

It is not quite as easy as simply altering BootService to extend JobIntentService and changing the work method signature there - a second-level issue in AnkiDroidApp.java:204 is seen after this where the instantiation takes place.

[mikehardy]

Original issue temporarily fixed in #4786 - useful information is all present here

[mikehardy]

There is a deadline for this, FWIW - November 2018 for app updates to have targetSdk of 26
https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html

[mikehardy]

Turns out ACRA - our error reporting library - also has API>=26 errors.
So upgrading to ACRA 4.11 (where they backport Oreo support) fixes the same problem we have, but in one of our critical dependent libraries

It's a reasonable proxy for what we need to do, as well

ACRA/acra@05e9a53

[mikehardy]

I'm still not implementing but I'm storing knowledge-nuggets here. We may be able to use the new "WorkManager" component from Google to handle this easily across all APIs without a bunch of Compat code:
https://developer.android.com/topic/libraries/architecture/workmanager

(Edit: just looked at workmanager, and it's an androidx "Jetpack" - aka, brand new, new dependency etc - component, so no, not right now...)

[mikehardy]

@timrae I've got a proof-of-concept that seems to work, before I try it cleanly I wanted to run it by you.

Looks to me like since a receiver is in the background and thus can't start a service in API>=26, the 3 pairs of BootReceiver->BootService, NotificationReceiver->NotificationService and ReminderReceiver->ReminderService need to collapse amongst themselves so that the XXXService work is performed by the XXXReceiver directly when it receives broadcasts and the Services go away.

It's a lot of code movement so I wanted to check - sound good enough to see a PR this style?

[timrae]

I'm really not knowledgeable about services in Android at all, so it's hard for me to comment and even review those changes. Code movement is fine if it's necessary, but please do make sure that you don't accidentally leave something running eating up battery!

[mikehardy]

That's perfect, because to comply with background execution limits I made it all event-based and there will be nothing eating battery :-). Found a way (at least temporarily) to make the patch digestible as well but you'll see that on the related PR...