Android Native UI

Build and review Android interfaces around platform contracts: Compose semantics, lifecycle-aware state, adaptive windows, Material/system integration, back navigation, and accessibility—not web ARIA or pixel-only parity.

Identify the UI boundary

Map Android Views versus Compose, Material 3/custom design system, minimum SDK, navigation library, state holder, and whether the project is Android-only or Compose Multiplatform.

For Compose Multiplatform, keep portable UI in commonMain; isolate Android APIs such as Context, permissions, back handling, and window APIs at the platform boundary. Verify each shipped target independently.

Fresh platform guidance

Before prescribing or implementing APIs, behaviour, Material conventions, tooling, or verification that may vary by Android/Compose/Kotlin release, search current primary Android sources: developer.android.com, AndroidX release notes, and Kotlin documentation where relevant. Check the project's SDK, Compose BOM/library versions, and shipped Compose Multiplatform targets before recommending an API. The examples here express durable contracts; they are not a substitute for release-specific documentation.

State, effects, and component APIs

Hoist state only as high as the caller that needs to control it. Model durable screen state separately from one-shot events. Collect flows with lifecycle awareness on Android, and use LaunchedEffect, DisposableEffect, or other explicit effects for imperative work—not a composable body.