A closer look at parameter-state encoding, compiler IR analysis, comparison propagation, SlotTable storage, and the optimizations that happen before recomposition decisions reach the runtime.

Jetpack Compose doesn’t need to compare every argument passed to every composable function.

The compiler already knows that some arguments cannot change. Consider a simple composable:

@Composable
fun ProductCard(
    title: String,
    isAvailable: Boolean
) {
    ProductCardContent(
        title = title,
        isAvailable = isAvailable,
        maxLines = 2,
        showDivider = false
    )
}

Four arguments are passed to ProductCardContent, but they don't all have the same characteristics.

title and isAvailable originate from the parent composable's parameters. Their change status can potentially be inherited from the parent. maxLines and showDivider, on the other hand, are fixed expressions.

There is no reason for the child composable to compare 2 against a previously stored 2, or false against a previously stored false.

These expressions can be identified at compile-time by the Compose compiler and stored in a synthetic parameter of type integer called $changed.

This means that the compiler doesn’t just pass argument values. It passes information about those values.

Understanding how this works will show us two very similar optimizations.

Static argument elimination and comparison propagation.

Both of which reduce the number of comparisons performed at runtime and the amount of storage space required in the SlotTable for detecting parameter changes.

The implementation details below are based on the AndroidX Compose compiler source. The generated signatures and bit structure are an internal part of the compiler and therefore can vary between releases.

1. Why Compose needs a parameter change-tracking mechanism

A composable function is not an ordinary function call from the runtime’s perspective.

Consider:

@Composable
fun UserProfile(name: String) {
    Text(text = name)
}

The compiler transforms composable functions to communicate with the Compose runtime. Among other things, it introduces synthetic parameters such as:

• A Composer reference.
• A $changed bitmask describing the state of the arguments.
• Additional changed masks when the parameter count requires them.
• Default-argument metadata where applicable.

Conceptually, the transformed function resembles:

fun UserProfile(
    name: String,
    $composer: Composer<*>,
    $changed: Int
)

This is illustrative pseudocode, not the exact generated JVM signature.

The runtime will need to know if the parameters of the function have changed since last run. If this information is not available from the caller then the generated code can call Composer.changed() to compare the current value with the previous stored value.

That comparison requires storage in the SlotTable.

The SlotTable stores all information related to the composition including previous values used by the runtime (e.g. parameter comparison and remember).

The crucial observation is that this comparison is only necessary when the compiler and caller don’t already know the answer.

This is precisely what $changed communicates.

We can look at the implementation in the ComposableFunctionBodyTransformer in the compiler. This handles the composable skipping, default arguments and comparison propagation.

2. Anatomy of the $changed bit field

The $changed parameter is an integer bitmask. It packs multiple pieces of information about the composable's parameters.

In the implementation examined, the compiler uses:

const val BITS_PER_INT = 31
const val SLOTS_PER_INT = 10
const val BITS_PER_SLOT = 3

Why 31 bits instead of 32?

The lowest bit is used to represent a function level flag which can be used to force execution. The next 30 bits are used to store ten 3-bit values representing parameters.

The effective layout is:

More precisely:

The compiler calculates a parameter’s offset using:

fun bitsForSlot(bits: Int, slot: Int): Int {
    val realSlot = slot % SLOTS_PER_INT
    return bits shl (realSlot * BITS_PER_SLOT + 1)
}

A function with more than ten tracked parameter slots requires additional changed-mask integers.

Three bits of data are allocated to each parameter. However only 2 bits are used to indicate the comparison state.

The remaining bit carries stability metadata.

The two-bit comparison state

The comparison states are:

The third bit is used to represent instability where required:

The compiler’s StabilityBits implementation defines:

UNSTABLE = 0b100
STABLE   = 0b000

Consequently, Static is encoded as 0b011 within the three-bit slot, with the stable marker remaining clear.

For parameter slot zero, the actual shifted value is:

Static = 0b011 shl 1
       = 0b00000110

This compact representation allows the compiler to communicate both comparison state and stability information without introducing an object for every parameter.

3. How the compiler determines that an argument is static

The optimization begins before runtime execution, it happens at compile time.

The Compose compiler works with Kotlin Intermediate Representation (IR), and during its lowering passes, it examines the expressions being passed to composable functions, collects metadata about the arguments.

The relevant implementation uses structures named CallArgumentMeta and ParamMeta.

Conceptually, CallArgumentMeta records:

data class CallArgumentMeta(
    var stability: Stability,
    var isVararg: Boolean,
    var isProvided: Boolean,
    var isStatic: Boolean,
    var paramRef: ParamMeta?
)

This is a simplified representation of the compiler’s actual implementation.

The compiler examines the argument expression and determines:

1. Whether its value can be established as static.
2. Whether it originates from an enclosing composable parameter.
3. Whether its stability is known.
4. Whether it was explicitly provided or comes from a default expression.
5. Whether the argument is a vararg.

The static-expression analysis is implemented in AbstractComposeLowering.kt, particularly through IrExpression.isStatic().

Expressions the compiler can classify as static

The implementation recognizes several categories.

Compile-time constants

Text(
    text = "Hello",
    maxLines = 2
)

IR constant expressions can be classified as static.

Enum values

alignment = AlignmentOption.Center

Enum entries are treated as static.

Immutable local variables

val maxLines = 2

Text(
    text = title,
    maxLines = maxLines
)

An immutable local variable can inherit static classification from its initializer.

A mutable variable doesn’t receive the same treatment.

Stable object and companion-object references

The compiler can classify object references as static when the relevant stability conditions are satisfied. Companion-object references receive special handling.

Stable property access

Certain read-only properties with default getters and stable return types can be classified as static, provided their receivers are also static. Stable annotations can also participate in this analysis.

Operations on static values

The compiler recognizes selected Kotlin operations, including arithmetic and Boolean operations, when the operation, result type, and operands satisfy its staticness conditions.

For example, a computation involving only constant operands can be classified as static.

The compiler also has specialized handling for certain function calls, including eligible stable functions with stable return types and static arguments.

This is not general-purpose constant folding. The compiler uses specific structural and stability rules to establish that an expression is safe to treat as static.

A dynamic state read remains dynamic.

val currentMaxLines = uiState.value.maxLines

Text(
    text = title,
    maxLines = currentMaxLines
)

The fact that currentMaxLines is declared using val doesn't make it static. Its initializer depends on observable runtime state.

This is an important distinction: immutability of a local reference is not proof that its value is constant.

4. Comparison propagation: avoiding repeated work across composable calls

Static argument elimination is only half of the optimization.

The compiler also propagates parameter comparison results through the composable call graph.

Return to the earlier example:

@Composable
fun ProductCard(
    title: String,
    isAvailable: Boolean
) {
    ProductCardContent(
        title = title,
        isAvailable = isAvailable,
        maxLines = 2,
        showDivider = false
    )
}

The compiler can identify that title and isAvailable directly reference parameters of ProductCard.

It doesn’t need to make ProductCardContent independently compare those values if ProductCard already knows their change status.

The ParamMeta structure contains the parent parameter's slot index and a reference to the relevant changed or dirty mask.

When constructing the child’s changed mask, the compiler can extract the parent’s parameter state and move it into the child’s corresponding slot.

The logic is effectively:

The actual implementation is more involved because it handles slot offsets, multiple masks, stability metadata, default arguments, and different expression types.

The important operation is in buildChangedArgumentsForCall().

For each argument, the compiler decides whether to:

• Set a static state directly.
• Propagate a known parameter state from the parent.
• Mark the argument uncertain.
• Handle varargs or omitted defaults through their specialized paths.

The resulting child mask is assembled using constants, bitwise operations, and shifts.

This prevents re-doing the same comparison at each level of a composable hierarchy.

We can split these into two useful categories:

• Static classification: The compiler can prove that an expression will never change.
• Comparison propagation: The compiler propagates a comparison result (which has been proven) from one composable to another.

Both reduce the number of comparisons, but use different information.

5. What happens inside the composable function

The receiving composable uses the incoming $changed mask to decide whether any parameter comparisons remain necessary.

Consider the conceptual logic:

if (parameterState == Uncertain) {
    parameterState =
        if (composer.changed(value)) {
            Different
        } else {
            Same
        }
}

This is simplified pseudocode, not literal generated source.

The important detail is that Composer.changed() is called only when the incoming state requires a comparison.

When called, the runtime compares the current value against its previously recorded value and updates the SlotTable bookkeeping.

The resulting state is reflected in the local $dirty mask.

Three cases have different consequences:

Uncertain: A comparison is required. The runtime needs the previous value to establish whether the parameter changed.

Same or Different: The caller already performed the necessary comparison. The callee can use the propagated result without performing another comparison or retaining a duplicate previous value for this purpose.

Static: No comparison is necessary at all. The compiler has established that the argument cannot change.

This is why the optimization saves more than the cost of comparing two integers or references. It can also eliminate the parameter-specific SlotTable entry used solely for change detection.

The distinction is documented in the compiler source comments: the uncertain state is the one that can require SlotTable space for the comparison.

6. Static default arguments are another optimization opportunity

Composable functions frequently use default parameters:

@Composable
fun ProductTitle(
    title: String,
    maxLines: Int = 2,
    color: Color = LocalContentColor.current
) {
    Text(
        text = title,
        maxLines = maxLines,
        color = color
    )
}

The compiler handles default values for composable functions with the use of a separate $default bitmask.

This mask must not be confused with $changed.

• The $default bitmask will tell you which arguments were not provided.
• The $changed bitmask tells you about the parameter comparison and stability.

The default mask has one bit per parameter to indicate if the default expression needs to be evaluated.

The compiler can also optimize the default expression.

For maxLines = 2, the compiler knows the default is static. If the caller omits the argument, the resulting parameter can be assigned the Static state.

For color = LocalContentColor.current, the result depends on the composition environment. It cannot simply be treated as an immutable constant.

The compiler must preserve the behavior of dynamic defaults, including the possibility that they contain composable calls or observable state reads.

This also affects generated composition groups. When default expressions require runtime evaluation, the compiler may generate a defaults group to ensure that they are reevaluated correctly when necessary. When all defaults are static, it can avoid some of that machinery.

This is a useful example of how a seemingly minor expression-level optimization can influence the generated composition structure.

7. Static does not mean stable, and neither guarantees skipping

There are three concepts that need to remain separate.

Static describes an argument expression that cannot change during program execution.

Stable describes whether Compose can reliably determine changes to an object’s observable properties.

Skippable describes whether a composable can avoid executing its body when called during recomposition and its relevant inputs remain unchanged.

For example:

@Composable
fun UserName(name: String) {
    Text(
        text = name,
        maxLines = 1
    )
}

String is a stable type, but name can change between compositions.

maxLines is static because it is fixed.

The composable’s ability to skip execution is a separate decision involving its other parameters, restartability, invalidations, and runtime state.

Strong skippingis an extra dimension. Enabled by default from Kotlin 2.0.20 onwards. If a composable is restartable, it can be skipped even if it contains unstable parameters. Parameters will be compared using structural equality if stable, or instance equality if strong skipping is enabled.

Static arguments are another optimisation. The compiler does not need to compare parameters since it can confirm the argument will never change.

This does not stop recompositions happening due to a State being read within the composable, or the CompositionLocal changing or some other invalidation.

The optimization concerns parameter change detection, not every possible reason a composable might execute.

8. How to inspect static argument optimization in your project

The compiler exposes reports and metrics that help investigate how it analyzes composables.

For Kotlin projects using the Compose compiler Gradle plugin, enable reports and metrics:

composeCompiler {
    reportsDestination =
        layout.buildDirectory.dir("compose_compiler")

    metricsDestination =
        layout.buildDirectory.dir("compose_compiler")
}

The generated reports include several useful artifacts.

module.json: Contains aggregate metrics such as:

{
  "staticArguments": 25,
  "certainArguments": 138,
  "knownStableArguments": 377,
  "knownUnstableArguments": 25,
  "totalArguments": 426
}

These values illustrate the types of metrics available. They are not measurements from a particular application.

staticArguments counts arguments identified as static at composable call sites.

certainArguments provides information about arguments for which the compiler can propagate comparison metadata.

composables.txt: Provides composable signatures with parameter stability and default-expression classifications.

For example, the output can distinguish:

stable maxLines: Int = @static 2
stable color: Color = @dynamic ...

This helps identify cases where a default expression is treated as dynamic rather than static.

composables.csv : Contains function-level metrics that can be inspected programmatically or compared between builds.

The compiler metrics documentation explains the report formats and their interpretation:

One limitation matters: these reports don’t expose every generated $changed bit pattern at every call site. They provide compiler-analysis information, not a runtime trace of all bit-level decisions.

For deeper investigation, inspect the compiler’s IR transformation and generated bytecode for a small, isolated example. Avoid depending on synthetic parameter positions or bit encodings in application code.

The optimization is about eliminating information the runtime no longer needs

The static bit is an aspect of a larger change-tracking mechanism.

The compiler categorizes expressions, tracks parameter states via composable calls, and then encodes them as compact integer bit masks. The runtime checks for value equality only if the incoming metadata does not provide a clear outcome.

This means two separate benefits:

1. Static expressions do not require the runtime to compare parameters or store prior value states for change checking.
2. If values have been checked by the caller, there is no need to check them multiple times at each composable.

Neither optimization ensures that a composable is skipped from execution. However, both decrease the effort needed to make that decision.

For Android developers evaluating Compose performance, this is an important consideration. Performance of recomposition is not dictated by the number of composables executed but also by how effectively the compiler and runtime determine whether those executions are necessary.

The $changed mask is one of the mechanisms that makes that possible.

Sources

• Parameter states, mask encoding, comparison propagation, default processing and skipping
• IrExpression.isStatic() and the compiler's static-expression classification
• Stability-bit representation and generated stability metadata
• staticArguments, certainArguments, and compiler report formats
• Historical documentation of comparison propagation and static parameter optimization
• SlotTable and composition implementation
• Stable and unstable parameter comparison behavior
• Skippable and stable versus unstable equality checks

Inside Jetpack Compose’s $changed Bit Field: Static Arguments and Fewer Runtime Comparisons was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

When I finished my app SnapReturn this fall, I hit the same wall a lot of indie Android developers hit: Google wouldn’t let me publish to production until I ran a closed test with at least 12 testers for 14 days. I’m an Android developer by day, so I figured this part would be easy. It wasn’t.

I got one friend and three family members. My Reddit posts got a few replies, and some of those people disappeared after a day or two. What finally got me through was a group of developers testing each other’s apps. Here’s everything I learned along the way.

The rule, in 30 seconds

If your personal Play Console account was created after November 13, 2023, you need to run a closed test before you can publish to production. It needs at least 12 testers who stay opted in continuously for at least 14 days. Then you answer a set of questions about your test and wait for Google to review your application.

• The 14 days must be consecutive, and testers who leave early don’t count.
• A tester who opts out and back in starts their count again.
• Organization accounts don’t have this rule.

Google’s rules can change, so check Google’s help page for the latest.

Why “12 opted in” isn’t enough

The number is the easy part to understand. The part that trips people up is engagement. When you apply for production, Google asks how engaged your testers were, what feedback they gave, and what you changed because of it. Developers regularly report being asked to keep testing even after reaching 12, because their testers barely opened the app.

So the real goal isn’t 12 names on a list. It’s 12+ people who actually use your app, often enough that your answers to Google are true and specific.

Where to find testers

Recruit 15–20, not 12. Someone always drops out, and a spare tester only helps if they opted in from the start.

Set up your test so nobody gets stuck

• Use a Google Group for testers. Anyone can join it, and you add the group to your closed track once, instead of collecting everyone’s email.
• Make the test available in all countries. If it’s limited to your country, testers elsewhere can’t install it, and they won’t always tell you.
• Share the “Join on the web” link from your closed track, and remind people to use the same Google account for the group and the opt-in.
• Publish the release and wait for Google’s review of the closed track before you send the link. An unreviewed track shows testers an error.

Keep testers engaged for 14 days

• Give a small task each day. “Open the app” gets ignored. “Add a recipe from a website” gets done, and it gets the part you care about tested.
• Keep tasks short. A couple of minutes is the sweet spot. Your testers are doing you a favor.
• Ask for one sentence of feedback: what worked, and what got in the way. Short notes add up to real evidence.
• Ship at least one update during the test, and tell testers what you fixed. It shows Google the test changed your app.
• Check Play Console’s tester count every few days. It’s the number Google uses.

Write down what happens as you go

When you apply for production, Google asks about three things:

• Your closed test: how you recruited testers, whether they used all your features, and what feedback they gave
• Your app: who it’s for, its value, and how many installs you expect in the first year
• Your readiness: what you changed after testing, and how you decided the app was ready

It’s much easier to answer honestly if you kept notes: which features got tested, the problems testers found, and what you fixed. Specific, true answers hold up. Vague or exaggerated ones don’t.

The short version

1. Recruit 15–20 testers, not 12.
2. Use a Google Group and make the test available in all countries.
3. Give testers a short task every day.
4. Fix what they find, ship an update, and keep notes.
5. Answer Google’s questions with what really happened.

After going through this myself, I built Fourteen, where groups of 16 Android developers test each other’s apps daily for 14 days, with short tasks and an optional SDK that confirms real use. It also drafts your answers to Google’s questions from your test data. The first cohort begins Saturday, November 14, 2026. Whatever route you take, I hope this saves you some of the time it cost me.

More guides: Why production access gets rejected · How to answer the production access questions

Originally published at https://getfourteen.app on November 8, 2026.

How to get 12 testers for Google Play closed testing (and actually pass) was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Although AI can do more and more for engineers, it will not replace them. Coding has always been only one part of software development, and engineers are more likely to evolve from people who implement code into people who use AI to build the entire development system. Rather than panic, we can keep learning and evolve alongside AI.

What Agentic Engineering Does

(Figure from Harness engineering for coding agent users)

An AI Coding system usually has three components: a foundation model, a Coding Agent tool, and the context, skills, and verification system supplied by the engineering team. All three affect the quality of the final deliverable.

The foundation model sets the upper bound for reasoning, code comprehension, and generation. As models such as Claude, GPT, and Gemini improve, their first-pass success rate on complex tasks generally rises, but so does the cost. In practice, teams trade off cost, response time, and reliability. Even with a top-tier model, complex business requirements, cross-module refactoring, and performance investigations cannot be completed reliably in a single generation pass. This is especially true in Android projects: Gradle builds, build variants, resource and manifest merging, Jetpack component lifecycles, JNI/NDK, R8 obfuscation, app startup paths, and UI rendering all increase the Agent’s comprehension burden.

Coding Agent tools organize model capabilities into an executable development loop. Tools such as Claude Code, Codex, and CodeBuddy include system prompts, file search, editing, command execution, task decomposition, and context compaction. Some tools also train models in real tool-use environments, making them better at reading repositories, changing code, running tests, and repairing failures. This surrounding system is commonly called the harness: the execution environment around the model.

The context and skills supplied by engineers determine whether the Agent acts correctly in a particular project. For an Android team, that context includes the app’s business goals, module boundaries, architecture layers, shared components, design system, build procedures, test commands, performance budgets, staged rollout rules, privacy and compliance requirements, and directories or interfaces that must not be changed casually.

(Figure Inspair by Harness engineering for coding agent users)

To enable high-quality AI delivery, engineers must do at least two things: guide the Agent to work with the right context, and enable it to verify that its output is correct. These correspond to Context Engineering and Harness Engineering, respectively.

Context Engineering asks, “What does the Agent see when making decisions?” A large language model is essentially stateless: each output is determined by the current context window. When context is accurate, complete, and concise, the Agent makes more reliable judgments. When context is disorganized, outdated, or noisy, even a strong model may generate code from faulty premises.

Harness Engineering asks, “How does the Agent know it got the job done right?” For Android, delivery cannot be judged solely by whether code was generated. It must also compile, preserve architecture constraints, pass critical test cases, conform to UI specifications, avoid performance regressions, and include the required analytics instrumentation and staged rollout strategy. Without such feedback, an Agent can mistake “I wrote a lot of code” for “the task is complete.”

From an Agent Software Factory to a Controlled Development Process

If context, tools, and verification are taken to their limits, can AI Agents do all the work of software development themselves? That is the premise of the AI Agent software factory.

(Figure from Why the Software Factory Failed)

Some in the industry have already tried a lights-off software factory: requirements enter a queue, and Agents automatically implement, test, fix, and commit changes, sometimes even handling production feedback. Such systems can look highly efficient in the short term because code generation really is faster than manual coding. But in a complex production codebase, a process where nobody reads the code or reviews the design is not sustainable.

For now, think of an Agent as a new engineer joining the team. Writing prompts, describing requirements, and assigning tasks amount to communicating requirements remotely. Even communication between people has information gaps: the business background, implicit constraints, and trade-offs in a requester’s head are hard to convey completely to the implementer, and written records inevitably contain omissions and ambiguities. The problem is more pronounced for an Agent, which can only infer the system’s intent from its current context and tool results. Research and Plan should therefore be vehicles for iterative discussion, not one-off documents. During planning, engineers need to keep asking questions, adding constraints, and correcting misunderstandings until the scope of change, architectural direction, edge cases, and verification approach are confirmed.

Does an approved Plan guarantee good code? Still no. Even code written by an experienced engineer needs review. Agents make mistakes too, whether in the form of hallucinated assumptions, incorrect API usage, duplicated logic, excessive abstraction, or inappropriate fallbacks added merely to pass tests. After multiple iterations, a seemingly minor disturbance can propagate along a dependency chain and eventually produce a tangled codebase that is difficult to understand or change. Plan Review addresses whether the direction is right; Code Review addresses whether the implementation is right. Neither can replace the other.

The underlying issue is not that the prompt needs to be better, nor can it be solved by adding a few more loops. Most current coding benchmarks reward passing tests but struggle to penalize damage to maintainability. A model can pass tests with local hacks, duplicated logic, poor abstractions, excessive fallbacks, or workarounds that bypass the type system. The costs of those choices often emerge only weeks, months, or even a year later.

No matter how much efficiency AI brings, the fundamental problems of software architecture and software engineering do not disappear. How should modules be divided? How should dependencies be controlled, state managed, concurrency coordinated, errors propagated, and systems evolved? Faster code generation does not automatically answer any of these questions. Pitfalls engineers encountered decades ago still appear today in new forms. The communication costs, system complexity, organizational coordination, and design principles discussed in classics such as The Mythical Man-Month, Peopleware, and works on distributed systems are even more worth revisiting in the AI era. AI can shorten the path to implementation, but it cannot make architectural judgments for the team or bear the codebase’s long-term maintenance costs.

Long-term maintainability is particularly important in Android codebases. A screen working today does not mean it handles lifecycle management, state restoration, resource cleanup, retries on poor networks, internationalization, accessibility, dark mode, foldables, and performance budgets correctly. A cross-platform dynamic UI approach may suit promotional pages or e-commerce campaign pages, but in a highly interactive utility app, an audio/video scenario, or an experience requiring a high frame rate, it may impose costs in time to first frame, scrolling, input latency, and native feel. Architectural trade-offs must be judged against the business model, user scale, team capabilities, and future evolution — not just immediate generation speed.

Why Plans and Code Both Need Review

(Figure Inspire by https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/ace-fca.md)

The earlier an error occurs, the greater its amplification effect. One bad line of code is a local problem; a flawed implementation plan can produce hundreds of lines of wrong code; a misunderstanding of the requirements or a faulty technical research conclusion can steer the entire feature in the wrong direction.

Human review in Agentic Engineering should therefore not be reserved for the final Code Review. The higher-leverage review points come earlier:

• During requirements analysis, confirm the user problem, success criteria, edge cases, and explicit exclusions.
• During system architecture, confirm module boundaries, data flow, API contracts, threading model, and state management.
• During program design, confirm core types, call chains, file layout, dependency direction, and error-handling strategy.

For Android development, Plan Review should at least ask: Are we changing the right module? Is the code going in the right place? Are we using the right screen architecture? Do we need to add or update unit tests? Will the change affect app startup, the main thread, or memory usage?

Where Humans Must Stay Involved

(Figure Inspire by https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/ace-fca.md)

A workflow suitable for Agents can be divided into six steps:

1. Requirements or problem analysis: Input may be a feature request, bug report, production alert, user feedback, or test case. The output should clarify the business goal, reproduction steps, impact, and acceptance criteria.
2. Codebase research: Have the Agent read the relevant modules, call chains, historical implementations, and test baselines, and produce a research document rather than changing code immediately.
3. Solution planning: Based on the research, produce a plan that identifies which files to change, why, how to verify the changes, and where the risks lie.
4. Human review of the plan: Engineers focus on whether the direction is correct, abstractions are appropriate, and verification is sufficient.
5. Staged implementation: The Agent implements the plan, running a build, tests, or device verification after each runnable increment.
6. Human review of code and reports: Engineers inspect key diffs, verification results, and uncovered risks, then decide whether to extend the work, roll it back, or hand it over for testing.

This process does not remove people from development. Instead, it asks engineers to shift their attention from repetitive coding to high-value judgment: clarifying requirements, making architectural trade-offs, enforcing quality gates, and accepting deliverables.

Context Engineering: Helping the Agent Work with the Right Context

Large language models do not have true long-term memory. For a Coding Agent, the current context window is the primary basis for understanding a project. Context management is not simply a matter of “feeding it more material”; it requires controlling information quality — accuracy, completeness, concision, and loading information on demand.

(Figure from https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/ace-fca.md)

A good AGENTS.md, CLAUDE.md, or project-level guide should answer the questions an Android Agent most often encounters:

• What does the app do, and what are its core user journeys?
• How are the Gradle modules organized, and in which direction do dependencies run among App, Feature, Core, Data, Design System, and Native modules?
• Which architecture is used — for example, MVVM, MVI, Clean Architecture, Redux-like state management, or a custom framework?
• What is the UI stack — View System, Jetpack Compose, or both — and how should themes, color palettes, component libraries, and design tokens be used?
• How is the data layer organized — for example, Repository, UseCase, Room, DataStore, networking SDKs, caching policies, and offline support?
• What are the build and verification entry points — for example, common variants, assemble tasks, lint, unit tests, on-device tests, screenshot tests, NDK builds, and native unit tests?

This file needs regular maintenance, but it must not grow without bound. Stuffing every module detail into the initial context consumes the model’s attention budget. Even with a large context window, too much irrelevant information diffuses attention and makes mistakes on critical decisions more likely.

A better approach is layered context: keep only a project map and navigation index at the root; record local rules in module-level documents; and put specialized knowledge about builds, tests, performance, releases, analytics, privacy, and other topics in dedicated documents. The Agent reads only the top-level guide at the start of a task, then follows the index to the relevant documents when it enters a module.

Context Engineering also requires frequent, deliberate context compaction. Code search results, build logs, failed attempts, long JSON payloads, and test output can all pollute the context. In a complex task, the Agent should compress noisy information into structured artifacts at each Research, Plan, and Implement stage: which files have been read, what it currently understands, which options were ruled out, what risks remain, and how to verify the next step. That way, the next Agent — or a human taking over — does not have to reconstruct the state from a chat history.

Rules, skills, MCP integrations, and external tools also consume context and tokens. Do not load every capability up front unless necessary. Load progressively: bring in build instructions when the task requires an Android build, and device-operation and testing skills only when UI verification is needed.

Harness Engineering: Defining What Counts as Done

Context answers, “Does the Agent know what to do?” Harness answers, “How does the Agent know it has done it correctly?”

In an Android project, harness controls fall into two categories:

• Feedforward controls: Constraints and guidance supplied before the Agent acts, such as architecture rules, module boundaries, coding standards, shared-component usage guides, and testing requirements.
• Feedback controls: Executable feedback supplied after the Agent acts, such as Gradle builds, Android Lint, Detekt/Ktlint, unit tests, Compose UI Tests, Robolectric, instrumentation tests, NDK builds, gtest, and static architecture checks.

Checks with deterministic, CPU-executable outcomes should be moved as early as possible. These include compilation, lint, type checks, unit tests, module-dependency checks, complexity checks, and coverage checks. Semantic judgments — whether a design is overengineered, tests cover the core business behavior, or a UI meets product expectations — can be supported by AI review, but engineers must still make the final call.

The point of a harness is not to dictate a rigid path to the Agent, but to define the desired deliverable clearly. Too many process constraints limit the model’s ability to discover better solutions. As model capabilities improve, yesterday’s protective procedures can become obstacles. A more robust approach is to prescribe fewer step-by-step instructions, provide more capabilities, boundaries, and acceptance criteria, let the Agent plan its own work, and catch mistakes with executable verification.

Improving Agent Output Quality

Once a Coding Agent generates code, it must first pass engineering-level verification. For Android, at a minimum, the target variant must compile, and all relevant Kotlin/Java code, resources, manifests, and native code must pass through the build pipeline. Modules involving C++ also need NDK compilation and native unit tests. UI changes need checks for shared color palettes, shared components, consistent spacing, the theme system, and accessibility properties.

But a successful build is only the lowest bar. Whether a client feature is actually correct depends on business logic, lifecycle handling, state restoration, thread switching, error handling, data consistency, and dependencies outside the client behaving as expected.

Improving Testability with IoC and DI

Unit testing is mature in the Android ecosystem, but much legacy code is difficult to test. Common problems include business logic scattered across Activities and Fragments; ViewModels that access global Managers directly; network, database, configuration, account state, and experiment flags read through singletons; utility classes that hide I/O; and Native and Kotlin layers coupled through interfaces that are difficult to replace.

Such code is not impossible to test; it is simply too expensive to test. To make a module testable, external dependencies must be separated from business logic and passed in through interfaces and constructor injection. This is the principle of Inversion of Control (IoC) and Dependency Injection (DI). On the Kotlin/Java side, teams can use Hilt, Dagger, Koin, or an in-house container. On the C++ side, dependencies can be wrapped using Fruit or a lightweight factory.

The value of dependency injection is not merely cleaner-looking code. It gives both Agents and engineers a stable way to replace dependencies. When testing a ViewModel, they can mock networking, databases, account state, experiment flags, and the time source. When testing a Repository, they can swap out remote services and local caches. When testing a Native ViewModel or business core, they can run fast local tests without an Android device.

In the era of manual coding, retrofitting DI and tests into legacy modules was often tedious. Coding Agents are well suited to this kind of well-defined refactoring: they can identify global dependencies, extract interfaces, adjust construction paths, add tests, and run verification at each step. Engineers should focus their reviews on whether interface boundaries make sense, whether testability has come at the expense of sound design, and whether excessive abstraction has been introduced.

Layering Unit Tests and Client-Side Verification

Android tests can be layered by feedback speed and fidelity.

JVM unit tests are the fastest. They are well suited to ViewModels, UseCases, Repositories, state machines, data transformations, business rules, and error handling. With dependency injection, an Agent can create or update tests for every requirements change, covering happy paths, edge cases, failures, and regressions.

Next come Robolectric and lightweight framework tests, which can validate some Android Framework-dependent logic but cannot fully replace a real device. Further down the stack are instrumentation tests, Compose UI Tests, UIAutomator, and screenshot tests, which validate screen behavior, interaction flows, and visual fidelity on real devices. Native logic should be verified quickly with local gtest runs whenever possible, rather than requiring a full app launch every time.

For screens built with Jetpack Compose, UI state should be driven by a stable state model, with Composables kept free of side effects — or limited to minimal ones — where possible. Then an Agent can build tests around state inputs and UI outputs instead of fragile tap sequences. For older View System screens, business decisions should likewise be moved out of View callbacks into a ViewModel or Presenter to make UI automation less brittle.

Observed Results

Take CreatePostViewModel.cpp, which handles editing topic posts. After a dependency injection refactor, a Coding Agent can enumerate and generate unit tests for the main business paths: drafts, topic selection, body validation, image state, publishing failures, retries, and recovery from errors. Each change runs native unit tests before moving to client integration verification. The real benefit is not "more tests"; it is catching low-level C++ logic errors before handoff to QA and giving engineers more confidence in letting the Agent change complex logic.

Preventing Feature Gaps: From Unit Tests to Integration Acceptance

Unit tests can protect client-side logic, but a requirement is never delivered simply because “the client code is done.” Complete delivery also depends on accounts, server APIs, configuration delivery, experiment flags, assets, operations consoles, analytics instrumentation, staged rollout, and test cases. Before handing a feature to product and QA, teams generally also need integration test cases to demonstrate that the primary flow works.

At its core, integration testing verifies end-to-end behavior: launch the full app, use a real or near-real account, perform a sequence of actions, and observe screen state and service responses. In other words, the system must “see what is on the device screen, perform the next action, and then judge whether the outcome matches expectations.”

The Android SDK already provides capabilities such as adb, UIAutomator, screenshots, accessibility trees, log capture, file retrieval, and Intent-based launching. Android CLI tools and community projects aimed at Coding Agents now package these capabilities into testing skills the Agent can call. Projects such as Trailblaze attempt to connect device control, screen understanding, test recording, and verification into one workflow.

One important lesson from Trailblaze is that device verification need not rely heavily on screenshots and OCR. Reading the UI hierarchy and accessibility information first can greatly reduce token usage while helping the model identify controls, text, and hierarchy more reliably. Screenshots and OCR are better used as fallbacks when the UI tree is unavailable or visual judgment is required. If verification targets Android only, the official Android CLI and Skills can also be used instead of Trailblaze for device control and integration testing.

If a QA team maintains integration test cases, a practical Android Agent verification workflow might look like this: export integration test cases from a test management platform or XMind and convert them to structured Markdown; connect a test device and install the target build; have the Agent execute each case step by step; capture the UI tree, screenshots, and logs at each step; when a failure occurs, record the current screen, action history, key logs, and suspected cause; finally, produce a test report identifying passed, unexecuted, blocked, and human-review-required cases.

Alternatively, if nobody maintains integration test cases, tests can be created with Journeys and run by the Agent using Android CLI.

To help the Agent execute those cases, provide a feature guide. It might be a user-facing wiki or a web page the Agent can access, explaining how to reach and operate the feature so the Agent does not have to guess its way through the app.

This approach can cover most stable primary flows, such as login, publishing, search, list refresh, form submission, configuration changes taking effect, and error messages. It still has limits: cross-device interactions, complex gestures, video playback experience, animation flicker, subtle visual fidelity, unstable network conditions, and perceived performance still require humans or specialized testing tools. The Agent’s value is to run the automatable integration paths first and organize clear failures and omissions, allowing engineers, QA, and product managers to focus on the problems that genuinely require judgment.

Conclusion

The diagram below summarizes the building blocks of an Android harness. Guides provide context and quality standards before coding. The Coding Agent performs Research, Plan, Implement, and Repair. Sensors provide feedback on builds, behavior, performance, and stability. The system then preserves test results, code diffs, and runtime metrics as evidence of delivery. Human Review sits at high-risk decisions and final acceptance; when tests fail or metrics regress, the feedback goes back to the Agent for correction.

The goal of Agentic Engineering is not to create an unsupervised software factory, but to help Android engineers deliver software with greater leverage. AI accelerates research, generates code, adds tests, runs verification, and compiles reports. Humans decide whether the requirements are right, the architecture is sound, the quality bar has been met, and which risks cannot be delegated to a model.

In an Android environment marked by long product lifecycles, demanding experience requirements, and fragmented devices, reliable AI Coding does not mean “getting the Agent to write more code.” It means “getting the Agent to write code with the right context and prove it is correct through executable verification.” Context Engineering determines whether the Agent understands the system; Harness Engineering determines whether it can validate the outcome; and human review determines whether the codebase remains healthy over time.

References

• Advanced Context Engineering for Coding Agents
• Why the Software Factory Failed
• Harness Engineering
• Use Feature Lists to Constrain What the Agent Does
• Awesome Harness Engineering
• Awesome Context Engineering
• Trailblaze

AI Coding for Android: Reflections and Building Self-Verification was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Part 3: Sharing the UI without losing the safety net

Part 2 ended on a pattern: the code that moved most easily was the code that knew nothing about Android. By that logic the UI layer should have been the worst part of the migration. It touches the screen, the system bars, the keyboard, the back gesture — everything that is unmistakably a platform.

And, much to my amazement, it wasn’t. The composables moved about as easily as the domain models did.

What didn’t move was everything around them. The resource system, the build plugins, the preview tooling and the screenshot tests were all built on the assumption that a Compose module is an Android library module. Once that stopped being true, the application code was fine and the ecosystem around it wasn’t.

Sharing application code turned out to be easier than sharing the ecosystem around it. That’s the whole article.

What moved easily

Most composables moved to commonMain unchanged. Layout, state, theming, animation — Compose Multiplatform covers the surface BikeHub uses, and the diff for a typical screen was mostly imports.

Two things made this smoother than it would otherwise have been.

The UDF layer went first. Every feature module in BikeHub uses Ouroboros-Compose, a small unidirectional-data-flow library (influenced by Spotify’s Mobius, that I used back then, when views and fragments ruled the android UI). It abstracts the ViewModel away and keeps the UI logic in plain, testable classes. I refactored it to KMP as step 0 of the whole migration, before touching a single feature module.

That ordering mattered more than it looks. Because the UI logic doesn’t sit inside an Android ViewModel, there was no androidx.lifecycle dependency threaded through 38 feature modules waiting to be unpicked. The state holders were already just Kotlin.

Android platform code in the UI layer was already a code smell. I’d treated it that way for years, so there wasn’t much of it to find. There were some LocalContext.current calls that were easy to abstract away, and lots of text and drawable resources.

The result is visible in the module layout. Of all the feature modules, most have exactly one file outside commonMain, and it’s a preview file. Only two have anything resembling real platform code: one needs a PlatformWebView, and another needs to know whether notification settings are a thing on the actual platform at all.

If you want a single predictor of how painful your own UI migration will be, it’s probably this: how much Android your presentation layer touches that isn’t Compose itself.

What’s actually in androidMain

Part 1 put androidMain at 12% of the Kotlin code, and I quoted that figure for a while as “the Android-specific part of the app”.

It isn’t. Of 13,843 lines in androidMain, 9,653 lines — 70% — are @Preview functions. Seventy-four files whose entire job is to render a composable in Android Studio’s preview pane and feed the screenshot tests.

Take those out and the genuinely platform-specific Android code is about 4,190 lines, under 4% of the codebase.

That reframes the whole migration for me. The thing I’d been calling “platform code” was mostly tooling scaffolding — the price of being able to look at the UI on one platform, not the price of running it on three.

That the previews sit in androidMain at all is a fossil of an abandoned attempt. The @ComponentPreview annotation is expect/actual, so the preview functions could live in commonMain — but they were written for Android’s @Preview, because the original plan was to drive the screenshot tests from them with Compose Preview Screenshot Testing. That plan didn’t survive the migration, and the previews stayed where they were.

Roborazzi wasn’t the first choice. Compose Preview Screenshot Testing is the more appealing option on paper: you write the previews you’d write anyway, and the tooling renders them. I tried it, and it doesn’t work in a Kotlin Multiplatform module. So I went back to Roborazzi, which runs under Robolectric in the androidHostTest source set the KMP Android target already provides.

The previews I’d written for the first approach are still there — 9,653 lines of them — now feeding Android Studio’s preview pane rather than a test runner.

What didn’t move: the UI layer’s real platform seams

Strip out the previews and what’s left is a short, specific list. All of it lives in core:designsystem and core:ui, behind expect/actual:

• BackHandler — a back gesture on Android, a different idea on iOS, and the browser’s history on the web.
• FullScreenDialog — what “full screen” means is decided by the host.
• ContainerSize — how the available window is measured.
• PhotoPager and ZoomAsyncImage — pinch-zoom and paging over photos.
• PhotoHandler and a couple of Modifier extensions in core:ui.
• PlatformWebView in one feature module, because an embedded web view is four different things.

Everything that leaves the app entirely — a browser, the store listing, the OS notification settings — goes through a single ExternalNavigator interface with one implementation per platform, so no feature module ever touches it.

And then there’s the preview annotation itself:

An expect/actual pair whose only job is to let one platform’s tooling see the code, and to make that annotation harmless everywhere else. It’s a small thing, and it’s the clearest single illustration of what this article is about: the UI moved, the tooling around it needed an adapter.

Resources: one module, two workarounds

All resources — strings, drawables, fonts — live in a single core:res module under commonMain/composeResources. One module, one generated Res class, every other module depends on it.

The upside of centralising is obvious: one place to look, no duplicate keys, no per-module resource packaging to configure. The cost is equally obvious — core:res is a dependency of almost everything, so touching a string rebuilds a lot.

What I didn’t expect was needing a reflective workaround to make it usable downstream. The Compose Multiplatform resources plugin doesn’t wire up the output directory of its Android assets copy task in a library module, and the task type is internal — so there’s no typed API to set it with:

Reflection in a build file is not a thing I enjoy looking at. It’s there because the alternative was no stable location for the generated assets, and the next section depended on having one.

The safety net: Roborazzi in a KMP module

BikeHub’s visual regression safety net is Roborazzi, running under Robolectric. The tests live in each module’s androidHostTest source set — the host-side test variant of the KMP Android library target — and one convention plugin, bikehub.multiplatform.screenshot, turns them on. Forty modules apply it. The tests sit next to the code they cover, inside the multiplatform modules themselves.

A test is about as plain as it gets:

A shared ScreenshotTest base class in core:testing handles the rest: each case renders in light and dark, across a device set defined once as specs rather than device names, captured at half scale to keep the PNGs down, compared with a 0.1 threshold.

And this is where the resource problem came back

Robolectric renders the UI on the JVM, and it reads resources from the module’s test assets. Compose Multiplatform resources don’t arrive there on their own, so the screenshots came out with missing images and unresolved strings.

The fix is the second half of that convention plugin: a Sync task that copies the generated resources out of core:res’s build output — the stable location the reflective workaround above created — into the host test assets, sequenced around the Android asset merge:

Two workarounds chained together, one in core:res and one in the screenshot plugin, to make a Compose Multiplatform module’s resources visible to an Android host test. The application code involved in this is zero lines. Tooling again.

What it’s worth, and what it isn’t

Two trade-offs I’d want you to weigh before copying this setup.

It only covers one platform. Compose Multiplatform renders through Skia on iOS and the web. A green screenshot suite tells me the composables are stable on Android, and nothing about the other two targets. By the way, If you do, how do you cover that gap? Any solutions are welcome :)

55 MB of PNGs live in the repository. That’s the price of a diff you can look at. Recording at half scale keeps it from being much worse. CI runs verifyRoborazziAndroidHostTest, and on a pull request it re-records and pushes a commit when verification fails, which keeps the loop moving but means an unintended visual change can be accepted by not looking at it carefully enough.

What I’d take away

Check your tooling before you change your module types. Swapping com.android.library for com.android.kotlin.multiplatform.library is a one-line change with a long tail. Anything keyed to “this is an Android library module” — tests, previews, resource packaging — needs a plan afterwards, and planning it is cheaper than discovering it.

Keep platform code out of the presentation layer, for reasons that have nothing to do with KMP. It’s good practice on one platform too. It just happens to decide whether your UI layer moves in an afternoon or a month.

Up next

Part 4: Shipping WebAssembly to Production. Getting a multiplatform app to build is one thing. Making it work reliably in a browser is another: caching, a large bundle, deep links, and the browser’s security model.

Migrating a Real Android App to Kotlin Multiplatform 3/4 — Sharing the UI without losing safety net was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello! 👋 Welcome to the first episode of AI by lazy, a series about the Android chores we keep postponing, handed to an AI agent and then checked by a human who is slightly less lazy than the title suggests.

We start with a classic. Open the build.gradle.kts of a mature Android app and there is a decent chance you'll find this in the release block:

isMinifyEnabled = false

Nobody on the team remembers why. Somebody tried once, something broke, and the flag has been guarding the release build ever since, like a “do not touch” sign that outlived the person who wrote it.

Turning R8 on is one line. Making it safe is the chore. So I gave that chore to an agent three times, with different context and different tools, and checked everything it did on a real device.

Here is the route:

1. Why R8 stays off, and what that costs
2. R8 in one minute, and why reflection breaks
3. How I delegated it
4. What each run did
5. What I checked, and what I found
6. Which keep rule is right, and why this result doesn’t generalize
7. The rule to take away, and the verdict

One disclosure before we start. The demo app, Later, was generated with AI for this series, and its technical debt was planted on purpose. Later is a to-do app for procrastinators: every task has a “Later” button that pushes it to tomorrow and increments a counter.

Yes, a series about postponed chores runs on an app about postponing. I couldn’t resist. 😅 The results below are real and reproducible on that app, but its debt is cleaner than the debt in a product with years of history, and I’ll come back to that.

Why R8 stays off

At a previous job, the team had tried to enable R8, ran into problems, wrote it down in Confluence and moved on. A year later I joined that company, enabled it by hand, with no AI to help, and it went fine.

I don’t tell that story to look clever. Whatever broke the first time was real at that moment. What interests me is what happened next: a failure nobody re-tested kept R8 off for a year. The Confluence page became the truth, and nobody asked what we actually knew when we said “R8 breaks the app.”

Keep that question in mind, because it comes back at the end with a twist.

Leaving R8 off isn’t free. You ship more code than you use, startup pays for it, and Google has started to measure it: Android vitals now flags apps whose DEX is poorly optimized, and apps with more than 10 MB of DEX that don’t meet its threshold “may see store visibility impact starting from February 2027” (Android vitals).

Google also publishes partner stories with big numbers, like Reddit reporting 40 % faster cold starts after enabling the full power of R8. Those are self-reported case studies, not an average you should expect, but they explain why “we’ll do it later” is getting more expensive.

R8 in one minute

R8 is the optimizer that runs on your release build. It does three jobs:

• Shrinking: it starts from your entry points (activities, services, anything the manifest declares) and removes the code nothing reaches.
• Optimization: it rewrites what’s left, inlining methods and merging classes.
• Obfuscation: it renames classes, fields and methods to short names like a and b, which also makes the DEX smaller.

Since AGP 8.0, R8 runs in full mode by default, which is more aggressive: for example, keeping a class no longer implicitly keeps its no-args constructor. And since AGP 9.3 there is a simpler way to turn it all on:

buildTypes {
    release {
        optimization {
            enable = true
        }
    }
}

That one block enables code shrinking, resource shrinking and a set of default keep rules equivalent to proguard-android-optimize.txt, and your own keep rules live in .keep files under src/main/keepRules/ (Enable app optimization).

Where reflection breaks

Now the part that bites. R8 decides what to keep by following references in your code. Reflection hides those references. Later downloads its “remote” tasks as JSON and parses them with Gson into two small Kotlin data classes, RemoteTask and RemoteTaskResponse. Nothing in the app ever calls their constructors; Gson creates them at runtime. From R8's point of view, those are classes nobody builds and fields nobody reads.

To see the failure for ourselves, we took the starting point of the experiment, turned R8 on with that block and no keep rules, and tapped sync on a Pixel 7. The APK went from 11.5 MB to 4.2 MB, and the first sync crashed:

lj0: Abstract classes can't be instantiated! Adjust the R8 configuration or register
an InstanceCreator or a TypeAdapter for this type. Class name: ke1

R8 had removed the constructor and marked the class abstract, and ke1 is what was left of its name. Even the exception got renamed: lj0 is Gson's JsonIOException in disguise, which is why release crash reports need the mapping file to make sense. This time we actually watched it fail. Remember that, too.

How I delegated it

The setup:

• Agent: Claude Code with Claude Opus 5.5.
• Tools available in the repo: Google’s official r8-analyzer skill, installed with the Android CLI 1.1, and my own android-emulator-control skill, which builds, installs and drives an app on a device.
• Device: a Pixel 7 on Android 17, connected over USB.
• Project: Later on AGP 9.5.1 and Gson 2.15.0, starting from the tag ep1-before.

These results belong to this model and these versions. A different agent, or this one next month, may behave differently. What should transfer is the way we checked.

I ran the same chore three times, each in a fresh session and on its own branch:

Run A got the blind prompt with no skills visible (they were installed after the session started). Run A' got the same blind prompt with the skills visible. Run B got the prompt with context about Gson, skills visible.

The blind prompt:

Enable R8 for the release build of this app and make it production-ready. Done means the release build works on my Pixel 7, which is connected over USB. Don’t change anything unrelated to R8.

Run B added one sentence: “The app parses JSON from RemoteTaskSource with Gson, so check everything that relies on reflection."

The sentence I care about most is the one in the middle. “Production-ready” is the “let’s circle back” of prompts: everybody nods, nobody can verify it. “Done means the release build works on my Pixel 7” is something a device can prove. If the agent’s idea of done is a green build, R8 will happily let it ship the crash we just saw.

What each run did

The good news first, because it’s genuinely good. All three runs found the Gson problem on their own, even the blind ones. All three wrote rules for those two classes only, instead of keeping the whole package. All three installed the release build on the phone and ran the sync, the code path that crashed.

And two of them noticed that the release build was still signed with the debug key, flagged it as something Play would need fixed, and left it alone because it wasn’t R8.

For reference, the release build before R8 had 23.14 MB of uncompressed DEX and about 1 % obfuscation. Both rows come from android analyze, whose obfuscation figure is a heuristic. Run B also ran R8's Configuration Analyzer, which scores things its own way: 98.77 % optimization, 99.22 % obfuscation and 99.16 % shrinking.

What differed between runs

Run A used the older DSL. It works, the same way a flip phone still makes calls, but it suggests the agent was working from general knowledge rather than the current docs.

Run A’, with the skills visible, learned the AGP 9.3 DSL from the references inside r8-analyzer, then decided not to run the analyzer itself: it reasoned that the skill audits existing rules and the job was to enable R8.

Run B, the one with context, did the most complete job: it used the annotation the Gson docs recommend, ran the full analyzer, and even installed a debug build over the release one to read the synced rows straight from the database before reinstalling the release build.

On paper, three successes. So let’s do the part this series is named after.

What I checked, and what I found

None of the three saw the crash

Every run read the code, spotted Gson and wrote the rule before its first R8 build. They were right. But they were right by inference, and one of them said so with more honesty than most humans manage:

“That the rule was needed is an inference, not something I saw.”

Here’s the twist I promised. The Confluence page was a failure nobody re-tested. These runs produced a fix nobody saw fail. One belief keeps R8 off; the other declares it done. Neither is evidence.

Confident claims that weren't true

When I asked each run to walk me through what it did, the corrections started:

• Run A’ reported that the sync added 12 tasks. The JSON has 20, and the app said 20. The 12 came from a head -12 it had used to print some titles, and that's how head -12 gets promoted to a fact. It also admitted it never saw the "synced" message itself; it only checked that one category count went up by four.
• Run B reported that it had opened a task detail screen with no crashes. When asked, it said it couldn’t back that up: the tap may not have opened anything.
• Run B also left this comment in proguard-rules.pro, stated as fact: without a rule keeping the constructors, "R8 full mode treats them as never instantiated and strips the field reads." It never tested that. We did: same configuration, rule removed, built and installed on the Pixel 7. Sync worked, and when we read the database afterwards every synced title, note and category was intact. The comment was wrong for this setup, and it would have lived in the repo as documentation.

None of these are dramatic. That’s the point. They are the small, plausible, unchecked sentences that end up in a pull request description, and later in somebody’s Confluence page.

Skills used as documentation, not tools

Run A never saw the skills. Run A’ read them and skipped the parts that measure. Only run B ran the analyzer, and only after it had already decided on its rules. Having a tool in the repo doesn’t mean the agent will use it to check its own work.

Driving the phone

This is where things got entertaining. Later’s sync button has no contentDescription, so it doesn't show up in a UI dump in any useful way. Every run ended up tapping raw screen coordinates for at least part of the app.

Run A', in a hurry, fired a burst of taps with no waits; a BACK press took it out of the app, the remaining taps landed on the launcher and opened Google's voice search, and it force-stopped the Google app to recover. Nobody asked it to touch the Google app. 🙃 (That missing contentDescription was planted for the accessibility episode. It showed up early.)

Which keep rule is right

All three configurations work on Later, and the one I kept as ep1-after goes one step further than any of them: optimization { enable = true }, @SerializedName on every field, a default value on every constructor parameter, and no hand-written rule at all.

Why the default values

Run B’s instinct was right: these classes need a constructor. It just kept the wrong one. Gson creates objects through a no-args constructor, and these data classes didn’t have one.

Without it, Gson falls back to Unsafe, which allocates the object without running any constructor, so Kotlin default values and init blocks never run. On Later every field still arrived intact, but that's a fallback, not a design. The Gson troubleshooting guide asks for exactly this: a no-args constructor that R8 keeps.

Give every parameter a default and Kotlin generates that constructor; Gson's bundled rules (Gson 2.11 and later) keep it, together with the fields annotated with @SerializedName. We checked the mapping file and the device: the no-args constructor survived, and the sync works. That last change was a human one.

I’d ship that version, and in a code review I’d ask for it. Not for the few kilobytes. A -keep class rule names the class by its full path, so the day someone moves that model to another package, the rule stops applying. The build won't complain; only R8's Configuration Analyzer lists it as an unused rule, if anyone reads the report. Until then, the crash is back, only in release. The annotation and the defaults travel with the code.

Why this result doesn't generalize

Why did reading the code work so well here? Because in Later, all the reflection lives in our own code. Grep for Gson, find two classes, done. Real apps are rarely this polite.

On a project I’m working on right now, R8 has to be enabled again. A previous attempt failed, nobody recorded what happened, and the trouble apparently came from third-party libraries, not from the build. That’s the harder case: the reflection hides in dependencies nobody reads, so an agent that infers from your code will find nothing to infer. Only running the release build and watching it fail will tell you. It’s also the Confluence story again, minus the Confluence page.

The longer-term answer

Straight from the source: Gson’s own README says it “is not a recommended library for interacting with JSON on Android.” Libraries that generate code instead of using reflection, like kotlinx.serialization or Moshi with codegen, avoid this whole category of R8 surprises. That’s a migration, not “turn on R8”, so none of the runs did it, correctly.

The rule to take away

If I could add one paragraph to that old Confluence page, it would be the same one I now add to the prompt. Three lines that would have saved that team a year of isMinifyEnabled = false:

1. Make it fail first. Build the release without new rules, reproduce the crash, then fix it. A rule that nobody saw fail is a guess, even when it’s a good guess.
2. Separate what you verified from what you inferred. Ask the agent to label both in its summary, and treat any sentence without evidence as a TODO, not a fact. That includes comments it writes in your code.
3. Define done as something a device can prove. “Works on my Pixel 7” gave every run the right target. “Production-ready” alone would have been satisfied by a green build.

The verdict for this episode

Wrapping up

The agent did the chore, and did it well: a release build a fraction of the size, narrow rules, no package-wide keeps, and good instincts about what was out of scope. What it couldn’t give me, until I asked, was evidence. The real test is a codebase like the one I described, where the reflection belongs to someone else’s library.

If you want to try this yourself, the repo is at github.com/euri16/later. Check out the ep1/setup branch (the starting point plus both skills), give your agent the same prompt, and compare its result with the ep1-after tag. Next episode, with R8 finally on, we profile Later's jank, because performance numbers on an unminified build don't mean much.

Thanks for reading! 🙌 What’s the weirdest crash you’ve only ever seen in a release build? Tell me in the comments. Bonus points if it was documented somewhere nobody reads.

AI by lazy: R8 Shrinking and Obfuscation Handled by Your Agent was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Compose Multiplatform lets Android developers reuse Kotlin and Compose screen code on iOS. You keep the language and the UI toolkit you already know, and the same screens run on an iPhone.

But a screen that runs on iOS does not automatically follow iOS. You can build the whole app in Compose, including the tab bar and navigation, and Compose Multiplatform supports the back gesture and iOS-style transitions. What it cannot do is redraw your own tab bar when Apple redesigns the system one. A Compose copy of a system control stays the way you drew it.

I faced this choice while building ClariMeal, a calorie tracker for iOS and Android. I wanted the product screens shared, and I wanted the navigation and system controls to come from iOS itself. The reason was maintenance. Liquid Glass in iOS 26 is a system material, and Compose cannot draw it. On Android, ClariMeal has its own glass tab bar built in Compose, and it looks good there. On iOS it would still be an imitation: it looks different and does not behave like the system bar. Only the system bar follows iOS when Apple changes it.

That did not require a SwiftUI rewrite. Screen content stayed in Compose and the logic stayed in Kotlin, while native iOS components took over navigation and system interactions. This article explains which parts of your iOS app are better left to the system when you want them to follow iOS, where I drew that boundary, and what it still cost.

1. The tab bar belongs to the operating system

Start with one comparison: the same tab bar on Android, iOS 18 and iOS 26.

On Android, Compose draws the whole bar, including the + button in the middle. On iOS, the tab bar comes from UIKit, and the + button shows where the line between the system and the app runs.

The app supports iOS 17 and later. Before iOS 26, the + button is a circle in the middle of the system tab bar, and that circle is my code. On iOS 26, I repurpose UISearchTab for Add. The app replaces its search icon with a plus and intercepts taps to open the Add flow without selecting the tab. UIKit renders the detached circle at the trailing edge of the tab bar.

These excerpts omit the setup of the navigation tabs and the placeholder controller:

if #available(iOS 26.0, *) {
    let addTab = UISearchTab { _ in UIViewController() }
    addTab.automaticallyActivatesSearch = false
    addTab.image = UIImage(systemName: "plus")
    addTab.title = runtime.addControlTitle()
    uiTabs.append(addTab)
    tabs = uiTabs
} else {
    // iOS 17-25: a placeholder item in the middle,
    // and we draw the circle ourselves
    controllers.insert(placeholder, at: Self.centerAddIndex)
    viewControllers = controllers
}

The slot is never selected as a destination. The tab bar delegate turns the tap into the Add flow:

@available(iOS 18.0, *)
func tabBarController(
    _ tabBarController: UITabBarController,
    shouldSelectTab tab: UITab
) -> Bool {
    if tab is UISearchTab {
        runtime.presentAddFlow()
        return false
    }
    return true
}

That is the whole button on iOS 26. None of this code draws it: UIKit places the circle at the edge of the tab bar, adds the glass and sets the shape. My code only tells UIKit that this tab is Add and what a tap should do.

Apple explains that UIKit apps adopt the new appearance when they are rebuilt with the iOS 26 SDK. Native controls remove the need to reproduce that appearance yourself. They do not remove SDK updates, integration work or testing.

The same rule applies to the navigation bar, swipe back and sheet presentation. On iOS 26, the app also uses the system scroll edge effect under the navigation bar instead of drawing its own blur. These are the parts of the interface where iOS should decide how iOS behaves.

2. The calorie card belongs to the product

This is the card at the top of the Today screen. It shows the calories left for the day, a ring and three bars for protein, carbs and fat.

The number, the ring, the colors of the macros and the spacing between them are product decisions. On Android, the same Compose code draws this card. There is no reason to redesign it because Apple redraws a tab bar.

The content of the Today, Progress and Summary screens stays in Compose. Food cards, insight cards, charts, macro rows and scan results share one implementation as well. The business logic, the Room KMP database and the insight engine also stay in Kotlin.

Android is a different case. There, Compose is the platform’s own UI toolkit, so the screens, the navigation and the bottom bar all use Compose. On iOS, the system controls come from UIKit, and that is where the boundary matters.

For me, iOS-first describes the experience. It does not require every screen to be written in SwiftUI.

3. Native navigation can host shared screens

The main tab interface uses ShellCoordinator, a Swift UITabBarController subclass. It contains four navigation tabs, each with its own UINavigationController, plus a separate Add action.

Each screen in those stacks is a UIViewController that hosts one Compose screen through ComposeUIViewController. When Compose sends a navigation event, the native side pushes the next controller.

Shared navigation wrappers use AppNavigator for push and pop. Here are three methods from that interface:

interface AppNavigator {
    fun push(dest: NavDest, singleTop: Boolean = false)
    fun pop()
    fun popTo(dest: NavDest, inclusive: Boolean = false)
}

Each platform implements it with its own stack. On Android, Compose Navigation owns it. On iOS, a UINavigationController does. These method excerpts show how the two implementations change their stacks:

// Inside NavHostNavigator (Android)
override fun push(dest: NavDest, singleTop: Boolean) {
    navController.navigate(dest) { launchSingleTop = singleTop }
}

// Inside ShellNavigator (iOS)
private fun pushNew(dest: NavDest) {
    val nav = nav ?: return
    if (!buildAllowed(nav)) return
    nav.pushViewController(makeHosted(dest), animated = true)
}

makeHosted wraps the same Compose screen that Android shows into a ComposeUIViewController. Callers use AppNavigator without choosing a platform stack.

This makes the ownership clear. Compose renders the content of the destination. UIKit owns the stack, the navigation bar and the back gesture.

In this app, UIKit owns every destination stack, onboarding included. For destinations owned by UIKit, avoid keeping a second back stack in Compose. Send navigation requests to the native layer and let it own push and pop. Otherwise the two layers can disagree about which screen is open.

Swift hosts the containers and coordinates presentation and dismissal. The Add search flow uses another UITabBarController, created in Kotlin and presented in a sheet. Native UI does not require every controller to be created in Swift.

Food search uses UISearchController. Birthday input uses UIDatePicker and UIPickerView. Other screens use UISlider, UISegmentedControl, UIAlertController and UISheetPresentationController.

JetBrains shows this approach in a tutorial that moves navigation to SwiftUI’s TabView and NavigationStack while Compose keeps rendering screen content. My implementation uses UIKit for the same split. It is one available approach, not a requirement of Compose Multiplatform. The UIKit integration documentation also shows Compose content inside a UITabBarController with UINavigationController wrappers.

4. A copied system detail is still your code

Some Compose details deliberately match iOS. Row heights, separators, margins and the card radius were measured from iOS 26 system screens such as Settings and Health. The sampled cards had a 26 pt corner radius. These measurements became design tokens in the Compose theme.

A token makes a value easy to change. It does not make it native. Apple cannot update a number stored in your Compose theme.

The calorie card combines product-specific content and layout with these shared tokens, including the radius copied from iOS. Its implementation stays shared, but the copied details remain my responsibility. When iOS changes the details I chose to match, I review those tokens: some need updating, others can stay as part of the product’s design.

This is where I draw the boundary. The system renders the controls whose look and behavior it should own. Shared components carry the product design. Any system detail copied into them stays your responsibility.

5. A full SwiftUI rewrite would move the boundary too far

For this product, rewriting the screen content in SwiftUI would mean building each screen twice. A change to the calorie card or a chart would then need the same change on Android and on iOS.

I did not see enough value in that. Native navigation and controls cover the platform interactions I wanted iOS to own, and Compose keeps the product content shared. The business logic would stay in Kotlin either way.

What to remember

• Let native iOS containers own the navigation you want iOS to define.
• Keep product screen content shared when it serves both platforms.
• Send navigation events from Compose to the native stack.
• Treat copied system measurements as design tokens that you re-check with each SDK.

The rule I use: share the product. Don’t share the operating system.

You can see this setup in ClariMeal.

If this helped you decide where to separate shared and native UI, a clap helps other developers find the article.

You might also like:

• Kotlin Coroutines: The real difference between Job.cancel() and Scope.cancel()
• When Kotlin object Stops Being a Singleton
• 5 Jetpack Compose Tricks That Saved Me Hours in Real Projects

Anatolii Frolov
Senior Android Developer
Writing honest, real-world Kotlin & Jetpack Compose insights.
📬 Follow me on Medium

Compose Multiplatform: Why You Shouldn’t Build Your Whole iOS App in Compose was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Overview

Attending the Google Android Dev Summit in Mountain View was an exciting experience given it was my first time attending an official event at Google HQ. Compared to massive, spectacle-rich conferences like Google I/O, and Cloud Next, the scale here was noticeably more intimate, allowing direct technical conversations with Google’s core platform team and offering unique insight into shifting engineering priorities at Google — more on that to come.

The primary focus centered on enabling agentic coding paradigms, by introducing BYO model capabilities in Android Studio, and expanding command-line tooling via the Android CLI, while also enabling richer and more performant user interfaces with Compose/A2UI improvements.

Being there in person was insightful as it provided additional context on upcoming architectural and cultural shifts in the Android ecosystem, revealed by what was said, but more importantly, by what was left unsaid. This was particularly evident with Android Studio: while it received a minor update, it clearly took a back seat to the Android CLI updates and seems to be falling out of favor with Google as the preferred developer experience.

Android CLI & Agentic Workflows

The introduction of extended command-line interface (CLI) support for Android represents a major cultural shift towards agentic automation. Built specifically to improve execution performance and minimise context token usage, Android CLI allows autonomous AI agents to execute code development, build tasks, run tests, and confirm they have satisfied the requirements in a verification loop, with the simplicity and performance of the terminal.

A key insight emphasised during the sessions was the importance of hand-crafting your repository’s agents.md files rather than delegating them entirely to AI generation, ensuring strict project standards and precise instruction guardrails. By hand-writing the documentation, AI agents are more likely to follow it as expected. This was particularly interesting to me, as it highlights the inherent risk of relying on AI to define the rules while also being the one to execute the task.

Full video from Ben & Steven: Agentic Engineering with Android CLI

Agentic development often struggles when agents require human intervention for constant, trivial choices. Too often, I’ve set an agent to a task, stepped away, and returned 15 minutes later only to find zero progress because it stalled on a basic naming decision. A proven alternative in the agentic SDLC is the ‘grill me’ approach: where you prompt the AI to ask all clarifying questions upfront, then execute the task autonomously. Paired with self-verification loops, this eliminates constant hand-holding and enables material productivity gains.

Another insight was that agents are often far too confident in their own abilities and finish a task thinking it is complete when it’s really not. Just think how many times have you received an answer from an AI, asked it to double-check its work, only to watch it immediately backpedal.

From Google’s experience, asking the agent to verify and show you the requirements are met, materially increases the reliability of the outcome. This inherently increases the runtime demanded given the longer verification loop, but generally provides better overall results as there’s less re-work required.

To summarise, by resolving any ambiguities early on in the SDLC workflow, it allows us, as experienced engineers, to focus on other, more nuanced items while the agent is running in the background doing what it does best. This is where we can add real value as humans and provide a differentiating factor to agents.

To explore these developments further, check out the official presentation and developer documentation:

Full Presentation: Agentic Engineering & Android CLI

Developer Guide: Android CLI Tooling Documentation

Standardising Best Practices with Android Skills

AI agents often fail to adhere to Modern Android Development (MAD) patterns, frequently generating legacy boilerplate, outdated patterns, or outright hallucinating. This does align with my experience working on both Android and .NET APIs, where agents are generally much better at generating .NET API code over Android code. Though this is not surprising given the Android ecosystem evolves so quickly, models often lack the volume of training data found in more stable environments like .NET.

To solve this, at ADS, Google announced over 30 official Android Skills to set engineering standards for code-generation agents. These skills specifically target:

• New functionality: Defining a knowledge base for recently released features that AI hasn’t been trained on yet.
• Complex implementations: Guiding hardware integrations like advanced camera APIs that are specific to Android.
• High-risk areas: Android Security protocols & Play Store compliance.

These new announcements demonstrate that Google acknowledges the current ecosystem has not been favorable to agentic engineering, and is now providing flexible, AI-friendly standards so developers can adopt what works best for them.

Next-Generation Android Prototype Tooling

Another standout revelation was an upcoming, not-yet-named rework of the Android Emulator that runs completely differently.

Engineered to address performance limitations, this next-generation Android ‘simulator’ (currently just called ‘prototype’) provides faster boot times, significantly lower system resource consumption, and smoother runtime execution compared to traditional Android emulators.

This leap in performance is critical for local agent development loops and high-throughput automated testing runs. And allows agents to verify their work much more efficiently.

Anyone who has been working on Android for some time knows how big a leap this is and it was one of the most talked about changes at the event. Everyone was excited to be able to run and test their apps quickly, especially if you work on enterprise sized apps — this is a game changer.

Hands-On with Android XR & Spatial Computing

Hands-on workshops provided direct real-world time with emerging Android XR devices and spatial app development workflows like the newly announced XREAL Aura.

These workshops demonstrated how the ecosystem separates light, head-mounted glasses from an external computing ‘puck’ that handles primary processing, enabling extended screen mirroring and multi-window productivity layouts.

The current trajectory seems to focus on productivity, resting media consumption, and hands-free utility rather than continuous, all-day wear.

While I did feel a little nauseous wearing them for longer periods (though given the limited headsets available, I had the wrong size for me so that likely contributed), they were impressive in their presentation ability and hand tracking. This made the experience feel quite intuitive and became quite ‘routine’ after only a short amount of time — a good sign new tech will become normalised to people.

It still remains to be seen whether they will get large-scale user adoption, but I can see this generation of AR fulfilling a niche in the market more than the full VR headsets, or the glasses-only options which have significant privacy concerns.

Conclusion & Outlook

The Android Dev Summit made it clear that Android development is rapidly evolving to prioritise AI-driven, agentic development workflows. By extending support for the Android CLI, standardising Android Skills, and experimenting with more efficient virtualisation tools, Google is establishing a decisive lead in modern agent developer enablement.

A2UI is also being enhanced to provide a pattern for dynamic, agentic experiences, right in the palm of your hand. This is where companies will be able to differentiate themselves from their competitors with richer and smoother experiences. More details: Agentic UI with A2UI

For mobile engineers and technical leaders, adopting these tools is no longer optional, but critical for supporting high-performing engineering teams, shipping standout user experiences, and remaining competitive in a rapidly evolving ecosystem.

Android Dev Summit 2026 was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ditch redundant if-else boilerplate and awkward scope chaining with the newly introduced onTrue(), onFalse(), and ifOrNull() functions.

Kotlin has always excelled at eliminating boilerplate. From concise data classes and standard scope functions (apply, also, let, takeIf) to smart casting, the language consistently seeks ways to make everyday idioms more expressive.

Kotlin 2.5.0-Beta2 adds standard library functions that let us inspect a value before returning it, or return a nullable result based on that value.

• Boolean.onTrue(action: () -> Unit): Boolean
• Boolean.onFalse(action: () -> Unit): Boolean
• ifOrNull(condition: Boolean, action: () -> T): T?

Implementation

• Because these functions are introduced as experimental APIs in the standard library, we need to opt in to use them.

1. File/Function Annotation
   OptIn(ExperimentalStdlibApi::class)
2. Module-wide via Gradle config

kotlin {
    sourceSets.all {
        languageSettings.optIn("kotlin.ExperimentalStdlibApi")
    }
}

onTrue() & onFalse()

• Both functions invoke a supplied block when the receiver matches the condition and return the original boolean unmodified.

Example

data class User(val id: String, val email: String)

class AuthService() {

    // Before:
    fun authenticateLegacy(user: User, token: String): Boolean {
        val isValid = verifyToken(user.email, token)
        if (isValid) {
            "Auth.success"
        } else {
            "Auth.failure"
        }
        return isValid
    }

    // Now:
    @OptIn(ExperimentalStdlibApi::class)
    fun authenticate(user: User, token: String): Boolean =
        verifyToken(user.email, token)
            .onTrue { 
                "Auth.success" 
            }
            .onFalse { 
                "Auth.failure"
            }

    
}

ifOrNull()

• When shaping API responses or DTOs, we may return one computed value if a flag is true and another if false. Traditionally, this looks like 👇

val phoneNumber = if (user.hasContactInfo) user.phoneNumber else null

The New Way: ifOrNull()

ifOrNull(condition) { //.. } lazily evaluates the lambda block only if the condition evaluates to true. If false, it returns null immediately.

@OptIn(ExperimentalStdlibApi::class)
val phoneNumber = ifOrNull(user.hasContactInfo) { 
    user.phoneNumber 
}

References

What's new in Kotlin 2.5.0-Beta2 | Kotlin

Clean Up Your Conditional Logic: Exploring Kotlin 2.5.0-Beta2’s New Boolean & Nullable Utilities was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Stop frustrating your IoT users. Build a seamless ESP32 Wi-Fi provisioning flow using Jetpack Compose, Ktor, and MVI Architecture.

The Painless Way to Connect ESP32 Devices to Wi-Fi on Android 📱⚡

How to build seamless IoT provisioning flows using Jetpack Compose, Ktor, and MVI Architecture.

If you’ve ever built an IoT product, you know the biggest hurdle isn’t writing the firmware or building the cloud backend — it’s the onboarding process. Getting a screenless microcontroller (like an ESP32) connected to a user’s home Wi-Fi network is notoriously frustrating.

Users have to leave your app, go to their phone’s Wi-Fi settings, connect to a temporary hotspot, ignore the “Internet may not be available” warnings, go back to the app, enter their credentials, and pray it works.

As Android developers, we can do better.

Today, I am open-sourcing EasyESP Connect — a battle-tested Kotlin Multiplatform (KMM) Library, Android App, and companion ESP32 firmware that makes provisioning ESP32 devices incredibly simple, resilient, and fully automated.

The Android IoT Routing Problem 🚧

Before diving into the solution, let’s talk about why Android makes IoT provisioning so hard.

When your phone connects to an ESP32’s temporary Wi-Fi hotspot, that hotspot doesn’t have internet access. Modern Android versions (Android 9+) are smart — if they detect a Wi-Fi network has no internet, they will silently route all HTTP requests through the user’s Cellular Data instead.

This means when your app tries to send the Wi-Fi password to http://192.168.4.1, the request goes to the cellular tower, times out, and the setup fails.

The Solution: EasyESP Connect ✨

EasyESP Connect solves this (and many other edge cases) by taking full control of the Android Networking stack and providing a beautiful, state-driven Jetpack Compose UI.

Key Features: * Automated Device Discovery: Passively scans for local ESP32 devices broadcasting setup SSIDs using Android’s WifiManager. * Programmatic Hotspot Binding: Uses WifiNetworkSpecifier (Android 10+) to securely connect the phone to the ESP32 without leaving the app, and explicitly binds the app’s process to the Wi-Fi network so HTTP requests don’t leak to cellular data. * Smart Fallbacks: If the OS blocks the automatic connection, it gracefully degrades to a guided manual connection screen. * ESP32 Dual Mode: The firmware runs in WIFI_AP_STA mode, acting as a configuration portal while simultaneously scanning the environment for home routers.

How to use it in your app 🛠️

I built EasyESP Connect to be as flexible as possible. Whether you want a plug-and-play UI or you want to build your own custom screens, integration takes minutes.

Method 1: The Drop-In Compose UI

If you are building a modern Jetpack Compose app, you can drop the pre-built EasyEspSetupUI directly into your screen. It handles permissions, Wi-Fi scanning, Lottie animations, and error states automatically.

import com.easyesp.shared.ui.EasyEspSetupUI
 import com.easyesp.shared.mvi.EasyEspConfig
 
 @Composable
 fun ProvisioningScreen() {
     EasyEspSetupUI(config = EasyEspConfig(scanTimeoutMillis = 60_000L),
                 onSuccess = { 
                    println("ESP Device Provisioned Successfully! 🎉") 
                 },
     onError = { error -> println("Setup Failed: $error") })
 }

Method 2: The Activity Result API

If your app is built with XML Views or Fragments, you can launch the Compose flow using a standard ActivityResultContract and just wait for the callback:

val launcher = registerForActivityResult(EasyEspSetupContract()) { result ->
   result.onSuccess { 
   // Device is connected!
   }.onFailure { error ->
   // Handle failure
   }
 }
 
 // Start Setup Flow
 launcher.launch(EasyEspConfig())

Method 3: Headless MVI (Build Your Own UI)

For developers who want complete control over the pixel-perfect design of their app, EasyESP provides a headless MVI (Model-View-Intent) Session.

You simply send EasyEspIntents to the session and observe the EasyEspState. The library handles all the ugly networking, timeouts, and state transitions in the background.

val session = EasyEsp.createSession(context, coroutineScope, EasyEspConfig())
 
 // 1. Observe State
 lifecycleScope.launch {
   session.state.collect { state -> 
       when(state) {
       is EasyEspState.Discovering -> showCustomRadarAnimation()
       is EasyEspState.EspDevicesFound -> displayDeviceList(state.devices)
       is EasyEspState.Provisioning -> showLoadingSpinner()
       is EasyEspState.Success -> navigateToDashboard()
       // …
       }
   }
 }
 
 // 2. Send Intents to control the flow
 session.sendIntent(EasyEspIntent.CheckPreconditionsAndStart)

The Firmware Side 🔌

3. Flash the Firmware (Arduino Library)

To make your ESP32 compatible, you can use the official EasyEspAndroid Arduino Library.

Search LibraryManager “EasyEspAndroid” and install Simply

or

1. Download this repository as a ZIP file.
2. In Arduino IDE, go to Sketch -> Include Library -> Add .ZIP Library… and select the ZIP.
3. Open Arduino IDE and go to File -> Examples -> EasyEspAndroid -> BasicSetup.
4. Select your ESP32 board and upload at 115200 baud.

Here is how simple your ESP32 code becomes:

#include <EasyEspAndroid.h>

EasyEspAndroid easyEsp;

void setup() {
  Serial.begin(115200);
  easyEsp.onConnected([](String ip) {
    Serial.println("Wi-Fi connected! IP: " + ip);
  });
  easyEsp.begin("EasyEsp-Setup"); // Start the hotspot
}
void loop() {
  easyEsp.loop(); // Handle incoming setup requests from Android
}

Flash this to your ESP32 via the Arduino IDE. It uses a lightweight asynchronous WebServer to expose two endpoints: 1. GET /networks — Returns a JSON array of surrounding Wi-Fi networks and signal strengths (RSSI). 2. POST /credentials — Accepts the target ssid and password from the Android app, drops the temporary hotspot, and connects to the home router.

Because it uses standard HTTP (via Ktor on Android), you can easily extend this to pass user tokens, MQTT broker URLs, or custom sensor data during the setup phase!

Get Started Today 🚀

Building IoT products is hard enough; onboarding shouldn’t be.

You can find the complete source code, the KMM shared library, the Jetpack Compose app, and the ESP32 firmware on GitHub.

🔗 GitHub Repository: codingwitharul/esay-esp 📚 Full Documentation: EasyESP Documentation

If this helps you build your next hardware project, drop a star on the repo! Happy coding! 👨‍💻💡

How to Connect ESP32 to Wi-Fi on Android (The Right Way) | EasyEsp was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.