4 ms·

Whatsapp, facebook, messenger, twitter enjoy unfair advantage from device manufacturers. They whitelist the above apps from their battery management systems an

Whatsapp, facebook, messenger, twitter enjoy unfair advantage from device manufacturers. They whitelist the above apps from their battery management systems and indiscriminately terminate everything else. Summary - figure out how to whitelist telegram on ur phone and you should be fine.

Vinnl 6y ago
See also: this long page in Signal's documentation with device-specific instructions on how to avoid it being throttled [1]. [1] https://support.signal.org/hc/en-us/articles/360007318711-Troubleshooting-Notifications https://support.signal.org/hc/en-us/articles/360007318711-Tr...
ninkendo 6y ago
Huh? That sounds wrong to me. Do you have a source for this?
- zinekeller 6y ago
  There is literally a website for this specifically (https://dontkillmyapp.com/ https://dontkillmyapp.com/) created by the Urbandroid team (creators of Sleep as Android). Rather annongingly, the team started out due to problems encountered on HMD/Nokia phones, since acknowledged and partially fixed (https://sleep.urbandroid.org/documentation/faq/alarms-sleep-tracking-dont-work/#nokia-2 https://sleep.urbandroid.org/documentation/faq/alarms-sleep-...). Personal anecdote: even Google have been wishy-washy between different versions of Android when it comes from battery optimizations (Android 6/Marshmallow is the most hardest on this front), but at least it was documented. Imagine the pain of managing other brands (and it seems that all Android manufacturers engage on it one way or another). Edit: in 2018, VideoLAN/VLC complained that Huawei agressively kills apps outside of its whitelist (https://twitter.com/videolan/status/1022033608670961665 https://twitter.com/videolan/status/1022033608670961665). There is no update on this one unfortunately, but I've heard that it was fixed in subsequent EmUI versions but there is no verification of that from VideoLAN or Huawei. Edit edit: Unrelated to the notfications issue, benchmark scores are allegedly being tricked out by a certain chip manufacturer running the chips out-of-spec in a whitelist (https://www.techarp.com/mobile/mediatek-benchmark-cheating-2/ https://www.techarp.com/mobile/mediatek-benchmark-cheating-2...).
  - ninkendo 6y ago
    Ah, I realized now by context that you’re only talking about android. (You only said device manufacturers so I thought you were referring to iOS as well.) But I had this whole reply typed up for iOS so, may as well include it: — I can only speak for iOS, but it definitely doesn’t work this way on iOS. The ability to run in the background is something you can grant to any app, and there’s no special treatment of any one third party app versus another. It’s not unlimited though even if you do grant the permission... if they use too much memory in the background they may be killed, and there’s a limit to how long they can stay running in the background. Push notifications are supported anyway, because the apps servers are supposed to deliver push notifications to APNS, which delivers them to your phone on behalf of the app even if the app is closed. But the transition from “app is running in the background and notifies you” (which can’t last forever) and “app is killed but the server delivers a notification through APNS” (which works when the app is dead) is often implemented poorly by developers and isn’t seamless. It’s hard to get it right. But no third party apps get treated any different in this regard.
    - zinekeller 6y ago
      I concur. It is indeed more consistent on their devices, probably because the (relative) unfragmented nature of iOS by nature allows to simplify and focus the app development and get consistent results (unlike Android that you can't just match the UI between devices).
  - rhamzeh 6y ago
    The problem isn't killing the apps in the background, it's whitelisting others. I want every app I don't manually allow to run in the background to be terminated after a short period of 30s~60s or so.

Vinnl 6y ago

See also: this long page in Signal's documentation with device-specific instructions on how to avoid it being throttled [1]. [1] https://support.signal.org/hc/en-us/articles/360007318711-Troubleshooting-Notifications https://support.signal.org/hc/en-us/articles/360007318711-Tr...

ninkendo 6y ago

Huh? That sounds wrong to me. Do you have a source for this?

zinekeller 6y ago
There is literally a website for this specifically (https://dontkillmyapp.com/ https://dontkillmyapp.com/) created by the Urbandroid team (creators of Sleep as Android). Rather annongingly, the team started out due to problems encountered on HMD/Nokia phones, since acknowledged and partially fixed (https://sleep.urbandroid.org/documentation/faq/alarms-sleep-tracking-dont-work/#nokia-2 https://sleep.urbandroid.org/documentation/faq/alarms-sleep-...). Personal anecdote: even Google have been wishy-washy between different versions of Android when it comes from battery optimizations (Android 6/Marshmallow is the most hardest on this front), but at least it was documented. Imagine the pain of managing other brands (and it seems that all Android manufacturers engage on it one way or another). Edit: in 2018, VideoLAN/VLC complained that Huawei agressively kills apps outside of its whitelist (https://twitter.com/videolan/status/1022033608670961665 https://twitter.com/videolan/status/1022033608670961665). There is no update on this one unfortunately, but I've heard that it was fixed in subsequent EmUI versions but there is no verification of that from VideoLAN or Huawei. Edit edit: Unrelated to the notfications issue, benchmark scores are allegedly being tricked out by a certain chip manufacturer running the chips out-of-spec in a whitelist (https://www.techarp.com/mobile/mediatek-benchmark-cheating-2/ https://www.techarp.com/mobile/mediatek-benchmark-cheating-2...).
- ninkendo 6y ago
  Ah, I realized now by context that you’re only talking about android. (You only said device manufacturers so I thought you were referring to iOS as well.) But I had this whole reply typed up for iOS so, may as well include it: — I can only speak for iOS, but it definitely doesn’t work this way on iOS. The ability to run in the background is something you can grant to any app, and there’s no special treatment of any one third party app versus another. It’s not unlimited though even if you do grant the permission... if they use too much memory in the background they may be killed, and there’s a limit to how long they can stay running in the background. Push notifications are supported anyway, because the apps servers are supposed to deliver push notifications to APNS, which delivers them to your phone on behalf of the app even if the app is closed. But the transition from “app is running in the background and notifies you” (which can’t last forever) and “app is killed but the server delivers a notification through APNS” (which works when the app is dead) is often implemented poorly by developers and isn’t seamless. It’s hard to get it right. But no third party apps get treated any different in this regard.
  - zinekeller 6y ago
    I concur. It is indeed more consistent on their devices, probably because the (relative) unfragmented nature of iOS by nature allows to simplify and focus the app development and get consistent results (unlike Android that you can't just match the UI between devices).
- rhamzeh 6y ago
  The problem isn't killing the apps in the background, it's whitelisting others. I want every app I don't manually allow to run in the background to be terminated after a short period of 30s~60s or so.