Currently, Android uses content::CompositorImpl for most of its compositor related functionality. This class has a lot of overlap with ui::Compositor (which is what we use on all other platforms). My guess is these started out more different and have had parallel functionality added over time. To reduce maintenance burden, we should try to combine these classes. Some Android specific functionality will still be needed, so we may want to consider an Android-specific subclass, or embedding the ui::Compositor in the Android CompositorImpl (similar to what Mac does).

Note that if we don't take this approach, we may want to investigate breaking ui::Compositor into more shareable components (like CompositorLockManager), and moving these to a common build target to reduce binary size (currently CompositorImpl pulls in ui::Compositor to rely on these).