battery optimization Info on the 1st start

[jakobroehrl]

Without deactivating of the battery optimization some features are maybe not working.
It could be handy to give the user a hint.
Tutanota has the possibility to deactive the battery optimization with one click on the 1st start.

It would be nice, if the app asks on the 1st start for camara and microphone permissions, too.

[jakobroehrl]

@mario
Why do I need to change the battery optimization for talk? Whatsapp is working without doing a change here, why is that?

[mario]

Because Whatsapp has enough 'power' on the market to convince phone/OS vendors to whitelist them inside the operating system code.

[jakobroehrl]

Again 2 users swichted to whatsapp/signal because this nextloud talk thing doen't notifiy after switching to a new phone.
At least a message would be nice.
@mahibi What would have to be done so that battery optimisation is no longer necessary? With whatsapp/signal this is also not necessary.

[mahibi]

deactivating of the battery optimization will always be necessary i guess.
but yes, an info on the first start would absolutely make sense!!

[jakobroehrl]

deactivating of the battery optimization will always be necessary i guess.

Why users don't have to do it on signal, whatsapp, ...?

[mahibi]

Why users don't have to do it on signal, whatsapp, ...?

i'm not 100% sure but i guess they are indeed whitelisted in the operating system code, like mario aready said.
e.g. see https://www.reddit.com/r/signal/comments/l41cth/android_why_does_signal_needs_unstricted_battery/

[jakobroehrl]

Another idea: fairmail and davx5 implemented a permanent notification to prevent killed by android.
Could this be a solution?

[mahibi]

will keep the idea with the permanent notification in mind! but it might be a crutch..

[mahibi]

More apps with good battery optimization options: DAVx^5 and Goodtime
will have a look whenever time allows!!

[mahibi]

i had a closer look if an info about battery optimization makes sense...

The intent that is thrown to change the battery optimization is ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS.
I implemented this quick&dirty in #2107 but it won't get merged.

Unfortunately there are some problems:

ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS is quite unreliable (at least for some vendors)

(not only for the talk app but for all apps that use this intent)
In general there is lots of frustration from android developers regarding the battery optimization settings.
There are many different implementations from vendors as they want to advertise long battery life.
Just some random insights:
https://dontkillmyapp.com/problem
https://www.reddit.com/r/Android/comments/8qjhx7/huawei_oneplus_and_xiaomis_overlyaggressive/
https://stackoverflow.com/questions/33114063/how-do-i-properly-fire-action-request-ignore-battery-optimizations-intent
https://stackoverflow.com/questions/32316491/network-access-in-doze-mode/32424117#32424117

For example for my Redmi Note 7 the behaviour is quite weird:
The UI of the android settings that i can change with the intent doesn't seem to care what i set with the intent.
Whenever i trigger the intent and choose to ignore battery optimization, in the android setting it's still shown as "optimized".
However the check in the talk app which decides if the dialog should pop up says that it's not optimized and the question won't be shown again.

Google doesn't allow ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS for chat apps

As we develop a chat app here, we are not allowed to request battery optimization programmatically.
See https://developer.android.com/training/monitoring-device-state/doze-standby#exemption-cases
So with doing this anyway, we risk to get banned from playstore.
The solution from google is to use FCM high priority messages which we already do, see https://github.com/nextcloud-gmbh/push-notification-proxy/blob/24075b48b373e3e022630eda6d068e51b2cf201d/notification-handling.go#L235
So we have no other choice than to believe google that FCM high priority messages always wake up the phones.

However i'm not 100% confinced that FCM high priority messages always wake up the phones and i can imagine there are vendor specific problems. But i have no proof for this..
To prove problems and reproduce them one can read https://dontkillmyapp.com/ which is also mentioned at https://github.com/nextcloud/talk-android/blob/master/docs/notifications.md

So what else can go wrong and what can we do?

• Check if autostart is an issue check autostart with "AutoStarter" #2113

Assuming the android settings are not the problem, more points of failure could be

• the pushproxy itself or problems with it's hosting
• issues at googles FCM services

i created issue nextcloud/notifications#1206 so users can check on their own if pushproxy & FCM work.