> I thought Google clamped down on that practice a while ago, since it increases power, data, and memory usage.

I don't really follow the reasoning. If saving on power, data, and memory usage were more important than the ability to receive messages, it would follow that you were better off carrying around a cinder block than a phone.

Having n apps all actively querying various servers all the time will waste resources. The solution Google provides is Firebase Cloud Messaging which is the blessed notification service on the system which handles querrying notifications for all apps. FCM even avoids waking up the system from idle if the notification received is not high priority and can wait until sometime in the future when the device momentarily stops idling to processing everything at once before idling again.

Well except that maintaining a connection to APNs is cheaper than spinning up periodic tasks to connect to APNs to check for new messages, and is exactly the same process that GCM itself uses (persistent connection), and you probably only have one such messaging app, so unless GCM is considered a major battery drain (hint, it's not) I think it would be fine.

And in this case, GCM actually creates potential vulnerability. This should be allowed, and if Google sees it as a problem, they should implement a system service to retrieve from APNs. I believe the API is public.

Backgrounding is problematic when devs do it wrong or disrespect the user, but this isn't one of those cases.

Android preventing background processes in this case is worse for the user.

> and you probably only have one such messaging app

That sounds extremely unrealistic. If nothing else, you already have GCM – I don’t think it deactivates the persistent connection even if you don’t have any notification registrations.

> Backgrounding is problematic when devs do it wrong or disrespect the user, but this isn't one of those cases.

But how would Google distinguish “disrespecting” from intentional use cases?

I’ve used Android for years, and uncontrollable background services were a big problem.

> unless GCM is considered a major battery drain (hint, it's not)

It’s as much a battery drain as APNs. The point is that I want as few of these persistent connections and background services as possible, and the ideal number is one.

> That sounds extremely unrealistic. If nothing else, you already have GCM –

I'm confused. GCM is Google Cloud Messaging. It's also known as FCM or Firebase Cloud Messaging. It is the Google Play equivalent of Apple Push Notification Service (APNs). It's job is just to provide a persistent connection for delivering push notifications.

> I don’t think it deactivates the persistent connection even if you don’t have any notification registrations.

It seems almost impossible to be running an Android phone that has zero push notification subscriptions registered.

> But how would Google distinguish “disrespecting” from intentional use cases?

Via app review and banning apps that abuse those use cases. It turns out you can also decimate the user's battery using the stuff Google still lets you do (like periodic background tasks), but we don't ban those things because otherwise your phone would be useless at that point. Of course both the periodic task system and the persistent background service both would show up in your battery usage statistics, so the user and the system would be plenty aware that the app is misbehaving. And of course Google Play Protect can send along that feedback back to the Play Store in both cases.

> I’ve used Android for years, and uncontrollable background services were a big problem.

Cool, I also have used Android for a long time! Started on the Nexus 5 back in 2013 and have used Android devices ever since.

> and uncontrollable background services were a big problem.

Hm, I wouldn't say they were a big problem but I guess I just used well behaved apps. Certainly restricting background behavior helped battery life, but at what cost?

What you might not realize is that there are a number of permissions that you can declare in the Android manifest that trigger the Play Store review to be... just a little more thorough about your apps behavior. This should be one of those permissions. Using it for a persistent connection to a messaging service is absolutely a valid use case for this sort of thing. That's not the kind of thing that caused battery problems on your older Android phones though.

This is also very analogous in App Store. You declare certain plist declarations that need to be justified, and cause your app to be more carefully reviewed.

Well, Google just wants you to use GCM since it solves the same problem without reverting to a cinder block.

Very possible on Android versions that are closer to AOSP. Shitty vendor forks, probably not.

No, unless the user goes to the settings and disables battery optimization for the app. If the device is idling the app will only be able to wake up periodically. Starting at 15 minutes and exponentially grows to up to 6 hours [0].

[0] https://cs.android.com/android/platform/superproject/+/maste...

> Not really, unless the user goes to the settings and disables battery optimization for the app

That sounds "very possible" to me. Apps can even pop up a dialog on first run instructing the user to disable battery optimization, and then load up that settings page when the user taps a button in the dialog. Certainly some people will be confused by it, still not know what to do, or not want to do it, but it's still quite possible.

And if the user won't do it, the app can still spin up a service with a foreground notification if they really want to keep things working decently well, and use Android's scheduled jobs mechanism to restart the service every 10 minutes (or however often) to catch cases where the service still ends up getting killed.