Android

The Android slop test

Would a fluent Android user trust this app, or trip on off-spec components? The most common tell is an iOS app wearing Android’s skin: a bottom-only navigation copied from iPhone, a back arrow that ignores the system Back gesture, Cupertino-shaped switches and dialogs. Material 3 is the rulebook; follow its components and theme the brand through it.

Layout & structure

• Material navigation, matched to size. Navigation bar (bottom, 3–5 destinations) on compact width; navigation rail or drawer on expanded width. Never ship a phone bottom-bar untouched on a tablet.
• System Back always works. Honor the predictive Back gesture and Back button; never trap the user or hijack the gesture.
• Edge-to-edge with window insets. Apply the status bar, navigation bar, display cutout, and IME insets so content never hides behind system bars or the keyboard.
• Top app bar for screen context; pair with a FAB when the screen has a single primary action.

Touch targets

• 48×48 dp minimum for every touch target, with at least 8 dp between them.

Typography

• Material type scale. Display, Headline, Title, Body, Label roles (large/medium/small each). Map text to roles; never hand-pick sizes per screen.
• Roboto is the system face; theme a brand face in through the type scale, keeping body, labels, and controls legible and consistent.
• sp units, never fixed px, so type follows the system font-size setting.

Color & theming

• Material color roles (primary, on-primary, surface, surface-variant, secondary-container, outline, error). Role tokens resolve light/dark and contrast variants automatically; raw hex breaks there.
• Dynamic Color (Material You) where it fits: derive the scheme from the user’s wallpaper on Android 12+, with a static fallback.
• Dark theme is a first-class scheme. Design and test it; never a quick invert.
• Tonal elevation. Convey elevation through the standard surface tonal levels (plus shadow where appropriate); no arbitrary drop shadows.

Components & motion

• Material components. Buttons (filled / tonal / outlined / text), FAB, switches, chips, snackbars, bottom sheets, Material dialogs, navigation bar/rail/drawer. Never port iOS controls or invent equivalents.
• One FAB, one primary action. Never stack FABs or spend one on a secondary task.
• Snackbars for transient feedback (actionable when useful, never a toast for that); dialogs only for decisions that must interrupt.
• Material motion patterns. Container transform, shared-axis, fade-through, with standard easing and durations; honor the system Remove animations setting with a crossfade or instant cut.

Verifying the build

• Screenshots come from the emulator or a connected device, never a browser. Build and install, then capture with adb exec-out screencap -p > <path> (pick a device with adb -s <serial> when several are attached). Capture every device class the app ships to, at least one phone and, when tablets are a target, one tablet, and write the files where the review flow expects them.
• Dark theme and font scale belong in the pass. adb shell cmd uimode night yes flips the theme; adb shell settings put system font_scale 1.3 (restore 1.0 after) catches the clipped labels a fixed layout hides; with several targets attached, the capture’s -s <serial> goes on these commands too.
• Emulators give breadth; gestures, refresh rates, and performance need hardware. Say which one produced the evidence.