fix: keep the main process active while the WebView is in the foreground - #60
fix: keep the main process active while the WebView is in the foreground#60ItsChaceD wants to merge 2 commits into
Conversation
OS-pedrogustavobilro
left a comment
OS-pedrogustavobilro
left a comment
There was a problem hiding this comment.
This PR doesn't seem bad according to some docs
- https://developer.android.com/develop/background-work/services/bound-services
- https://developer.android.com/guide/topics/manifest/service-element
- And probably most relevant one https://source.android.com/docs/core/perf/cached-apps-freezer that talks about if a service is launched it keeps the app's process from freezing.
However, this issue (assuming it's the same issue) seemed to have happened with older versions before the WebView activity moved to its own process, so it's hard to say if this PR would actually fix anything.
Be that as it may, we should keep it open for now, and see if we can reproduce the actual issue and then check if this fix helps at all.
PS: Left a minor comment
| bindService(Intent(this, OSIABKeepAliveService::class.java), connection, Context.BIND_AUTO_CREATE) | ||
| keepAliveConnection = connection |
There was a problem hiding this comment.
Minor: In accordance to the docs https://developer.android.com/reference/android/content/Context#bindService(android.content.Intent,%20android.content.ServiceConnection,%20int), the method can throw SecurityException, and we should call unbindService in that situation (and I guess if we do we don't need to assign keepAliveConnection. Can we add that here perhaps?
I don't think we need to fail the activity on that exception, as the webview would still function as is right?
2 participants
Description
Bind the isolated WebView activity to a small service that lives in the main app process, for as long as the browser is open.
Since the WebView moved to its own process, the main app process has no visible UI while the user is in the browser. Android treats it as idle and freezes it about 30 seconds into a browser session. A frozen main process can't run the app's event handlers, so pages like payment callbacks load in the browser but the app never reacts and never closes it. On stock Android the process thaws when an event arrives, so it recovers. Vendor freezers like Samsung's don't thaw, which leaves users stuck on a blank page. Connecting a USB cable disables Samsung's freezing, which is why the problem never reproduced while capturing logs.
The service binding makes Android treat the main process as active while the browser is visible, so it never becomes freezable. The binding only happens in the isolated process; the sharing (in-process) variant doesn't need it.
Context
https://outsystemsrd.atlassian.net/browse/RMET-5394
Type of changes