Android Build Verification

Android Build Verification 🛠️🔍

A foundational quality guard for Android AI Agents that ensures no code is committed or merged without a successful compilation.

⚡ When to Use

• After EVERY edit: After you modify more than 2 files or 20 lines of code.
• Dependency Changes: After updating libs.versions.toml or build.gradle.kts.
• DI/Schema Changes: After adding a new @HiltAndroidApp, @Entity, or @Dao.
• Resource Changes: If you add new icons or strings to res/.

🏗️ The Build Workflow

1. Fast Compilation Check

• Command: ./gradlew assembleDebug --parallel --build-cache
• Purpose: Verify that the entire project compiles.

2. Unit Verification

• Command: ./gradlew testDebugUnitTest
• Purpose: Ensure that logic didn't regress after the build script was changed.

3. Manifest & Resource Consistency (Critical)

• Hilt Entry Point: Verify that the Application class (annotated with @HiltAndroidApp) is registered in AndroidManifest.xml under android:name.
• Theme Bridge: If using Material 3 XML themes, ensure com.google.android.material:material is present in dependencies.
• Icon Resources: Check that res/mipmap-anydpi-v26 and res/drawable contain valid XML vectors for adaptive icons to avoid AAPT linking errors.

🛑 Scaffolding / Empty Project Guardrails

When explicitly tasked to create a project or scaffold a new feature from scratch, agents MUST verify these items before claiming completion:

1. Complete Theme Implementation: Did you actually create Theme.kt, Color.kt, and Type.kt? (Prevents Theme not found errors).
2. Compose Compiler Symmetry: Did you double-check that the composeCompiler version explicitly matches the kotlin plugin version in libs.versions.toml?
3. Auxiliary Dependencies: Did you add the required libraries you referenced? (e.g. coil-compose, hilt-navigation-compose, windowsizeclass).
4. End-to-End Hookup: Are all UI buttons calling actual ViewModel methods that hit a Repository, or did you accidentally leave an empty { /* TODO */ } block? Do not leave disconnected UIs.

🚀 Performance Strategies

• Daemon Speed: Keep the Gradle daemon warm by running consecutive tasks.
• Offline Mode: If building frequently without dependency changes, use --offline to skip network checks.
• Task Selection: If only one module changed (e.g., :feature:auth), only build that module: ./gradlew :feature:auth:assembleDebug.

🧪 Error & Symptom Checker

• "Unresolved Reference": Check imports or if the target module is missing from settings.gradle.kts.
• "Duplicate Class": Check for version conflicts in libs.versions.toml.
• "Hilt Error": Ensure the @AndroidEntryPoint or @Module classes have the correct annotations and that kapt is active.
• "Room Schema Export": Verify if you moved database versioning without updating the exportSchema config.

📐 Continuous Verification Workflow (For Agents)

• Step 1: Make the intended change.
• Step 2: Run ./gradlew assembleDebug.
• Step 3: If it fails, fix the code immediately.
• Step 4: Report "Build Successful" alongside the code changes to the user.

📜 Checklist for Reliability

• Local Build: Did it pass locally before saying "I'm done"?
• Syncing: Did you run git add . and commit the new files for the user?
• Lint: Are there no critical lint errors that would prevent a release?

🔗 Related Resources

• Detekt Expert Skill
• Unit Testing Skill
• Gradle Expert Skill