android

Android engineering rules — permissions, release signing, Kotlin/Compose. Load for Android.

SKILL.md

GitHub

Scope

This skill is the engineering half of Android support: platform rules that apply to any Android task — permissions, release signing, distribution, and native code standards.

The design half lives in skills/mobile/material-design/SKILL.md (color system, typography scale, components, motion, adaptive layout, accessibility). Load it only when the task touches UI — screen layout, navigation, visual or interaction design. A signing, build, or non-UI logic task does not need it.

Design & UX (non-negotiable, applies even to non-UI tasks)

  • Support edge-to-edge layout — use WindowInsets to avoid overlap with system bars
  • Use adaptive icons (mipmap-anydpi-v26/) — required for Android 8.0+
  • Support back gesture (predictive back on Android 14+) — register OnBackPressedCallback instead of overriding onBackPressed()
  • Test on both small screens (< 5") and large screens / foldables

Permissions & Privacy

  • Declare only the permissions you actually use in AndroidManifest.xml
  • Request runtime permissions with ActivityResultContracts.RequestPermission
  • Handle shouldShowRequestPermissionRationale() — show an explanation before re-requesting
  • Target the latest stable targetSdkVersion required by Google Play
  • Fill the Data Safety section in Play Console accurately — it is legally binding

Code Signing & Release

  • The upload keystore must be stored securely (EAS Credentials, 1Password, or CI secret store) — never commit it to the repository
  • Use Android App Bundle (AAB) for Play Store submissions — not APK
  • Enable R8/ProGuard for release builds; test the release build locally before submitting to catch missing keep rules
  • versionCode must be monotonically increasing — Play Store rejects builds with the same or lower version code

Native Kotlin / Jetpack Compose Standards

  • Prefer Jetpack Compose for new screens; use Views/XML only when Compose cannot achieve the required behavior or when maintaining existing View-based code
  • Use ViewModel + StateFlow/SharedFlow for UI state — never hold state in Activities or Fragments
  • Use Room for local persistence; DataStore for preferences (not SharedPreferences for new code)
  • suspend functions and Flow over callbacks for all new async code
  • Never run network or database operations on the main thread