5 ms·

So to summarize, to save battery all notifications on Android (since two versions ago) have to go through a single notification service (rather than each app ha

So to summarize, to save battery all notifications on Android (since two versions ago) have to go through a single notification service (rather than each app having the option of continuously running in the background and maintaining a connection with its own notification service). Recently Google killed their GCM notifications service in favor of Firebase Cloud Messaging, which (unlike GCM) unfortunately doesn't have an open source library available for it at the moment. Does that sound right so far? Anyway, the Telegram-FOSS team claims that this doesn't _actually_ save battery: > Despite Google's misleading warnings, there is no difference in battery usage between v4.6 in "true background" and v4.9+ with notification. But this seems rather unlikely to me. Are they saying that an application running continuously in the background uses the same amount of battery as an application that's not running at all? Or am I just misreading that statement?

runeks 7y ago
> Are they saying that an application running continuously in the background uses the same amount of battery as an application that's not running at all? A single application running in the background probably uses only a small amount of extra power compared to the notification service alone. However, a couple dozen applications -- all running in the background in order to enable notifications -- probably consume a lot more power than a single service.
- Ajedi32 7y ago
  There's also a wide variety of possible implementations of a notification service, and not all of them will necessarily be as power efficient as what Telegram-FOSS does.
  - AstralStorm 7y ago
    And Android's battery monitoring should flag them accordingly, not rely on presence of some library.
    - ahupp 7y ago
      It's not relying on the presence of a library. It's indicating that the app is still running in the background, and thus using more battery.
- DeonPenny 7y ago
  I can tell you in the old android world. There was a not insignificant chance that 70-80% of apps that needed notifications or syncing did just that.
curt15 7y ago
> So to summarize, to save battery all notifications on Android (since two versions ago) have to go through a single notification service And presumably the user has no way to install alternate notification services?
- Ajedi32 7y ago
  I don't think so. A "notification service" isn't something that exists solely on the user's device; there's also a server-side component that each remote service that wants to send a push notification has to interact with. So for Android to support alternate notification services, every app/service that wants to send push notifications would _also_ have to support those alternate services on their backends.
neves 7y ago
I think they said they aren't using any more battery than they were using before. Sure they could implement their software using less battery, but these Google warnings could apply to anything. This app could perform better. This app could be smaller. This app could have less bugs. The only thing that they can't say is: "This app could be more secure."
- jtbayly 7y ago
  It is my understanding that if it could have "less bugs" then it could be "more secure." Aren't bugs the cause of most security breakdowns?
izacus 7y ago
> But this seems rather unlikely to me. Are they saying that an application running continuously in the background uses the same amount of battery as an application that's not running at all? Or am I just misreading that statement? I don't see how that could be true - Android has seen massive battery life improvements after introduction of Doze which forces apps to sleep and stops the from constantly waking up radio and main ARM core. FCM is the only service that can wake up the device remotely and includes throttling code. Before these changes Android had severe idle battery life issues (which were happily mocked by owners of locked down and proprietary iOS devices on this very website) since multiple apps waking up radio for notifications/synces caused radio/cpu to run pretty much constantly. It's worth noting that just doing a radio ping can increase power consumption by as much as 100x for next few minutes. Maybe the Telegram report ignores the fact that they aren't allowed to wake up the device anymore. If you're measuring in isolation it's easy to make a case for "not making a difference".
- AstralStorm 7y ago
  There is no way to wake up a device remotely ever. Firebase is doing the same thing anyone can, running on a schedule. It just batches the comms in one time slot. Android scheduler mechanism was supposed to offer the same benefit.
saurik 7y ago
The phrase "running continuously" makes it sound like they are doing something... but they aren't: they are blocked reading on a socket. The only time they would run is if they receive information, which is exactly when they would run anyway (as they got a notification). The difference in battery usage would essentially be down to subtle effects caused by the private memory of that process (which might be negligible) not being able to be used as a cache to make some other process more effective. The only reason this would matter is if the processes are forced to wake up occasionally to actively send some kind of keepalive on the socket (which would be an arbitrary requirement caused by the network), which still frankly would not necessarily use much battery if the OS does intelligent gathering of wakeups from multiple processes (like, it would exist and be measurable, but seems strange to me to be something to care about as the phone is probably already waking up every now and then to do other stuff Google wants). I mean, if the notification comes in and the app wouldn't have to wake up to process it normally (which might prevent paging some executable code in from flash) and the notification itself could be delayed into some kind of batch, then maybe? Apple actually does do some of this kind of stuff on iOS: I would bet Google doesn't.
- izacus 7y ago
  The main issue with what you're mentioning is usually the fact that only Apple and Google servers tend to be whitelisted on telco routers for long polling connections. Trying to keep long-running HTTP connections for everyone else tends to be extremely hard on battery life since telcos can kill of connections even as often as 2 - 5 minutes. Powering up the main core and radio so often will make your phone hardly last 12 hours.
  - pas 7y ago
    Is there any real data or other hard evidence of this whitelisting? Especially in the EU where no favorable treatment is the default (so net neutrality) - as far as I know.
    - izacus 7y ago
      Just first hand experience, sorry.
shawnz 7y ago
> Despite Google's misleading warnings, there is no difference in battery usage between v4.6 in "true background" and v4.9+ with notification. This doesn't sound like the right comparison to me -- shouldn't they be comparing FCM against the background app/persistent notification approach? Here, it sounds like they are comparing the background app approach against the persistent notification approach, but those are AFAIK basically the same technique, except the latter shows an annoying notification whereas the former didn't. So of course the performance would be the same. EDIT: After reading the original post it is clear they are indeed not comparing against FCM. They are just comparing two different methods of running in the background. See: https://github.com/Telegram-FOSS-Team/Telegram-FOSS/blob/master/Notifications.md https://github.com/Telegram-FOSS-Team/Telegram-FOSS/blob/mas...
habosa 7y ago
[Firebase team member here] As far as I am aware, GCM never had an open-source client. In fact I don't think any "play-services-{x}" library has ever been open sourced.
- deleted 7y ago
  [deleted]

runeks 7y ago

> Are they saying that an application running continuously in the background uses the same amount of battery as an application that's not running at all? A single application running in the background probably uses only a small amount of extra power compared to the notification service alone. However, a couple dozen applications -- all running in the background in order to enable notifications -- probably consume a lot more power than a single service.

Ajedi32 7y ago
There's also a wide variety of possible implementations of a notification service, and not all of them will necessarily be as power efficient as what Telegram-FOSS does.
- AstralStorm 7y ago
  And Android's battery monitoring should flag them accordingly, not rely on presence of some library.
  - ahupp 7y ago
    It's not relying on the presence of a library. It's indicating that the app is still running in the background, and thus using more battery.
DeonPenny 7y ago
I can tell you in the old android world. There was a not insignificant chance that 70-80% of apps that needed notifications or syncing did just that.

curt15 7y ago

> So to summarize, to save battery all notifications on Android (since two versions ago) have to go through a single notification service And presumably the user has no way to install alternate notification services?

Ajedi32 7y ago
I don't think so. A "notification service" isn't something that exists solely on the user's device; there's also a server-side component that each remote service that wants to send a push notification has to interact with. So for Android to support alternate notification services, every app/service that wants to send push notifications would _also_ have to support those alternate services on their backends.

neves 7y ago

I think they said they aren't using any more battery than they were using before. Sure they could implement their software using less battery, but these Google warnings could apply to anything. This app could perform better. This app could be smaller. This app could have less bugs. The only thing that they can't say is: "This app could be more secure."

jtbayly 7y ago
It is my understanding that if it could have "less bugs" then it could be "more secure." Aren't bugs the cause of most security breakdowns?

izacus 7y ago

> But this seems rather unlikely to me. Are they saying that an application running continuously in the background uses the same amount of battery as an application that's not running at all? Or am I just misreading that statement? I don't see how that could be true - Android has seen massive battery life improvements after introduction of Doze which forces apps to sleep and stops the from constantly waking up radio and main ARM core. FCM is the only service that can wake up the device remotely and includes throttling code. Before these changes Android had severe idle battery life issues (which were happily mocked by owners of locked down and proprietary iOS devices on this very website) since multiple apps waking up radio for notifications/synces caused radio/cpu to run pretty much constantly. It's worth noting that just doing a radio ping can increase power consumption by as much as 100x for next few minutes. Maybe the Telegram report ignores the fact that they aren't allowed to wake up the device anymore. If you're measuring in isolation it's easy to make a case for "not making a difference".

AstralStorm 7y ago
There is no way to wake up a device remotely ever. Firebase is doing the same thing anyone can, running on a schedule. It just batches the comms in one time slot. Android scheduler mechanism was supposed to offer the same benefit.

saurik 7y ago

The phrase "running continuously" makes it sound like they are doing something... but they aren't: they are blocked reading on a socket. The only time they would run is if they receive information, which is exactly when they would run anyway (as they got a notification). The difference in battery usage would essentially be down to subtle effects caused by the private memory of that process (which might be negligible) not being able to be used as a cache to make some other process more effective. The only reason this would matter is if the processes are forced to wake up occasionally to actively send some kind of keepalive on the socket (which would be an arbitrary requirement caused by the network), which still frankly would not necessarily use much battery if the OS does intelligent gathering of wakeups from multiple processes (like, it would exist and be measurable, but seems strange to me to be something to care about as the phone is probably already waking up every now and then to do other stuff Google wants). I mean, if the notification comes in and the app wouldn't have to wake up to process it normally (which might prevent paging some executable code in from flash) and the notification itself could be delayed into some kind of batch, then maybe? Apple actually does do some of this kind of stuff on iOS: I would bet Google doesn't.

izacus 7y ago
The main issue with what you're mentioning is usually the fact that only Apple and Google servers tend to be whitelisted on telco routers for long polling connections. Trying to keep long-running HTTP connections for everyone else tends to be extremely hard on battery life since telcos can kill of connections even as often as 2 - 5 minutes. Powering up the main core and radio so often will make your phone hardly last 12 hours.
- pas 7y ago
  Is there any real data or other hard evidence of this whitelisting? Especially in the EU where no favorable treatment is the default (so net neutrality) - as far as I know.
  - izacus 7y ago
    Just first hand experience, sorry.

shawnz 7y ago

> Despite Google's misleading warnings, there is no difference in battery usage between v4.6 in "true background" and v4.9+ with notification. This doesn't sound like the right comparison to me -- shouldn't they be comparing FCM against the background app/persistent notification approach? Here, it sounds like they are comparing the background app approach against the persistent notification approach, but those are AFAIK basically the same technique, except the latter shows an annoying notification whereas the former didn't. So of course the performance would be the same. EDIT: After reading the original post it is clear they are indeed not comparing against FCM. They are just comparing two different methods of running in the background. See: https://github.com/Telegram-FOSS-Team/Telegram-FOSS/blob/master/Notifications.md https://github.com/Telegram-FOSS-Team/Telegram-FOSS/blob/mas...

habosa 7y ago

[Firebase team member here] As far as I am aware, GCM never had an open-source client. In fact I don't think any "play-services-{x}" library has ever been open sourced.

deleted 7y ago
[deleted]