Android

The three Android modules: Compose animation foundations, advanced graphics with AGSL and Material 3 Expressive, and Compose Multiplatform patterns.

Detected from your Gradle files. Compose alone loads two modules; Compose plus the Kotlin Multiplatform plugin loads three.

compose-motion

Loads whenever Compose is detected.

An API decision tree first, then the spring API with opinionated defaults, because picking stiffness and damping ratio by feel is how a project ends up with eleven different springs. Then the working set: animate*AsState for the common case, AnimatedVisibility for mount and unmount, AnimatedContent for state-driven layout swaps, Crossfade for simple fades, updateTransition for coordinating several properties off one state, Animatable for manual control, SharedTransitionLayout from Compose 1.7 for hero animations, and InfiniteTransition for loops. Plus a quick map of the gesture modifiers.

The anti-patterns come in wrong-then-right pairs, and the one that matters most is size animation: animateDpAsState on a height triggers a full layout pass every frame, where Modifier.graphicsLayer { translationY = ... } does not.

Reduced motion on Android has no first-class API, so the module carries a helper built on Settings.Global.ANIMATOR_DURATION_SCALE, and the audit treats its absence in an animated project as critical.

The stack-specific audit: recomposition counts through the Layout Inspector or Modifier.recomposeHighlighter, frame timing through Macrobenchmark on a mid-range baseline device (targeting under 16.67ms at 60fps, under 8.33ms at 120fps), Modifier.semantics on custom interactive components for TalkBack, and baseline profiles for production builds.

compose-graphics

Loads when the scope is full or the thesis is advanced. Three domains.

Material 3 Expressive, including its motion physics and MotionScheme, which is the right register for hero and high-impact surfaces rather than for everything.

AGSL runtime shaders on Android 13 and up, which always means a static fallback below that version rather than a broken surface.

Canvas and DrawScope for generative work, plus graphicsLayer effects.

compose-multiplatform

Loads when the Kotlin Multiplatform and JetBrains Compose plugins are both present.

It starts by separating KMP from CMP, because conflating them is the source of most confusion in this space. Then project structure, the expect/actual pattern including its composable form, LocalDensity across platforms, LocalConfiguration and platform-aware UI, fonts through Compose Resources, and interop in both directions: SwiftUI inside Compose on iOS, and Compose inside a SwiftUI or UIKit view.

It ends with what does not work, which in a multiplatform target is the section that saves the most time.

Legacy projects

If the scan finds XML layouts, classic Activities or setContentView(R.layout.*) alongside Compose, exactly one question is asked: stay in pure Compose, or integrate into a legacy screen?

Choosing integration produces an AndroidView bridge that exposes the modern code inside the legacy screen. New legacy code is never generated: no layout XML, no setContentView.