android-gradle-build-logic

Android Gradle ビルドロジック

使用するタイミング

• 次のようなリクエストでこのスキルを使用します：Android Gradle プラグインのセットアップ、Android モジュールのビルドロジックの修正、Android リポジトリのバージョンカタログ。
• 主な成果：Gradle、バージョンカタログ、プラグイン、コンベンションパターン、ツールチェーンの互換性を用いて、Android のビルドロジックを整えます。
• 対象範囲が広がる場合は、次のスキルに引き継ぎます：
• android-modernization-upgrade
• android-ci-cd-release-playstore

ワークフロー

1. リクエストを、現在の Android スタック、モジュールの境界、最低サポート API レベルに対応付けます。
2. 既存の実装を調べ、暗黙の前提、重複するヘルパー、古くなったパターンを確認します。
3. 正確性、可読性、長期的な保守性を高める最小限の変更を適用します。
4. 関連するショーケースアプリのパスとリポジトリのベンチマークに照らして、結果を検証します。
5. 中核となる基盤が安定してから、関連する作業を次の専門スキルに引き継ぎます。

ガードレール

• Android や Kotlin の公式ガイダンスと独自のローカル規約が矛盾する場合は、公式ガイダンスを優先します。
• 公開 API は明快で明示的なものにし、Android のライフサイクルに伴うコストを隠す巧妙な抽象化は避けます。
• リクエストで両方が明示的に必要とされていない限り、アーキテクチャの整理とプロダクトの動作変更を混在させません。
• 古いモジュールや生成コードに影響する互換性の制約は、必ず文書化します。

アンチパターン

• 明確な所有境界を設けずに、モジュール間にヘルパーを散在させること。
• 純粋なドメイン層やデータ層に、フレームワーク固有のコードを導入すること。
• 変更が必要なのは契約の1か所だけなのに、周辺のファイルをすべてリファクタリングすること。
• 移行に関する注意事項を暗黙のままにし、文書化しないこと。

例

通常のケース

• シナリオ：バージョンカタログを使用して、クリーンなチェックアウトから Compose ショーケースをビルドします。
• コマンド：cd examples/orbittasks-compose && ./gradlew :app:assembleDebug

エッジケース

• シナリオ：XML フィクスチャで共有リポジトリとプラグイン管理を検証します。
• コマンド：cd examples/orbittasks-xml && ./gradlew :app:assembleDebug

障害からの復旧

• シナリオ：modernization スキルおよび CI スキルとのビルドロジックトリガーの精度をベンチマークします。
• コマンド：python3 scripts/eval_triggers.py --skill android-gradle-build-logic

完了チェックリスト

• 実装パスが明確かつ最小限で、適切な Android の対象領域に対応しています。
• 関連するサンプルコマンドとベンチマーク用プロンプトを実行または更新しています。
• リクエストが境界をまたぐ場合、関連スキルへの引き継ぎを文書化しています。
• 選択したパターンと、主な移行またはトラブルシューティングの手順を公式資料で確認しています。

公式資料

• https://developer.android.com/build
• https://developer.android.com/build/releases/gradle-plugin
• https://developer.android.com/build/migrate-to-built-in-kotlin
• https://docs.gradle.org/current/userguide/userguide.html