Telegram-foss: Push Notifications help page makes no sense

Created on 15 Aug 2018  路  7Comments  路  Source: Telegram-FOSS-Team/Telegram-FOSS

Hi, I understand the motivations behind the push notifications icon being used to receive messages now as per #172.

But as a native English speaker the document opened by clicking on the notification makes very little sense https://github.com/Telegram-FOSS-Team/Telegram-FOSS/blob/master/Notifications.md

I would fix it, but I don't know what it's trying to tell me.

Things I want to know:

  • why do I have a notification
  • why alternative solutions were rejected
  • why other apps seem to work ok
  • what this change is going to effect (i.e.: battery life)

Thanks

Most helpful comment

Hi! You're very welcome to fix it.

Funny fact first: Google's new restrictions broke more than just FOSS apps. GCM/FCM has always been unstable and unreliable and that's why Telegram and WhatsApp always had their own background services in the first place. Google didn't really fix it before making the thing obligatory, so users of stock ROMs with Google Play Services and upstream Telegram from Google Play are suffering too: https://www.reddit.com/r/Telegram/comments/7zv8ms/something_has_changed_and_it_cant_just_be_oreo_to/

1) Since background services are prohibited now , the service has to be in foreground. Foreground means visible to the user, in our case by putting a persistent notification in the tray. Any attempt to lower visibility is considered hiding a battery draining background work and results in the annoying system notification "This app is using battery" being shown. Still, I have isolated the persistent notification in a separate notification channel, so one may hide it manually. And then hide the system one as well.

2) Alternatives are

  • Keep targetSDK below Android Oreo

    • Upstream did it for a while, but then one can't use newer features and we could just as well stop on v4.6c forever

  • Opt out of battery optimizations

    • While it will certainly fix the problem, battery drain increases in my tests. Some users already had to opt out before due to vendor specific optimizations or other circumstances, yet it would be false to make everyone suffer.

  • Give up, go the JobService way

    • Waking up approximately once in 15 minutes (even that not guaranteed) doesn't seem like instant messaging to me

3) All other apps which require real-time notifications have to either do this, opt out of battery optimizations or use the proprietary FCM library. Oh, one may show a notification with lower priority from the start, but then the system shows the very misleading "This app is using battery" notification. Random links from search: https://github.com/PhilippC/keepass2android/issues/87 , https://github.com/ubergeek42/weechat-android/issues/375

4) No effect on battery life, background service logic didn't change at all. The only effect is the notification itself

All 7 comments

Hi! You're very welcome to fix it.

Funny fact first: Google's new restrictions broke more than just FOSS apps. GCM/FCM has always been unstable and unreliable and that's why Telegram and WhatsApp always had their own background services in the first place. Google didn't really fix it before making the thing obligatory, so users of stock ROMs with Google Play Services and upstream Telegram from Google Play are suffering too: https://www.reddit.com/r/Telegram/comments/7zv8ms/something_has_changed_and_it_cant_just_be_oreo_to/

1) Since background services are prohibited now , the service has to be in foreground. Foreground means visible to the user, in our case by putting a persistent notification in the tray. Any attempt to lower visibility is considered hiding a battery draining background work and results in the annoying system notification "This app is using battery" being shown. Still, I have isolated the persistent notification in a separate notification channel, so one may hide it manually. And then hide the system one as well.

2) Alternatives are

  • Keep targetSDK below Android Oreo

    • Upstream did it for a while, but then one can't use newer features and we could just as well stop on v4.6c forever

  • Opt out of battery optimizations

    • While it will certainly fix the problem, battery drain increases in my tests. Some users already had to opt out before due to vendor specific optimizations or other circumstances, yet it would be false to make everyone suffer.

  • Give up, go the JobService way

    • Waking up approximately once in 15 minutes (even that not guaranteed) doesn't seem like instant messaging to me

3) All other apps which require real-time notifications have to either do this, opt out of battery optimizations or use the proprietary FCM library. Oh, one may show a notification with lower priority from the start, but then the system shows the very misleading "This app is using battery" notification. Random links from search: https://github.com/PhilippC/keepass2android/issues/87 , https://github.com/ubergeek42/weechat-android/issues/375

4) No effect on battery life, background service logic didn't change at all. The only effect is the notification itself

what about a permission called "run in background"? Many apps use that, including your app :)
Currently version 4.9 only works in foreground as you can see that in the battery stats.

@pwn0r not funny
maybe a little bit

@thermatk hello,
I just came across this, an alternative to Google's FCM. if the current Telegram-FOSS solution works perfectly, just ignore this comment ^^ https://f-droid.org/en/2018/09/03/replacing-gcm-in-tutanota.html

I just came across this, an alternative to Google's FCM. if the current Telegram-FOSS solution works perfectly, just ignore this comment ^^ https://f-droid.org/en/2018/09/03/replacing-gcm-in-tutanota.html

Basically the only difference which I can see specifically for Oreo is just that instead of keeping the service on foreground they use a scheduler and relaunch their service every 15min. Not really obvious yet which approach is more battery-friendly. Also they do mention occasional "small delay" so this could be a downside with their approach.

I see, thanks for the reply :)
I'd also prioritize messages not being delayed over anything else really

Made it shorter

Was this page helpful?
0 / 5 - 0 ratings