Spots 
My coding agent could already render a single Android XML layout through Robolectric and get back a PNG plus a View Tree with pixel bounds. Then I pointed it at a real screen from a work app, and one layout stopped being enough.
A real screen is an Activity shell, a Fragment container, a RecyclerView with data, and states like a loading overlay. Launching the production Fragment would drag in DI, navigation, networking and the rest of the app's runtime. I wanted something narrower: a screen real enough for visual checks, without running the app. This is how android-ui-renderer-mcp got composed-screen rendering.
The work screen can't be shown, so every image here is a render of an open demo app in the same repository (sample/). It has the same structure — Activity with a toolbar, Fragment, RecyclerView, master-detail, loading overlay — and each image can be reproduced from the request stored next to it.
The work screen can't be shown, so every image here is a render of an open demo app in the same repository (sample/). It has the same structure — Activity with a toolbar, Fragment, RecyclerView, master-detail, loading overlay — and each image can be reproduced from the request stored next to it. The boundary: real resources, explicit state
That is the main design decision: the renderer uses the app's real UI resources, but takes runtime state from a deterministic request. Otherwise it becomes one more way to run the app, only harder than an emulator. Activity + Fragment as one render target
A new render_target tool supports one target kind, activity_fragment. It inflates the Activity XML, finds the container, inflates the Fragment XML separately and inserts it. The production Fragment class never starts.
The toolbar title and menu icons come from XML (app:title, app:menu); no Activity code ran. The details on the right are an <include>, filled from the request.
I'm not emulating the Fragment lifecycle. I need its visual result from real resources, because the agent changes XML and has to see what ends up on screen. Deterministic RecyclerView rows
An empty RecyclerView says little about the real UI, and running the production adapter would pull real data back in. So list data became part of the request: the real itemLayout, the orientation, the rows, and a fixture per row. The renderer creates a temporary adapter and inflates the real item XML for each row. One row from the request above, the selected book:
The UI structure is real; the data is test data and fully controlled. The renderer doesn't guess values from tools:*. If the agent wants three rows, it describes three rows. Frozen spinners for loading overlays
My coding agent could already render a single Android XML layout through Robolectric and get back a PNG plus a View Tree with pixel bounds.