Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android now forces apps to include proprietary code for push notifications

reddit.com

Post reply on HN
Print view View original

191–200 of 284 posts

Re: Android now forces apps to include proprietary code for push notifications

#191

Post by AstralStorm »

jayd16 wrote: post #173
ajnin wrote: post #162

Earlier quoted context omitted.

Some types of messages do require immediate attention of the user, or are of highest value if delivered immediately. Instant messaging apps have been using notifications for a long time and did not require a foreground service. Expecting instant delivery of that class of messages is not abusing the system.

While it's not really possible to do this in your own background service any more, GCM still supports this use case. This is the deprioritization the grand parent is talking about. If there's already a notification showing you won't get instant follow up responses. It's a compromise to be sure but if you want to break that compromise you have to make a foreground service.

It was supposed to be possible, via standard notification mechanism and scheduler, new in 7.x. If Google starts flagging apps pinging network off the scheduler, everyone will get even more angry, as there will be a glut of foreground notifications just because they broke a use case.

Re: Android now forces apps to include proprietary code for push notifications

#192

Post by devolute »

throwayEngineer wrote: post #60
deogeo wrote: post #18

Perhaps it is time to treat Google as the enemy, because that is how it is treating us.

Google puts 1 restriction, they are the enemy. Apple has created priopritary connectors, closed off systems, paid barriers to entry, and banning apps from their store. Where is Apple and Microsoft on the scale from Friend to Enemy?

^ this is commonly known as 'whataboutism'.

Re: Android now forces apps to include proprietary code for push notifications

#193

Post by bchimp »

tjohns wrote: post #182
bchimp wrote: post #79

Earlier quoted context omitted.

This has been true for awhile once they forced apps to use API26 or higher (if you want to be listed in the Play store, and really, there is no other place if you want decent exposure.) I had a similar experience switching from "real background" to using FCM. I understand the battery saving motivation, but the problem is that the performance of the google service is terrible. The response time of my simple notificati…

15-20 minutes for a high-priority FCM message isn't normal. Either your app is being rate limited by the server, or there's something unique about your network setup that is preventing push messages from getting through. There's not enough context here to know what's going on. (Plenty of instant messaging apps use high-priority FCM messages, and get near instant delivery.)

I agree, it isn't normal, and I was scratching my head at the time as to why FCM would deliver the messages near instantly on older android models. The delayed delivery happened on Oreo+ phones. Oddly, I also noticed Whatsapp not delivering messages in a timely fashion (even when I had it opted out of battery saving). Background notifications in general started acting odd for Oreo+ phones.

> There's not enough context here ...

Sadly, actually getting context you can use to debug something like this from FCM is nearly impossible. The end result is you just take a WAG and hope for the best when the app gets in the field.

Re: Android now forces apps to include proprietary code for push notifications

#194

Post by izacus »

AstralStorm wrote: post #189
izacus wrote: post #185

Earlier quoted context omitted.

That was exactly the state of the Android until 6.x or so and I've had multiple frustrating hours of mentoring Android developers on how to do notifications respectfully just to be ignored with "eh, I'll poll every 10 minutes, it's easy and it works!". And this has been my experience constantly: - "Eh, I'll just demand full storage access for my game, it's easier to unpack files in root of sd card" - "Eh, I'll just c…

Defending users by actively lying about battery usage is not acceptable. Battery meter in 8 was accurate and flagged battery eating apps accordingly. This new thing is actively lying when you don't use Firebase, as if nobody can ever correctly implement push notifications.

I'm not sure what you're talking about exactly? What's the "new thing" in your post?

(Btw, the on-device battery meter is horribly inaccurate and always has been. Multiple values, like screen power use, are hardcoded by OEM and tracking app power use is not reliable in any case because those graphs are incapable of measuring cascading power efficienty effects coming from using the radio or Play Services.

Use Battery Historian if you want more useful battery use debugging.)

Re: Android now forces apps to include proprietary code for push notifications

#195

Post by AstralStorm »

izacus wrote: post #87
Ajedi32 wrote: post #51

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 hav…

> 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…

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.

Re: Android now forces apps to include proprietary code for push notifications

#196

Post by AstralStorm »

Ajedi32 wrote: post #72
runeks wrote: post #53

Earlier quoted context omitted.

> 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 l…

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.

And Android's battery monitoring should flag them accordingly, not rely on presence of some library.

Re: Android now forces apps to include proprietary code for push notifications

#197

Post by bchimp »

jayd16 wrote: post #173
ajnin wrote: post #162

Earlier quoted context omitted.

Some types of messages do require immediate attention of the user, or are of highest value if delivered immediately. Instant messaging apps have been using notifications for a long time and did not require a foreground service. Expecting instant delivery of that class of messages is not abusing the system.

While it's not really possible to do this in your own background service any more, GCM still supports this use case. This is the deprioritization the grand parent is talking about. If there's already a notification showing you won't get instant follow up responses. It's a compromise to be sure but if you want to break that compromise you have to make a foreground service.

For my use case, the volume of messages was not an issue. This isn't a huge app that is pushing out tons of notifications. We're talking 10's or 100's a day, maybe.

In fact, it didn't matter at all once the initial notification was visible whether follow-on notifications were displayed. Possibly the fact that I was locally dropping the notifications (because the user didn't need them), the system counted those as "notification that weren't interacted with, so I'm going to slow you down at the server."?

I have no idea, and no way to find out, since FCM is pretty opaque at this point.

Re: Android now forces apps to include proprietary code for push notifications

#198

Post by AstralStorm »

izacus wrote: post #97
saurik wrote: post #91

Earlier quoted context omitted.

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)…

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…

Are you kidding me, my old Android 6.0 unupdated S7 can easily top days when idle and polling radio only. The main battery killer is, and always has been, the screen, followed by CPU in high power state.

Re: Android now forces apps to include proprietary code for push notifications

#199

Post by bchimp »

ajnin wrote: post #162
jayd16 wrote: post #151

Earlier quoted context omitted.

>The response time of my simple notification system was nearly instantaneous, but OK google, I'll play your game. I put together something that used FCM and it can take 15 or 20 MINUTES to get even a "high priority" message from FCM. Letting your phone actually sleep is the battery saving feature. Also, you get throttled for high volume so check that as well. If you think your messages are so important to have a cons…

Some types of messages do require immediate attention of the user, or are of highest value if delivered immediately. Instant messaging apps have been using notifications for a long time and did not require a foreground service. Expecting instant delivery of that class of messages is not abusing the system.

Even Apple, with its distaste for background processing, lets you declare an app with "VOIP" mode or something, where iOS manages the socket for you. You get access to simple server-based signaling, and as a bonus, you get to avoid the whole push-notification system.

Google just seems to have glommed everything into FCM. In the FCM console, push-notifications are really treated as a user-engagement/advertising thing. Throttling and spam prevention makes sense for that.

Maybe Android has something like the iOS VOIP mode that doesn't involve annoying the user with scary battery notifications, but I couldn't come up with anything at the time.

Re: Android now forces apps to include proprietary code for push notifications

#200

Post by Tinfoilhat666 »

maxaf wrote: post #142
soulofmischief wrote: post #140

Earlier quoted context omitted.

I don't think you're focusing on the entire picture. Some people here like iOS for the reasons you described. However I'm willing to bet, unless you can show me otherwise, that it's a vocal minority. I don't know of anyone personally who is happy that Apple disallows GPL code. Comparing Apple's digital Fort Knox with Google's unsupervised free-for-all is a false dichotomy. There exists a happy medium, where power use…

Please forgive me for being unnecessarily obtuse this early on a Monday morning. Where does Apple say that GPL code isn’t allowed on the App Store? I ask entirely out of my selfish need to avoid unpleasant surprises later on.

Free Software Foundation says that GPL is not allowed in AppStore and they may request GPL software to be removed from App Store. https://www.fsf.org/news/2010-05-app-store-compliance
Post reply on HN