This library should wastes more battery for Android versions before Lollipop!

[vliux]

The mechanism of Lollipop JobScheduler is that, the service is inside a system process, which tracks the status of the device and wakes up our app processes when necessary. It's more battery-friendly compared to AlarmManager is that the condition-checking of the business logic is partly moved to JobScheduler service (in system process), so our app process don't need to frequently waked up.

I took a review of the code, for Lollipop it just delegates the job to official JobScheduler; while for API <= 4.4, BroadcastReceivers and WakeLocks are used in this library, so all the condition-checking is now inside app process, which is meaningless for using the lib. Even worse, the lib call PackageManager.setComponentEnabledSetting() with DONT_KILL_APP flag, which means the process of the app is less likely to be killed than normal. So using this lib may consume more battery power for devices before Lollipop.

[evant]

Yep, this is the major reason I made it clear in the README to not use this in production. Obviously it will never be as good pre-lollipop, but any suggestions on how to make it more battery-efficient would be helpful! I'm even willing to adjust the semantics a bit (for example, I'm considering on just using a simple arbitrary time to trigger the idle constraint since the api to do this pre-lollipop in an efficient way isn't really there).

[vliux]

A solution for pre-lollipop is to imitate the way how Googles does in Lollipop --- run a standalone process of your own, separately from any app processes. So no matter how many apps are using your library, only your process is active at background. This gives the system opportunities to kill all other app processes for sleeping mode. So your process need to check the conditions for those apps, and start app processes when certain conditions are fulfilled.