AlarmManager Regression in Android 5.1

Manny Karyampudi pointed out to me a problem with some of my book samples, that turned out to indicate a regression in the behavior of AlarmManager on Android 5.1.

(book sample apps are useful canaries in the Android coal mine…)

Up through Android 5.0, the repeat interval for setRepeating() and setInexactRepeating() could be fairly low. Some of my book samples, like this one, go as low as 5000ms, mostly so developers can see the results without waiting too long. In the book itself, I point out that frequent polling will be bad for CPU usage, battery life, etc.

In Android 4.4, they made setRepeating() inexact, but only if your targetSdkVersion is 19 or higher. My samples have a targetSdkVersion below this, once again so developers can see the results in an expected fashion. Using inexact alarms, so AlarmManager events can be batched, is very useful for battery life. However, for development purposes, they are aggravating, in part because we have no idea when the alarms will go off.

In Android 5.1, they appear to have set a limit, where low polling periods are rounded up to 60000ms (one minute). Repeat intervals higher than 60000ms are left alone. This shows up in the adb shell dumpsys alarm output as well as in the actual results when running the code. This affects setRepeating() at minimum, and it appears to affect apps with any targetSdkVersion.

As a user, I don’t mind this, as it means that I should get better battery life, in the face of apps that are too aggressive with their use of AlarmManager. As a developer, I know that I should not be using AlarmManager for anything rapid-fire like that, in part because I should not be trying to do frequent work in the background, and frequent work in the UI layer is better handled by postDelayed() loops instead.

However, also as a developer, I am once again dismayed to see that there has been a fundamental change to a key piece of Android that went unannounced and undocumented. I am hoping that Google will publish something to the Android Developers Blog that explains what is going on.

Many thanks to Mr. Karyampudi for pointing out this change in behavior!