3 ms·
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 sa
by rezonant 3y ago
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.
- lxgr 3y ago> 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.
- rezonant 3y ago> 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.