This source did not publish a separate summary. Review SKILL.md before using the skill.
SKILL.md
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
Best for: Android-only apps, hardware-intensive features, best-in-class UX, new projects.
Never let exceptions propagate to the user silently or crash the app.
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
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
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.
