Use Jetpack WorkManager instead of the custom implementation

[bencehornak]

I have stumbled upon the custom PeriodicWork implementation in the project, which is used by the disk buffering implementation to export signals:

opentelemetry-android/services/src/main/java/io/opentelemetry/android/internal/services/periodicwork/PeriodicWork.kt

Line 21 in 7238ac4

class PeriodicWork internal constructor() {

Its API is quite similar to that of the JetPack WorkManager API so I assume that you guys consciously decided not to use it, but to provide an own implementation. If this decision is already documented somewhere, could you point me there?

Otherwise I'd like to propose to use the Jetpack/androidx implementation, which is Google's official recommendation for doing periodic background work. It relies on sophisticated decisions made by the OS to optimize, when the best moment is to launch background tasks. E.g. one can set certain constraints to schedule the work only when the device is online, or if it's not low on battery (which is what I would recommend to set by default).

If I understand it correctly, it would work with the current minSdk (21), see the androidx.work docs:

WorkManager uses an underlying job dispatching service when available based on the following criteria:

• Uses JobScheduler for API 23+
• Uses a custom AlarmManager + BroadcastReceiver implementation for API 14-22

The downsides I can think of:

1. I find it difficult to pass object references between Work objects and the rest of the code.
2. Moreover, if the app developer decides to replace the default WorkManagerInitializer things get dirty very quickly.
3. The minimum frequency is 1x every 15 minutes