How much battery drain do push notifications cause on Android 4.1?

Question

I've got an S3 on 4.1, and I have a lot of apps which have push notifications. This is convenient, but I want to know if 4.1 is set-up to use push notifications efficiently with regards to battery drain. Would having Android 4.3+ use less battery for push?

I have push enabled for 4 apps. After adding another push one last night, my battery loses 20% in an hour. I am starting to wonder how much battery do push apps really drain. I noticed some Twitter apps state that while they use push, they use their own server which apparently uses less of our battery.

Answer 1

Push notifications are designed to be the solution to battery draining apps that constantly monitor for data that has changed locally or on a server. Because of this they are very battery efficient. My phone typically will get 20 notifications in a few hours with less than 1% total battery use.

If your having huge battery drain problems, your phone is probably not sleeping properly which is usually due to an app that is preventing the phone from sleeping. I might be able to help you resolve this With some more information, such as Phone, Android version (or ROM if your rooted) and a screenshot of your battery screen after your phone has been running for a few hours. I will update my answer accordingly.

Answer 2

I want to know if 4.1 is set-up to use push notifications efficiently with regards to battery drain

Well the short answer is Yes, but this sounds like a misguided question. Push notifications have been around for a lot longer than 4.1 and to my knowledge there aren't any major "efficiencies" that were added to the Android OS after 4.1 to improve handling push notifications.

For push notifications to work, you need 4 components:

(1) An app server that's processing data for you in the cloud and wants to inform you about an event (for ex: Twitter/Facebook servers)

(2) A Push Notification Server that can receive requests from (1), figure out who its intended for, and dispatch a push to the right user/device combination (ex: Google Cloud Messaging server)

(3) A counterpart Android app/service that is always running in the background and has a persistent (always-on) connection to (2) so it may receive the push, figure out which app it's intended for, wake up that app and send it the small push data (ex: Google Play Store native app)

(4) An Android app that can receive this local data from (3) and figure out how best to inform the user about this push notification (typically by putting up a notification indicator in the status bar) (ex: Twitter Android app). This is what the end user thinks of as a push notification. Not all push notifications needs to show themselves in the status/notification bar though, they are sent silently by (3) and it is up to (4) to determine if a notification should be shown to the user

Ideally, even with push notifications setting turned on, (4) isn't awake. It'll be awakened by (3) when (3) receives the push from (2). Google provides the GCM framework that provides (2) and (3). So provided your apps are using GCM (or other equivalent services like UrbanAirship, Xtify etc), any excessive battery drain you might notice is the fault of (1) or (4), both of which are the fault of the app developer.

(1) and (2) maybe combined, as can (3) and (4). So if the apps you're installing have their own push service, that's still an issue with their code, not your device or the OS.

Additional reading: Google Cloud Messaging Architecture