On desktop, FrameSinkManagerHost is owned by BrowserMainLoop, independently of ImageTransportFactory. On Android, FrameSinkManagerHost is owned by CompositorImpl and a surfaces_utils file contain functions that grab FrameSinkManagerHost from either CompositorImpl on Android and BrowserMainLoop on other platforms.

CompositorImpl implements content::Compositor which is a public interface in content used outside of content by the VR shell.

CompositorImpl is owned by CompositorView on Chrome for Android, and VrCompositor.

CompositorImpl accesses CompositorDependencies which is a singleton that holds FrameSinkManagerHost, FrameSinkIdAllocator and so on. 

It is unclear what the global root object where other objects hang off of is on Android.

We should refactor Android code to use a single code path for accessing the FrameSinkManagerHost and friends.

Perhaps both Chrome desktop and Chrome for Android should use content::Compositor as a singleton?

I don't think any code really needs to access FrameSinkManagerHost. Perhaps content::Compositor can handle higher level concepts like "CreateCompositorFrameSink"?

I think content::Compositor could entirely replace ImageTransportFactory/ContextFactory on all platforms eventually.