Conversations: What should we do with user-awareness of vendor-specific "battery optimizations"

[marmistrz]

It's a very common problem nowadays that vendors introduce their own, very aggressive "battery optimizers", as they call it, and actually - app killers. This leads to a serious problem: Conversations sometimes needs extra device-specific tweaks.

Users usually don't know these settings. Often this issue triggers the "facebook/hangouts/whatsapp workz, see how open source suckz" kind of attitude, even in the more technically inclined users.

I know that these "savers" exist - I don't know if there's any API for it or if it's standardized in any way. Probably not.

Additionally, sometimes the operating system may decide to kill the connection, indicating that a foreground service is needed. (this is a sidenote, usually the "optimizers" are a bigger problem)

Could Conversations detect the fact that a) it's being killed by the system b) its connection is getting killed?
In a) it may be difficult to distinguish between the "optimizer kill" and a system shutdown, in b) maybe we could look for some error on the socket?

Alternatively, maybe we could just detect affected Android-spinoffs, such as MIUI and tell the user that they may encounter problems due to what mess their vendor is doing, possibly with a link to a wiki to let the community document the workarounds.

[iNPUTmice]

I don't know if there's any API for it or if it's standardized in any way. Probably not.

No there is not.

Could Conversations detect the fact that a) it's being killed by the system

We tried this. And enabled the foreground service automatically after x-kills in a 24 hour period. It's impossible to come up with the right x since some kills (when the user starts a game or opens the camera) are fairly legit.)

Alternatively, maybe we could just detect affected Android-spinoffs, such as MIUI and tell the user that they may encounter problems due to what mess their vendor is doing, possibly with a link to a wiki to let the community document the workarounds.

The current master tries to detect if the device is a Huawei 6.0 device and adds a special setting briefly describing the problem and deep linking into the activity where you can add Conversations to protected apps.
I can imagine this for other vendors as well but I need pull requests (code) from people who acutally have those phones.

[luiscruz]

This is a really common issue amongst many open source android apps.
I wonder how did facebook/hangouts/whatsapp go around this issue?
Is it because most battery optimizers already whitelist these apps?

[TntDestroyer]

this samsumg dev thread hits on this issue, and whatever Smart is

http://developer.samsung.com/forum/board/thread/view.do?boardName=SDK&messageId=288298&frm=7&tagValue=smartmanager

identifying a manufacturer whitelist

[TntDestroyer]

Adding support for RTT seems like good strategy for positioning whitelist requests

https://xmpp.org/extensions/xep-0301.html

As RTT and doze are antithetical

[iNPUTmice]

I’m closing here since there is no actionable task associated with this.