When Android battery saver mode is enabled, incoming MWA connections from Chrome fail

[sdlaver]

When Battery Saver mode is enabled, Chrome web pages are paused immediately upon backgrounding. This breaks MWA, as the dapp is not able to communicate with the wallet.

Wallets should detect this case, and inform the user on why the connection failed, and how to address it (disable battery saver mode).

[steveluscher]

Oh dear.

So maybe we need to have that conversation, again, about using the ability to autoplay a video or not as a way to feature detect low power mode being on or off.

[ankur2136]

On Android its much simpler
https://stackoverflow.com/a/31896873

[steveluscher]

On Android its much simpler

I'm not sure this is a problem for native apps. Native apps aren't as aggressively paused as webpages are.

There are no web APIs for detecting low power mode, because of fingerprinting & security concerns.

[sdlaver]

Proposed solution:

• walletlib detects this case using isPowerSaveMode
• If, after some number of seconds (default: 3), the wallet has not received an incoming connection, it will make a callback to the wallet indicating that the incoming connection may be suppressed by power saving mode.
• On receipt of the callback, the wallet can display appropriate UI to the user, and then return control to the dApp.

[steveluscher]

I think that's good iff this also affects native apps. If it's only web apps that are affected, we should probably find a way to prevent wallet-adapter from even making the call if it believes the device to be in low power mode.

On receipt of the callback, the wallet can display appropriate UI to the user, and then return control to the dApp.

In this event, should we just invent and throw a protocol error and let the dApp handle it? Again, hesitant to do that if it's only web apps that are affected.

[sdlaver]

Yes, it can affect native dApps as well. There's a fix for native dApps (on top of #97) that involves giving a service handle for the backgrounded dApp to the wallet app.

should we just invent and throw a protocol error and let the dApp handle it?

To handle it, the dapp needs to be able to receive the protocol error. For a web dapp, if the websocket connection is never established, there's no way for the wallet to give it any error or result codes.

[steveluscher]

Sorry, I'm not being clear.

1. By ‘affects web/native apps’ I mean ‘there is no mitigation.’ Because native apps have an API (?) to request some unpaused background time, I consider them unaffected by this problem.

2. To handle it, the dapp needs to be able to receive the protocol error. For a web dapp, if the websocket connection is never established, there's no way for the wallet to give it any error or result codes.

   I meant to throw the protocol error from the client. Call transact() on the client. Client throws a SolanaMobileWalletAdapterProtocolError if the phone is found to be in low-power mode (ie. it doesn't even bother trying to associate).

[steveluscher]

Details on a proposed client-only solution, here: #343.