DEV Community: Evgeny Khramov

I Let a Coding Agent Render Android UI Without an Emulator. A Screenshot Wasn't Enough.

Evgeny Khramov — Fri, 25 Sep 2026 17:16:17 +0000

When a coding agent changes Android XML, it is fairly confident about what it can read: it finds the layout, understands the constraints, and produces a diff. But there was almost always one more manual step afterwards. I would open the screen and decide whether the button, the text, or the card had actually ended up in the right place.

I wanted to remove that repeated switch. I was not trying to hand over responsibility for the product or to declare the emulator unnecessary. I wanted the result of the agent's changes to be available inside the same workflow in which it edited the code.

My first idea was a screenshot: the agent changes XML, gets an image, and looks at it. In practice, that turned out to be only half of the solution.

The setup

The loop I wanted for XML/View screens:

change XML → render → check the result → fix

I put the rendering into a local MCP server built with Kotlin/JVM and Robolectric. The agent supplies a layout and explicit data for it, and gets the rendered result back. MCP is not the interesting part here. It is just a way to take me out of a repetitive intermediate step: launching the render by hand and passing the result back to the agent.

The scope is deliberately narrow. This is for XML/View projects, not Compose. It is not a replacement for a device, it does not promise a pixel-for-pixel match with a physical phone, and it does not try to emulate hardware surfaces, video, or a camera.

The PNG worked, and the tool was still not finished

The screenshot made the result visible immediately. The agent could notice that text was clipped, that a block had unexpectedly disappeared, or that two elements were clearly overlapping. That was already better than editing XML blind.

At that point the project looked almost done. Screenshots were generated, the MCP server responded, and an inspect_view tool existed.

A closer review broke that impression. The screenshot was real, but the sidecar returned an artificial root node as the View tree. There was no real child View to query, so a tool called inspect_view was barely useful.

That showed how much an image alone leaves unresolved. It is poor at answering the questions that often decide whether a UI change is correct:

What is the actual distance between two Views?
Has an element gone beyond the screen boundary?
Where exactly is the View with a particular id?

A person can estimate these by eye. The agent needs verifiable data, not just an illustration.

A second wrong assumption: the warm JVM

Around the same time the coding agent pointed out another oversimplified idea in my design. You cannot just start the Robolectric runtime once and keep reusing it after changes to XML or Kotlin: you risk inspecting stale resources and an outdated classpath.

That observation changed the architecture. It removed the temptation to treat a "warm JVM" as a problem we had already solved. The default sidecar still is not the persistently warm JVM from my early architectural plan.

The fix: measure what you render

The turning point was simple to state: the PNG and the data must come from the very same layout, after layout has been performed.

After inflate → fixture → measure → layout → draw, the renderer saves both the image and the real View tree. Each node includes its identifier, type, text and state, padding, margins, and absolute bounds.

Three small operations make up the loop:

render_layout  → creates a render session
get_view_tree  → returns the tree of that session
inspect_view   → returns a single node by id

The API names matter less than what they allow. The agent can move from "these look a little too close together" to a measurable fact, such as comparing the edge of a button with the edge of its container without estimating anything from a PNG.

That gave us a geometry feedback loop:

change → render → inspect → evidence → fix

The image helps reveal a problem, the tree provides the geometry, and the next change goes through the same render again.

Underneath there are also a source fingerprint and an allowlisted Gradle pipeline. They exist so the loop cannot silently render stale state or run arbitrary shell commands.

Testing it on a real layout

After these changes I connected the MCP server to an actual Android project I was working on. The coding agent used it to fix a real product-card layout with a required-items section.

Before the fix. The UI is in Russian.

After the fix. The UI is in Russian. The two screenshots show different items, so they are not a pixel-level comparison.

For me this was the key acceptance test. The tool had moved beyond its RFC and its own unit tests into a real UI task, and a coding agent used the loop in an actual UI change.

What the experiment did and did not prove

What I wanted to check	Result
Can a real Android XML/View layout be rendered through MCP + Robolectric?	Yes
Can a real, machine-readable View tree be returned alongside the PNG?	Yes
Did a coding agent use this loop in a real UI change?	Yes
Can the agent's actions be fully reproduced from the saved data?	Not yet

I do not consider this a replacement for an emulator or a device. Robolectric does not guarantee a pixel-perfect match with hardware. I have no compatibility matrix covering custom Views and complex themes. For the next experiment of this kind I want to keep the complete record: the prompt, the tool calls, render IDs, the XML diff, the measurements, and the final verdict.

These are reasonable limits for a first version. What matters more is that they can now be described as facts rather than as the impression left by a good screenshot.

Who did what

I did not give the agent the authority to "decide the UI." I defined a bounded problem, set the limits of support, refused to accept a PNG as sufficient evidence, and kept bringing the work back to verifiable criteria.

The coding agent was more than a code generator. It helped implement the tool, flagged the risk of a stale Robolectric runtime, and helped build and use the loop itself.

For me the main result is not that the agent now has an image. A screenshot makes an interface visible. A PNG together with a View tree makes it verifiable.

That is how manual visual review can leave the routine loop: not because I decided to trust the agent, but because it gets artifacts that can be measured and checked again.

The renderer is open source: android-ui-renderer-mcp on GitHub. The full case study is on my site: hram.github.io/en/articles/android-ui-renderer-mcp.

A Coding Agent Tried to Fix My CameraX Rotation Bug by Waiting. I Asked for Proof Instead.

Evgeny Khramov — Fri, 25 Sep 2026 16:26:51 +0000

My Android barcode scanner had a CameraX bug: after rotating a tablet through 180°, the preview still looked correct, but the frames received by the analyzer were upside down.

The interesting part wasn't the final fix. It was deciding when we actually had enough evidence to trust it.

A coding agent handled most of the debugging: reading the code, adding instrumentation, running adb logcat, changing the implementation, and checking the results. I handled the physical tablet.

The debugging loop was unusual.

The agent started adb logcat. I opened the scanner and physically rotated
the tablet. Then the agent collected the new values and adjusted the
instrumentation.

We repeated this several times until we had the states we needed to compare.

These were the values that eventually explained the bug. Before rotation:

Configuration.orientation=2
displayRotation=1
analysisTargetRotation=1
imageRotation=0

After rotation:

Configuration.orientation=2
displayRotation=3
analysisTargetRotation=1
imageRotation=0

The display had moved on. ImageAnalysis had not.

Getting to that evidence required stopping a different line of work first: waiting for a rotation value to update, then rebinding the camera.

How we nearly ended up waiting for the wrong thing

During an earlier experiment, the agent observed that the display-change callback had already fired while previewView.display.rotation still held the old value. About half a second later, that value became correct.

The agent concluded:

post is not enough. We need to wait for previewView.display.rotation to actually change before rebinding.

The proposed direction looked like this:

DisplayListener
→ callback
→ display.rotation still has the old value
→ post
→ still the old value
→ wait
→ get the new rotation
→ rebind CameraX

I stopped the work at that point. I did not yet know the correct fix. We might have needed another listener, different ImageAnalysis settings, or a deeper investigation of YUV processing.

But the timing approach left basic questions unanswered. Why did rotating the tablet require recreating the camera use cases? What exactly were we waiting for? Half a second on this tablet—how long on another?

I asked the agent to stop fixing things and prove the cause first.

Measure the states that should agree

We added these values to the diagnostics:

Configuration.orientation
displayRotation
Preview.targetRotation
ImageAnalysis.targetRotation
ImageProxy.rotationDegrees

Then we repeated the physical experiment. The agent started a fresh log capture; I opened the scanner screen and rotated the tablet. It collected the output, adjusted the instrumentation, and asked me to repeat the experiment when needed.

That produced the before-and-after logs at the top of this article.

The tablet had moved from ROTATION_90 to ROTATION_270. Both positions were still landscape, so Configuration.orientation remained 2:

ORIENTATION_LANDSCAPE → ORIENTATION_LANDSCAPE

The display already reported rotation 3, while the analyzer retained its old target:

display                 ROTATION_270
ImageAnalysis.target    ROTATION_90

ImageProxy.rotationDegrees consequently remained 0.

We now had a specific, measured cause: ImageAnalysis.targetRotation was not being updated when the device rotated through 180°. That gave us something concrete to fix and a way to verify the result.

Update the existing use cases

The implementation moved to this flow:

OrientationEventListener
→ calculatedRotation
→ Preview.targetRotation = calculatedRotation
→ ImageAnalysis.targetRotation = calculatedRotation

The existing Preview and ImageAnalysis instances remained in place. Handling the rotation no longer required delay, postDelayed, polling, unbindAll(), or bindToLifecycle().

There was one subtle mapping detail. The degrees reported by OrientationEventListener could not be mapped directly to the Surface.ROTATION_* constant with the same angle in its name. In our case, the range 45..134° had to map to ROTATION_270, not ROTATION_90.

We verified the change with the same physical experiment. Before rotating the tablet:

displayRotation=1
previewTargetRotation=1
analysisTargetRotation=1
imageRotation=0

After rotation:

orientationDegrees=70..79
calculatedRotation=3
displayRotation=3
previewTargetRotation=3
analysisTargetRotation=3
imageRotation=180

The chain was consistent. CameraX received the new targetRotation, and ImageProxy.rotationDegrees changed from 0 to 180, without recreating the use cases or rebinding.

These are the observations from our tablet and scanner. The mapping detail belongs to this case; it is not a claim that the same implementation has been verified on every device.

What the agent did, and what I still had to decide

The agent performed most of the mechanical work. It read the existing code, added diagnostics, collected device data, analyzed the logs, changed the implementation, repeated the checks, and updated the merge request.

My contribution included designing the experiment, physically rotating the tablet, evaluating the hypotheses, and deciding what would count as sufficient evidence.

At the critical moment, I did not know the right five lines of Kotlin. I could still recognize that “the value arrives later, so wait for it” was an incomplete explanation of the bug.

The useful intervention was to require the agent to show where the state diverged. That changed both the investigation and the fix.

For me, the reusable lesson is to make the verification criterion explicit: identify the states that should agree, capture their values during the failing behavior, and repeat the same experiment after the change. Here, that meant checking the display rotation, both use-case targets, and the image rotation together.

A coding agent can run much of that loop. Deciding what the experiment proves—and whether its evidence justifies accepting the fix—remains engineering work.

The full case study includes the debugging dialogue and a more detailed breakdown of how we divided the work.