android-dev

Android App Development Skill

Overview

This skill guides production-grade Android and cross-platform (non-iOS) app development following practices used at big tech companies. It covers the entire development lifecycle — architecture, UI, code quality, testing, error handling, release, and maintenance.

When to Use This Skill

• Use when deciding on a tech stack (see §1 Stack Selection)

• Use when setting up project architecture (see §2 Architecture)

• Use when designing UI, screens, or a design system (see §3 UI & Design)

• Use when ensuring code quality, patterns, or APIs (see Best Practices)

• Use when implementing error handling or debugging crashes (see §5 Error Handling)

• Use when planning testing strategy (see §6 Testing)

• Use when configuring build, CI/CD, or release pipelines (see §7 Build & Release)

• Use when optimizing performance or memory (see §8 Performance)

• Use when debugging or fixing bugs (see §9 Debugging)

• Use when following the full development roadmap (see §10 Development Roadmap)

• Use when needing deep reference for a stack (see references/ directory)

---

§1 Stack Selection

Choose based on team, requirements, and platform targets. Do not recommend iOS-specific paths.

Native Android — Kotlin + Jetpack Compose

• Language: Kotlin

• UI: Jetpack Compose (modern declarative UI)

• Key libs: Room, Retrofit/Ktor, Hilt, WorkManager, DataStore, Navigation Compose

• Reference: references/native-android.md

Native Android — Java + XML Views

• Language: Java (fully supported by Google, not deprecated)

• UI: XML Layouts (ConstraintLayout, RecyclerView, ViewBinding)

• Key libs: Room, Retrofit, Hilt, WorkManager, LiveData, ViewModel

• Java and Kotlin coexist seamlessly in the same project — migrate incrementally

• Reference: references/java-android.md

Flutter (Dart)

• Language: Dart

• UI: Flutter Widget tree (Material 3 / Cupertino widgets available but target Material for Android)

• Key libs: Provider/Riverpod/Bloc, Dio, Drift/Isar, go_router, flutter_local_notifications

• Reference: references/flutter.md

React Native (JavaScript/TypeScript)

• Language: TypeScript (preferred)

• UI: React Native core components + NativeWind / React Native Paper

• Key libs: React Navigation, Zustand/Redux Toolkit, React Query, MMKV

• Reference: references/react-native.md

Kotlin Multiplatform (KMM / Compose Multiplatform)

• Language: Kotlin everywhere

• UI: Native Compose on Android; Compose Multiplatform for shared UI

• Key libs: Ktor, SQLDelight, Koin, kotlinx.serialization, Napier

• Reference: references/kmm.md

Hybrid (Capacitor / Ionic)

• Language: TypeScript + HTML/CSS

• UI: Ionic components or custom web UI

• Avoid for: Heavy animations, native sensor access, high-performance games

• Reference: references/hybrid.md

Decision Matrix

| Requirement | Native Kotlin | Native Java | Flutter | RN | KMM | Hybrid |
|---|---|---|---|---|---|---|
| Android-only (new) | ✅ Best | ✅ | ✅ | ✅ | ✅ | ✅ |
| Android-only (existing Java) | ⚠️ migrate | ✅ Best | ❌ | ❌ | ⚠️ | ❌ |
| Android + Web | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ Best |
| Android + Desktop | ❌ | ❌ | ✅ | ⚠️ | ✅ | ⚠️ |
| Shared business logic only | N/A | N/A | N/A | N/A | ✅ Best | N/A |
| Native performance | ✅ | ✅ | ✅ | ⚠️ | ✅ | ❌ |
| JS/TS team | ❌ | ❌ | ❌ | ✅ Best | ❌ | ✅ |
| Custom pixel-perfect UI | ✅ | ⚠️ | ✅ Best | ⚠️ | ✅ | ❌ |

---

§2 Architecture

Core Principle: Separation of Concerns

Recommended Architecture: Clean Architecture + MVI/MVVM

app/
├── ui/              # Composables / Activities / Fragments / Screen states
├── presentation/    # ViewModels, UI State, UI Events
├── domain/          # Use cases, domain models, repository interfaces
├── data/            # Repository impl, remote (API), local (DB), mappers
└── di/              # Dependency injection modules

Data flow (unidirectional):

User Action → ViewModel/Store → Use Case → Repository → Data Source
                    ↓
             UI State (sealed class / StateFlow)
                    ↓
             Composable / View renders state

Key Architecture Patterns by Stack

Native (MVVM + MVI):

• StateFlow / SharedFlow for reactive state

• sealed class UiState + sealed class UiEvent

• Hilt for DI, coroutines + Flow for async

• Repository pattern wrapping Room + Retrofit

Flutter (BLoC or Riverpod):

• Bloc or Cubit for business logic isolation

• AsyncNotifierProvider (Riverpod) for data + state

• Repositories as abstract classes with impl injected

React Native (Redux Toolkit or Zustand):

• RTK Query or React Query for server state

• Zustand slices for client state

• Custom hooks to encapsulate business logic per feature

KMM:

• Shared commonMain holds domain + data layers

• expect/actual for platform-specific implementations

• Kotlin coroutines + Flow bridged to platform (StateFlow on Android)

Module Structure (Multi-module for large apps)

:app            # Entry point, DI wiring
:core:ui        # Design system, shared composables
:core:network   # API client, interceptors
:core:database  # Room / SQLDelight setup
:feature:home
:feature:profile
:feature:settings

---

§3 UI & Design

Design System First

Jetpack Compose UI Rules

• Use MaterialTheme tokens; never hardcode colors/dimensions

• CompositionLocal for theme, locale, haptics

• remember / rememberSaveable correctly (saveable for UI state surviving rotation)

• Extract large composables into sub-composables; each function ≤ 80 lines

• Use LazyColumn/LazyVerticalGrid for lists; never Column with forEach for large data

• Side effects only in LaunchedEffect, DisposableEffect, SideEffect

• Avoid state hoisting anti-patterns: hoist state to the lowest common ancestor

Accessibility (Non-Negotiable)

• All interactive elements: contentDescription or semantics { }

• Min touch target: 48×48dp

• TalkBack compatibility tested before every release

• Dynamic text size support (sp not dp for text)

• Color contrast ratio ≥ 4.5:1 (WCAG AA)

Navigation

• Native: Navigation Compose with typed NavHost and SafeArgs equivalent

• Flutter: go_router with named routes and guards

• RN: React Navigation v7 with typed NavigationProp

• Deep link handling registered for every screen that can be externally opened

• Back stack managed deliberately — don't push duplicates, use popUpTo / launchSingleTop

Responsive & Adaptive UI

• Support all screen sizes: phones, foldables, tablets (WindowSizeClass)

• Test at 320dp, 360dp, 411dp, 600dp+, 840dp+ widths

• Foldable hinge awareness via WindowInfoTracker

• Edge-to-edge display + WindowInsets handling required for Android 15+

---

Best Practices

Language Standards

Kotlin:

• Prefer data class, sealed class, object, enum class appropriately

• No !! null assertions — use ?.let, ?: return, requireNotNull with message

• Coroutines: always specify CoroutineScope + Dispatcher explicitly; never GlobalScope

• Use @Stable / @Immutable on Compose state classes for smart recomposition

Java:

• @NonNull / @Nullable annotations on every method param and return type

• Never call methods on unchecked objects — null-check explicitly or use Objects.requireNonNull

• Always null binding reference in Fragment's onDestroyView() to prevent memory leaks

• Use ExecutorService (not AsyncTask — deprecated) for background work; or LiveData + Room's built-in threading

• Prefer ListAdapter + DiffUtil over manual notifyDataSetChanged() in RecyclerView

• Use ViewBinding — never findViewById

Dart (Flutter):

• Null safety required — no ! without explicit null check above

• Immutable state objects with copyWith

• const constructors on all stateless widgets

TypeScript (RN):

• strict: true in tsconfig always

• Zod or io-ts for runtime type validation of API responses

• No any — use unknown and narrow

Dependency Management

• Pin all dependency versions in build.gradle.kts / pubspec.yaml / package.json

• Audit dependencies monthly for security vulnerabilities

• Avoid transitive dependency conflicts — use dependency resolution strategies

• Keep dependency count minimal — every added lib is a maintenance burden

Code Review Checklist (PR gate)

• [ ] New public APIs have KDoc / DartDoc / JSDoc

• [ ] No hardcoded strings — use string resources / l10n

• [ ] No hardcoded dimensions or colors outside design tokens

• [ ] No blocking I/O on main thread

• [ ] No memory leaks (no Activity context stored in singletons)

• [ ] Coroutine scopes / streams properly cancelled / disposed

• [ ] Feature flag guarding any non-trivial feature

---

§5 Error Handling

The Golden Rule

Error Classification

| Type | Strategy |
|------|----------|
| Network errors | Retry with exponential backoff; show retry UI |
| Auth errors (401/403) | Refresh token → re-request → logout if fails |
| Validation errors | Show inline field errors immediately |
| Data parsing errors | Log + fallback to cached/default state |
| Unexpected crashes | Catch at top-level; show error screen + report |
| Background task failures | Retry via WorkManager; notify user if critical |

Result / Either Pattern (Kotlin)

sealed class AppResult<out T> {
    data class Success<T>(val data: T) : AppResult<T>()
    data class Error(val exception: AppException) : AppResult<Nothing>()
}
sealed class AppException(msg: String) : Exception(msg) {
    class NetworkException(msg: String) : AppException(msg)
    class AuthException(msg: String) : AppException(msg)
    class ParseException(msg: String) : AppException(msg)
    class UnknownException(msg: String) : AppException(msg)
}

Use AppResult<T> as return type for all repository + use case functions. ViewModels map to UiState.Error.

Crash Reporting

• Integrate Firebase Crashlytics or Sentry from day one

• Set user identifiers and custom keys before crash occurs

• Non-fatal exceptions logged for all caught errors

• ANR monitoring enabled

• Crash-free sessions target: ≥ 99.5%

Offline / Network Resilience

• Cache-first strategy: show stale data, fetch fresh in background

• Room / Drift / MMKV as single source of truth

• Expose network state via ConnectivityManager and reflect in UI

• All network calls wrapped with timeout + retry policy

---

§6 Testing

Testing Pyramid

/\
        /E2E\        ← 10%  (UI tests: Espresso, Maestro, Appium)
       /------\
      / Integr \     ← 20%  (Repository, DB, API contract tests)
     /----------\
    /    Unit    \   ← 70%  (ViewModels, Use Cases, Utilities)
   /--------------\

Unit Tests (70%)

• Every ViewModel, UseCase, Repository, Mapper tested

• Native: JUnit5 + MockK + Turbine (Flow testing) + Kotest assertions

• Flutter: flutter_test + mocktail

• RN: Jest + @testing-library/react-native + msw for API mocking

• Coverage target: ≥ 80% on domain + presentation layers

Integration Tests (20%)

• Room DB tests with in-memory database

• Retrofit/Ktor tests with MockWebServer (OkHttp)

• Repository tests verifying cache + remote coordination

• API contract tests against real staging endpoint

UI / E2E Tests (10%)

• Espresso for critical user journeys (login, checkout, core action)

• Maestro for cross-platform E2E flows (recommended for Flutter + RN too)

• Run on real device farm (Firebase Test Lab / BrowserStack) before release

• Smoke test suite runs on every PR; full E2E suite nightly

Test Data Management

• Use factories / builders for test data, never copy-paste objects

• Hermetic tests: never share mutable state between test cases

• Fakes over mocks for complex dependencies (repositories, data sources)

---

§7 Build & Release

Build Variants

debug       → dev API, logging on, no minification, debuggable
staging     → staging API, logging on, minified, not debuggable
release     → prod API, logging off, minified, signed

Gradle Best Practices (Native)

• build.gradle.kts only — no Groovy DSL in new projects

• Version catalog (libs.versions.toml) for all dependency versions

• buildConfig for environment-specific constants

• Baseline profiles for startup performance

• R8 full mode enabled in release; maintain proguard rules in version control

CI/CD Pipeline

PR Opened
  └─ lint + unit tests + build debug APK          [< 5 min]
Merge to main
  └─ unit + integration tests + staging build     [< 15 min]
  └─ deploy to Firebase App Distribution (QA)
Release tag
  └─ full test suite + E2E on device farm         [< 45 min]
  └─ build release AAB
  └─ upload to Play Console (internal track)
  └─ promote: internal → closed testing → open → production

Recommended CI: GitHub Actions, Bitrise, or CircleCI.

Play Store Release Strategy

• Always release to internal → closed → open testing before production

• Use staged rollouts: 5% → 20% → 50% → 100% with 24-48h monitoring

• Monitor Crashlytics + ANR rate + rating before expanding rollout

• Never skip staged rollout for significant changes

App Signing

• Upload key (Play App Signing): stored in CI secrets, never committed

• Use Google Play App Signing for distribution key management

• Document key recovery procedure in team runbook

---

§8 Performance

Startup Performance

• App startup time target: cold start < 1s, warm start < 500ms

• Use App Startup library for initializing libraries lazily

• Baseline profiles generated + committed to repo

• Heavy initialization moved off main thread

UI Performance

• Target: 60fps (90/120fps on supported devices); zero jank

• Measure with Android Studio Profiler + FrameMetrics API

• Avoid allocation in draw() / onMeasure() / composition

• Use derivedStateOf in Compose to avoid unnecessary recompositions

• Image loading: Coil (Compose) / Glide / Picasso — never load full-res in thumbnails

Memory

• No Activity / Context references in ViewModels or singletons

• WeakReferences for listeners stored beyond their owner's lifecycle

• Bitmap recycling and memory cache sizing

• Heap dump + leak detection via LeakCanary in debug builds (always)

Network

• HTTP caching headers respected

• Image CDN + WebP format

• Gzip/Brotli compression verified

• Request batching where applicable

• Connection pooling configured

Battery

• Background work only via WorkManager with appropriate constraints

• Location updates: request only needed accuracy level; stop when backgrounded

• Wakelocks used sparingly with explicit release

---

§9 Debugging & Bug Fixing

Debugging Process

1. Reproduce reliably — document exact steps, device, OS version, account state
2. Isolate — is it UI, business logic, network, or persistence?
3. Instrument — add targeted logs / breakpoints, NOT shotgun logging
4. Hypothesize — form 1-3 specific hypotheses before touching code
5. Fix the root cause — never patch symptoms; trace back to the source
6. Regression test — write a test that fails before fix, passes after
7. Document — comment explaining why the fix works, not just what it does

Common Android Bug Patterns

| Bug | Likely Cause | Fix |
|-----|-------------|-----|
| ANR | Main thread I/O / long computation | Move to coroutine/Dispatcher.IO |
| Memory leak | Context stored in singleton | Use applicationContext; WeakRef |
| Crash on rotation | ViewModel not used; state not saved | rememberSaveable / ViewModel |
| UI lag | Recomposition loops | derivedStateOf, stable params |
| Blank screen after API call | Error swallowed silently | Check error state propagation |
| Deep link not working | Manifest intent-filter missing | Verify adb shell am start test |
| Push notification silent | Background restrictions | Test on real devices across OEMs |

Logging Standards

• Production: Firebase Crashlytics only (no Log.d in release builds)

• Debug/Staging: Timber with debug tree

• Log levels: ERROR (crashes), WARN (recoverable), INFO (key events), DEBUG (dev only)

• Never log PII — mask emails, phone numbers, tokens in logs

OEM-Specific Issues

• Test on Samsung, Xiaomi/MIUI, OnePlus/OxygenOS, Huawei (no GMS) for critical flows

• Background restrictions vary widely by OEM — test push, alarms, background sync

• Maintain a physical or cloud device farm with top market-share devices

---

§10 Development Roadmap

Follow this phase structure for any new Android project:

Phase 0 — Foundation (Week 1-2)

• [ ] Stack decision documented with rationale

• [ ] Module structure defined

• [ ] Design system tokens defined (colors, type, spacing, shapes)

• [ ] CI pipeline running (lint + unit tests + build)

• [ ] Crash reporting integrated (Crashlytics/Sentry)

• [ ] Analytics baseline integrated (Firebase/Amplitude)

• [ ] API contract / mock server set up

• [ ] DI framework configured

• [ ] Navigation skeleton implemented

• [ ] Flavor/build variant config complete

Phase 1 — Core Features (Weeks 3-8)

• [ ] Auth flow (login, register, token refresh, logout)

• [ ] Core screen shells with real navigation

• [ ] Network layer (client, interceptors, error handling)

• [ ] Local persistence layer (DB schema + DAOs)

• [ ] Repository layer wiring remote + local

• [ ] ViewModels + UI states for each feature

• [ ] Unit tests for all ViewModels + use cases

• [ ] Feature flags infrastructure

Phase 2 — Polish (Weeks 9-12)

• [ ] Design QA pass against Figma/spec

• [ ] Accessibility audit (TalkBack, contrast, touch targets)

• [ ] Dark mode implementation + verification

• [ ] Localization (strings externalized, RTL support if needed)

• [ ] Loading, empty, error states on every screen

• [ ] Deep link handling

• [ ] Widget / notification implementation

• [ ] Offline mode verification

Phase 3 — Hardening (Weeks 12-14)

• [ ] Performance profiling (startup, scroll, memory)

• [ ] E2E test suite on device farm (Firebase Test Lab)

• [ ] Security review (certificate pinning, biometrics, secure storage)

• [ ] Proguard / R8 rules verified

• [ ] Crash-free rate ≥ 99.5% on staging

• [ ] Play Store listing, screenshots, privacy policy

Phase 4 — Release

• [ ] AAB signed and uploaded to internal track

• [ ] Staged rollout plan defined

• [ ] Monitoring dashboard set up (Crashlytics, Play Console vitals)

• [ ] Rollback plan documented

• [ ] On-call rotation assigned

Phase 5 — Post-Launch (Ongoing)

• Crash-free rate monitored daily

• ANR rate < 0.47% (Play Store threshold)

• App rating monitored; negative reviews triaged weekly

• Dependency updates reviewed monthly

• OS beta testing with each new Android release

---

Limitations

• This skill is scoped to Android and Android-adjacent delivery paths; it does not cover iOS-only architecture, App Store release operations, or Apple platform UI guidance.

• Version numbers, Play Console policy thresholds, and recommended libraries can change; verify release-critical details against current Android, Google Play, and library documentation before shipping.

• Code snippets are architecture patterns, not complete applications; adapt package names, dependency versions, permissions, privacy disclosures, and security controls to the actual project.

• The guidance does not replace device QA, accessibility review, security review, legal/privacy review, or store compliance checks for a production release.

Additional Resources

For stack-specific deep dives, read:

• references/native-android.md — Kotlin, Compose, Room, Hilt, Coroutines

• references/java-android.md — Java, XML Views, ViewBinding, LiveData, Retrofit, Room, Hilt, migration path

• references/flutter.md — Dart, BLoC/Riverpod, Drift, go_router

• references/react-native.md — TypeScript, RN architecture, Hermes, New Architecture

• references/kmm.md — KMM shared modules, SQLDelight, Ktor, Compose Multiplatform

• references/hybrid.md — Capacitor, Ionic, PWA considerations