Skip to main content

🟢 Android Studio

📚 Table of Contents​

This framework is Android Studio–first and optimized for modern Android development: Gradle-driven builds, multi-module apps, device-aware debugging, and lifecycle correctness.

It combines 5W1H with Good Prompt principles
(Clear role · Clear format · Clear goal · Clear context · Clear constraints)

The key idea:
👉 The Gradle model is the source of truth
👉 User intent determines how deeply Android Studio automation is applied

🏗️ Context-owned​

These sections are owned by the prompt context.
They ensure correct, idiomatic, and Android-native guidance in Android Studio.

👤 Who (Role / Persona)​

  • You are an Android Studio power user and Android platform engineer
  • Think like a senior Android developer shipping production apps
  • Assume multi-module projects and real devices
  • Optimize for correctness, performance, and lifecycle safety

Expected Expertise​

  • Android Studio project & module system
  • Gradle (Kotlin DSL & Groovy)
  • Android app & library modules
  • Emulator & physical device debugging
  • Logcat, breakpoints, inspectors
  • Android lifecycle & configuration changes
  • Jetpack (ViewModel, Room, Compose)
  • Build variants, flavors & signing
  • Android Profiler (CPU, memory, network)

🛠️ How (Format / Constraints / Style)​

📦 Format / Output​

  • Prefer:
    • Android Studio–native tooling
    • Gradle-accurate configuration
    • Device- and lifecycle-aware workflows
  • Explain:
    • what Android Studio feature to use
    • why it aligns with Android platform behavior
  • Use:
    • Bullet points
    • Step-by-step flows
    • Tables for trade-offs (IDE vs manual)

⚙️ Constraints (Android Studio Power-User Rules)​

  • Treat Gradle files as canonical
  • Prefer IDE refactors over manual edits
  • Do not hand-edit generated files
  • Keep build variants and flavors explicit
  • Respect Android lifecycle constraints
  • Avoid brittle device- or OS-specific hacks

🧱 Modules, Builds & Architecture​

  • Use modules to enforce boundaries
  • Separate:
    • app
    • feature modules
    • libraries
    • test utilities
  • Keep dependency direction explicit
  • Align module structure with app architecture
  • Document non-obvious Gradle decisions

⚡ Productivity, Debugging & Refactoring​

  • Heavy use of:
    • Debugger with device awareness
    • Logcat filters and structured logs
    • Layout Inspector & Compose tools
    • Safe rename, extract, and move refactors
  • Prefer:
    • reproducing issues on real devices
    • lifecycle-aware debugging
  • Optimize for fast feedback on device

🧪 Reliability, Builds & Tooling​

  • Align Android Studio builds with CI
  • Use Gradle tasks as the single source of truth
  • Keep dependency versions centralized
  • Use test runners and device matrices
  • Treat lint warnings as correctness signals

📝 Explanation Style​

  • Use Android-specific terminology
  • Explain:
    • module vs variant scope
    • lifecycle implications
    • device vs emulator differences
  • Avoid platform-agnostic advice unless required

✍️ User-owned​

These sections must come from the user.
They define scope, app constraints, and acceptable automation depth.

📌 What (Task / Action)​

Examples:

  • Configure Android Studio for a project
  • Debug a runtime or lifecycle issue
  • Refactor a multi-module Android app
  • Improve build performance or reliability
  • Optimize emulator or device workflows

🎯 Why (Intent / Goal)​

Examples:

  • Reduce crashes and ANRs
  • Improve iteration speed
  • Ensure lifecycle correctness
  • Align local builds with CI
  • Improve team onboarding

📍 Where (Context / Situation)​

Examples:

  • Consumer Android app
  • Enterprise internal app
  • Multi-flavor / white-label app
  • Legacy Android project
  • Jetpack Compose–based app

⏰ When (Time / Phase / Lifecycle)​

Examples:

  • Initial project setup
  • Active bug investigation
  • Refactor or modularization
  • Pre-release hardening
  • Long-term maintenance

🔗 Final Prompt Template (Recommended Order)​

1️⃣ Persistent Context (Put in project docs or README.md)​

# Android Studio Power-User Rules

You are working inside Android Studio on a production Android project.

## Core Principles

- Trust the Gradle model
- Prefer IDE tooling over manual edits
- Optimize for lifecycle safety

## Configuration

- Keep build variants explicit
- Avoid Gradle configuration drift
- Use Gradle tasks as the source of truth

## Productivity

- Debug on real devices when possible
- Use IDE refactors and inspections

## Safety

- Treat lint warnings seriously
- Avoid lifecycle-unsafe patterns

2️⃣ User Prompt Template​

What I want to do:
[Describe the Android Studio task or workflow.]

Why it matters:
[Performance, correctness, lifecycle safety.]

Where this applies:
[App type, modules, Android versions.]
(Optional)

When this is needed:
[Phase: setup, debugging, refactor, release.]
(Optional)

✅ Fully Filled Example​

What I want to do:
Debug a crash that only occurs after backgrounding the app.

Why it matters:
The crash affects real users and is tied to lifecycle events.

Where this applies:
A multi-module Android app using ViewModel and Room.

When this is needed:
During pre-release testing.

🧠 Why This Ordering Works​

  • Gradle model first prevents invalid assumptions
  • Intent next guides tooling depth
  • Scope last limits unintended changes

The device reveals the truth.
Gradle defines structure.
Context turns Android Studio into a lifecycle-safe powerhouse.

Happy building with Android Studio 🟢📱🛠️