There’s a number of alternatives to using repeating alarms. Job scheduler API works and, in general I prefer “simplest first” approach. If it’s simpler, try it that way first. As far as battery life is concerned, the alarms are all subject to resource availability. I can leave my “ping” alarm (invokes an intentservice that verifies my back-end is available) running for 4 hours straight and it has no real extra measurable impact on battery life. It’s really up to what you’re doing in that repeating alarm, not the alarm itself.

So, if you’re making a really heavyweight call every 10 seconds, then that’s going to beat up your battery, the same way you would with a job scheduler. If you’re making a lightweight call every 2 minutes, then that’s going to be less impactful on your battery.

I also remove the background alarms in the suspend cycle of my activity so that they aren’t running when my application isn’t running (though there are certainly apps where it makes sense to keep an alarm running all the time).

In short, what you’re doing on timed intervals is far more important than how you’re accomplishing the timed interval.