Android: when a renderer crash, the framework might recreate the renderer service. |
||
Issue descriptionService connections are create with Context.BIND_AUTO_CREATE. This causes the service to be recreated if it dies and a binding is still bound. When a service is disconnected, we do remove all bindings to make sure the Android framework does not recreate that service. (and we let the browser handle it) As part of recent refactoring of ChildProcessLauncher, we made ChildProcessConnection run on the launcher thread only. So we now add a thread hop between the time we get the disconnection notification and the time the unbind all connections. The process may then be restarted by the framework during that thread hop, which might cause problems.
,
May 11 2017
What if we stopped using Context.BIND_AUTO_CREATE and stopped the service from onDisconnected()? Stopping the service only requires the intent, so it's thread safe to do it directly from the callback. I think that would prevent a restart.
,
May 11 2017
the problem is without BIND_AUTO_CREATE, bind won't start the service, iirc, because I tried that :p also my mental model for this is that start/stop is orthogonal to bindings. If there are bindings, then stop won't actually stop the service. But I didn't try that. And it's odd to stop a service that we didn't call "start" on, so I'm not sure if that works.
,
May 11 2017
I tried with a test app. Without BIND_AUTO_CREATE, you do have to call startService() and bind(). And then when you call stopService() it does stop the service, even if there are still bindings bound to it.
,
May 11 2017
we can't call startService though. background check..
,
May 12 2017
Could you elaborate why we can't call startService()? I hacked a quick CL to test this and it seems to work. (and I call startService())
,
Aug 1
|
||
►
Sign in to add a comment |
||
Comment 1 by boliu@chromium.org
, May 11 2017