4 ms·

If you think about it, it's actually not even a technological requirement. It's plenty possible to use an Android system service which maintains a connection fo

If you think about it, it's actually not even a technological requirement. It's plenty possible to use an Android system service which maintains a connection for Beeper Mini persistently from the phone. After all that's what GCM does too. Yes, it would require backgrounding permissions, but that is something pretty justifiable for a messaging app, and when using the right UI practices, you can explain this to the user before they grant it. So yes, it's absolutely possible for this app to be 100% client side and I wish Beeper would've done that to start, if for no other reason than to dispel the misinformation around that BPNs is somehow required for the core operation of the app. To be fair, they probably thought making this explicit in their How It Works article would be sufficient.

lxgr 3y ago
Is this actually still possible without (or even with) a foreground notification? I thought Google clamped down on that practice a while ago, since it increases power, data, and memory usage.
- thaumasiotes 3y ago
  > 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.
  - charcircuit 3y ago
    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.
    - 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.
  - lxgr 3y ago
    Well, Google just wants you to use GCM since it solves the same problem without reverting to a cinder block.
- oynqr 3y ago
  Very possible on Android versions that are closer to AOSP. Shitty vendor forks, probably not.
  - charcircuit 3y ago
    Not really, 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]. Element works around this by abusing exact alarms, which require the user to grant a permission, together with a wakelock, but this approach will probably not last forever. [0] https://cs.android.com/android/platform/superproject/+/master:frameworks/base/apex/jobscheduler/service/java/com/android/server/DeviceIdleController.java;l=1041?q=force-idle https://cs.android.com/android/platform/superproject/+/maste...
    - kelnos 3y ago
      > 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.

lxgr 3y ago

Is this actually still possible without (or even with) a foreground notification? I thought Google clamped down on that practice a while ago, since it increases power, data, and memory usage.

thaumasiotes 3y ago
> 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.
- charcircuit 3y ago
  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.
  - 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.
- lxgr 3y ago
  Well, Google just wants you to use GCM since it solves the same problem without reverting to a cinder block.
oynqr 3y ago
Very possible on Android versions that are closer to AOSP. Shitty vendor forks, probably not.
- charcircuit 3y ago
  Not really, 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]. Element works around this by abusing exact alarms, which require the user to grant a permission, together with a wakelock, but this approach will probably not last forever. [0] https://cs.android.com/android/platform/superproject/+/master:frameworks/base/apex/jobscheduler/service/java/com/android/server/DeviceIdleController.java;l=1041?q=force-idle https://cs.android.com/android/platform/superproject/+/maste...
  - kelnos 3y ago
    > 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.