android-development

プラットフォームに関する注意事項

• オプションのヘルパープラグインが一部の環境で役立つ場合がありますが、これらはこのスキルに必須のものとして扱ってはなりません。

Android 開発標準

謝辞: Peter Bamuhigire、techguypeter.com、+256 784 464178 氏による共有。

使用する場面

• AI エージェント実装のための Android 開発標準。Kotlin ファースト、Jetpack Compose UI、MVVM + クリーンアーキテクチャ、Hilt DI、包括的なセキュリティ、テスト、パフォーマンスのパターン。Android アプリケーションを構築またはレビューするときに使用します...

生成されるエビデンス

カテゴリ	成果物	形式	例
正確性	Android 機能テスト計画	単体テスト、インストルメンテーションテスト、Compose テストを網羅する Markdown ドキュメント	docs/android/feature-tests-checkout.md
UX 品質	アクセシビリティ監査	TalkBack、セマンティクス、コントラストを網羅する Markdown ドキュメント	docs/android/a11y-checkout.md

参照

• 以下のコアワークフローを読んだ後、詳細については references/ ディレクトリを使用してください。
• Room、DataStore、マイグレーション、またはオフライン同期については、保持されている Android 永続化ワークフロー を読み込んでください。
• Red-Green-Refactor、テストシーム、レイヤー固有のテスト設計については、保持されている Android TDD ワークフロー を読み込んでください。
• オンデバイスの Android AI/ML、ML Kit、LiteRT、MediaPipe、AICore、Gemini Nano については references/android-ai-ml.md を参照してください。
• AndroidX Biometric の起動ゲートと CryptoObject に裏付けられた認証については references/android-biometric-login.md を参照してください。
• ネイティブの PdfDocument エクスポートと Android レポート PDF 生成については references/android-pdf-export.md を参照してください。

読み込み順序

1. 共有の本番ゲートのために world-class-engineering を読み込んでください。
2. Android アプリがより大きなバックエンドまたはマルチモジュールシステムの一部である場合は system-architecture-design を読み込んでください。
3. Android 実装の詳細についてはこのスキルを読み込んでください。
4. すべてのユーザー向け Android 画面、特にプレミアム、ダッシュボード、オンボーディング、レポート、フォーム、または収益に重要なフローについては android-ui-ux-design を読み込んでください。
5. 必要に応じて vibe-security-skill および機能固有のスキルを読み込んでください。

AI 支援実装のための本番グレードの Android 開発標準。最新の Android ベストプラクティスに従った Kotlin ファーストと Jetpack Compose。

コアスタック: Kotlin 100% | Jetpack Compose (デフォルトの UI ツールキット) | MVVM + クリーンアーキテクチャ | Hilt DI 最小 SDK: 29 (Android 10) | ターゲット SDK: 35 (Android 15) 互換性: 最小 SDK (サポートされる最も古いバージョン) と最新の安定版 Android リリースの両方で完璧に動作する必要があります リファレンスアプリ: Now in Android - これらの標準を本番品質のコードベースで示す Google 公式サンプル

使用する場面

• 新しい Android アプリケーションや機能を構築するとき
• 品質と標準への準拠のために Android コードをレビューするとき
• AI エージェントを介して Kotlin/Compose コードを生成するとき
• Android プロジェクト構造をセットアップするとき
• セキュリティ、テスト、またはパフォーマンスのパターンを実装するとき
• Android クライアントから REST API と統合するとき

バックエンド環境

Android アプリは、3 つの環境にデプロイされた PHP/MySQL バックエンドに接続します:

環境	ベース URL パターン	データベース	備考
開発	http://{LAN_IP}:{port}/DMS_web/api/	MySQL 8.4.7 (Windows WAMP)	localhost ではなく、ホストマシンの LAN IP を使用してください
ステージング	https://staging.{domain}/api/	MySQL 8.x (Ubuntu VPS)	QA およびテスト用
本番	https://{domain}/api/	MySQL 8.x (Debian VPS)	実ユーザー

ビルドフレーバー (dev、staging、prod) を使用してベース URL を設定し、ビルドバリアントごとにアプリが正しいバックエンドをターゲットにするようにしてください。すべてのバックエンドは utf8mb4_unicode_ci 照合順序と MySQL 8.x を使用します。

クイックリファレンス

トピック	参照ファイル	対象範囲
プロジェクト構成	references/project-structure.md	ディレクトリレイアウト、モジュール構成
Kotlin 規約	references/kotlin-conventions.md	コーディングスタイル、Compose パターン
アーキテクチャ	references/architecture-patterns.md	MVVM、クリーンアーキテクチャのレイヤー
依存性注入	references/dependency-injection.md	Hilt モジュール、スコープ、ViewModel 注入
セキュリティ	references/security.md	暗号化ストレージ、生体認証、ネットワークセキュリティ
UI デザインシステム	references/ui-design-system.md	トークン、コンポーネント、Material 3
プレミアム Android UX	../android-ui-ux-design/SKILL.md	Material 3 の磨き込み、モバイルエルゴノミクス、プレミアムゲート
画面パターン	references/screen-patterns.md	完全な画面テンプレート、状態管理
テスト	references/testing.md	ユニットテスト、UI テスト、インストルメンテーションテスト
ビルド構成	references/build-configuration.md	Gradle KTS、Android Studio のセットアップ、依存関係、ビルドタイプ、ビルド速度のチューニング
API 統合	references/api-integration.md	Retrofit、エラーハンドリング、リポジトリパターン
分析とパフォーマンス	references/analytics-performance.md	Firebase、モニタリング、最適化
AI エージェントガイドライン	references/ai-agent-guidelines.md	プロンプトテンプレート、品質チェックリスト

アーキテクチャの概要

Presentation Layer (Compose + ViewModels)
         |
    Domain Layer (Use Cases + Repository Interfaces)
         |
    Data Layer (Repository Impl + API + Room)

レイヤーのルール

1. Presentation は Domain にのみ依存します
2. Domain は Android への依存を持ちません (純粋な Kotlin)
3. Data は Domain のインターフェースを実装し、API/DB を処理します

パッケージ構成

com.company.app/
  core/          # Shared: DI, models, repositories, utils
  data/          # Room DB, API services, data sources
  presentation/  # Screens, ViewModels, components, navigation
  theme/         # Design system tokens

主要な標準のまとめ

Kotlin

• 100% Kotlin、新しいコードに Java は使用しない
• 非同期処理にはコルーチン + Flow を使用する (コールバックは決して使用しない)
• UI 状態のモデリングには sealed クラスを使用する
• ユーティリティコードには拡張関数を使用する

Compose

• Jetpack Compose はすべての新しい画面におけるデフォルトの UI ツールキットです
• Views はレガシーな相互運用またはサードパーティの View 専用 SDK に限り許可されます
• ステートレスなコンポーザブルを推奨 (状態は ViewModel にホイストします)
• 副作用には LaunchedEffect を使用し、コンポジション内では決して使用しない
• Flow の収集には collectAsStateWithLifecycle() を使用する
• LazyColumn/LazyRow のアイテムには安定したキーを使用する
• アダプティブレイアウトは必須 — スマートフォン/タブレット/折りたたみ式デバイスには WindowSizeClass を使用します
• Material 3 アダプティブライブラリ: androidx.compose.material3.adaptive:adaptive

カスタム PNG アイコン (必須)

• カスタム PNG アイコンのみを使用し、アイコンライブラリは使用しないでください
• painterResource(R.drawable.<name>) または @drawable/<name> を使用します
• プロジェクトルートで PROJECT_ICONS.md を維持管理します

命名、ディレクトリのルール、トラッキングについては、mobile-platform-operations スキル (その mobile-custom-icons リファレンス) に従ってください。

チャート (Vico 標準)

• すべてのチャートのニーズ (折れ線、棒、縦棒、ローソク足など) には Vico を使用します
• 新しい画面には Compose モジュールを推奨します。Views は必要な場合にのみ使用してください
• セットアップと最新バージョンについては、常に公式ガイドに従ってください
• パターンとスタイリングについては、Vico のサンプルモジュールを参照してください

レポートの表 (25 行以上)

• 25 行を超える可能性があるレポートは、カードではなく表としてレンダリングする必要があります
• 表ファーストのガイダンスについては android-ui-ux-design スキル (25 行を超えるビジネスレポートでは表ファーストまたは高密度リストパターンを使用) に、エクスポートされるレポートの表については professional-word-output スキルに従ってください。

3 つのビルドバリアント (必須)

すべての Android アプリは、正確に 3 つのビルドバリアントを持つ MUST があります。これは交渉の余地がありません。

バリアント	目的	APK 名	縮小	インストール先
debug (dev)	ローカル開発	{AppName}-dev-{version}.apk	いいえ	エミュレーター (デフォルト)
staging	QA / 本番前	{AppName}-staging-{version}.apk	はい (R8)	エミュレーター (オンデマンド)
release (prod)	本番 / Play Store	{AppName}-prod-{version}.apk	はい (R8)	実機 (手動)

ルール:

1. ユーザーが提供する必要があります 各プロジェクトの staging と production の API URL を。Debug は常にローカルの開発サーバー (http://10.0.2.2/... はエミュレーター用、またはホストの LAN IP) を指します。
2. アクティブな開発中は、必要なバリアントのみをビルドしてください — 通常は debug です。毎回のイテレーションで staging と release をビルドしないでください。
3. デフォルトのローカルループ: 通常のコーディング、UI 作業、デバイステストには ./gradlew installDebug (または assembleDebug) を使用します。
4. 3 つの APK をすべてビルドするのは、リリース検証、QA 引き継ぎ、CI、またはユーザーがすべての成果物を明示的に要求した場合のみ: ./gradlew assembleDebug assembleStaging assembleRelease
5. ユーザーが staging のテストを明示的に要求した場合は、代わりに staging をインストールします: ./gradlew installStaging
6. APK の命名 は、アプリごとに一貫したプレフィックスを使用します (例: DMS-dev-1.0.0.apk、DMS-staging-1.0.0.apk、DMS-prod-1.0.0.apk)。非推奨の内部出力クラスではなく、最新の Android Components Variant API を使用して設定します。
7. Staging は release から継承します (R8 有効、リソース縮小) が、debug 署名設定を使用するため、同じデバイス上で dev と並行してインストールできます。
8. ProGuard ルール は、staging および release ビルドから Log.v、Log.d、Log.i、println を除去する必要があります。
9. API URL をハードコードしないでください — 常にビルドタイプごとに設定された BuildConfig.API_BASE_URL (または類似のもの) を使用してください。

完全な Gradle 設定については、references/build-configuration.md を参照してください。

API エンドポイントは常にビルドタイプまたはフレーバーごとに BuildConfig.API_BASE_URL (または同様の生成された定数) を通じて設定してください。アプリコード内でサーバー URL をハードコードしないでください。

Android Studio + ビルド速度のベースライン

より深いパフォーマンス作業を行う前に、このベースラインを確立してください:

1. ツールを最新の状態に保つ — プロジェクトが許す限り、Android Studio、SDK ツール、Gradle、AGP をまとめて更新してください。
2. kapt の代わりに KSP を使用する ライブラリがサポートしている場合はどこでも。kapt はレガシーとして扱うべきです。
3. 依存関係とプラグインのバージョンを固定する — 2.+ や latest.release のような動的バージョンは決して使用しないでください。
4. Jetifier を無効にする Build Analyzer がプロジェクトにまだ必要であると証明しない限り。
5. 構成キャッシュを有効にする プロジェクトとプラグインが互換性を持つようになったら。
6. Gradle スクリプトで構成回避と遅延 API を使用する; 構成中に高コストなロジックを実行しないでください。
7. デバッグビルドを静的保つ — 動的なバージョン名、マニフェストプレースホルダー、または完全な再ビルドを強制する生成値は使用しないでください。
8. モジュール化を優先する アプリが十分に大きく、機能またはコアモジュールが独立してコンパイルできる場合。
9. 推測する前に Build Analyzer と Gradle プロファイリングを使用する。まず測定し、次に実際のボトルネックを最適化してください。
10. 可能な限り API 24+ のデバイス/エミュレーターで開発する より迅速なデプロイループのために。

デバイスと Android バージョンの互換性 (重要)

私たちのアプリは、古いデバイスをまだ使用している少数の人々のために動作しなければならず、また、より新しい/最新のデバイスを使用している人々のためにも動作しなければなりません。1 つの Android バージョンだけでテストしないでください。

必須ルール:

1. enableEdgeToEdge() は必須です — MainActivity.onCreate() 内で super.onCreate() の前に呼び出してください。Android 15 (API 35) は、SDK 35 をターゲットとするアプリに対して edge-to-edge を強制します。これがないと、アプリは Android 15 デバイスで即座にクラッシュします。これは譲れません。
2. window.statusBarColor を直接設定しないでください — これは非推奨であり、edge-to-edge と競合します。システムバーの色は enableEdgeToEdge() に処理させてください。ライト/ダークのアイコンの外観のみを WindowCompat.getInsetsController().isAppearanceLightStatusBars で制御してください。
3. 少なくとも 2 つの Android バージョンでテストしてください — 出荷前に、必ず minSdk エミュレーター (Android 10) と最近の Android (14/15) エミュレーターまたはデバイスの両方で検証してください。
4. バージョン固有の API をガードしてください — minSdk より後に追加された API を使用する場合は、if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.X) チェックでラップしてください。
5. targetSdk を最新に保ってください — 最新の安定版 SDK (現在は 35) をターゲットにしてください。遅れを取らないでください — Google Play は最近の targetSdk を要求し、より新しい Android バージョンはそれをターゲットとするアプリに対してより厳格な動作を強制します。
6. ロケール切り替えが必要な場合は AppCompatActivity を使用してください (AppCompatDelegate.setApplicationLocales())。それ以外の場合は、純粋な Compose アプリには ComponentActivity を推奨します。

正しい MainActivity のパターン:

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        installSplashScreen()  // Before super
        enableEdgeToEdge()     // Before super — MANDATORY for targetSdk 35
        super.onCreate(savedInstanceState)
        setContent { ... }
    }
}

セキュリティ

• 機密データには EncryptedSharedPreferences
• API 呼び出しには証明書ピンニング — プレースホルダーのピンは絶対に使用しないでください (SSLPeerUnverifiedException の原因になります)。有効にする前に、openssl を使用してサーバーから実際の SHA-256 ピンを抽出してください。抽出コマンドについては references/security.md を参照してください。
• Let's Encrypt サーバーの場合: 常に中間 CA (安定) をリーフピンとともにピン留めしてください。リーフピンは自動更新で 90 日ごとにローテーションしますが、中間 CA ピンは更新を越えて維持されます。
• ENABLE_CERT_PINNING BuildConfig フラグを使用してください: 開発では false、ステージング/本番では true
• アプリが接続するすべてのサーバードメイン (ステージングと本番の両方) をピン留めしてください
• 機密性の高い操作には生体認証
• ハードコードされたシークレットは使用せず、BuildConfig フィールドを使用してください
• リリースビルドには ProGuard/R8

テスト

• ViewModel とユースケースのユニットテスト (MockK)
• 画面の Compose UI テスト (ComposeTestRule)
• Flow テスト用の Turbine
• テストでの DI 用の Hilt テストルール

パフォーマンス

• デバッグビルドでの StrictMode
• 遅延リストでの安定したキー
• 高コストな計算には derivedStateOf
• キャッシュを伴う Coil による画像読み込み
• リリースでの ProGuard + リソース縮小
• 通常の開発中は debug のみでビルドし、完全なマルチバリアントビルドは QA またはリリースチェックのために取っておいてください
• Gradle のメモリ、GC、プラグイン設定を変更する前に Build Analyzer を使用してください
• KSP ベースのプロセッサを優先し、サポートされた移行パスがない限り kapt を削除してください
• 依存関係の監査でそうでないと証明されない限り、android.enableJetifier=false を維持してください
• プラグインの互換性を確認し、違反を修正した後にのみ構成キャッシュを有効にしてください

リリースゲート

Android の機能を本番準備完了と呼ぶ前に:

• minSdk と最新の Android でメインのユーザージャーニーを検証します。
• オフライン、低速ネットワーク、権限拒否時の動作を検証します。
• 起動、スクロール、リスト操作をパフォーマンス期待値に対して検証します。
• クラッシュレポート、分析、監査上重要なアクションが計測されていることを検証します。
• 機密データがログ、スクリーンショット、または保護されていないストレージに決して残らないことを検証します。
• ナビゲーション、タッチターゲット、テキストスケーリング、TalkBack、状態の完全性、プラットフォームネイティブの洗練性について、android-ui-ux-design のプレミアム UX チェックを検証します。

ローカル開発ネットワーキング (WAMP)

• ローカルマシン (Windows WAMP または Ubuntu) で開発する場合、Android エミュレーターは localhost ではなく、ホストマシンの静的 LAN IP を介してバックエンドに到達する必要があります。
• 静的 IP は常に開発セットアップノートに記載し、Android 開発ビルドの BASE_URL に使用してください。
• ファイアウォールルールが WAMP HTTP ポートへのインバウンド接続を許可していることを確認してください。

Google Play レビュー準備

• Play Console への提出前に、mobile-platform-operations スキル (その google-play-store-review リファレンス) を使用してください。
• targetSdk を最新に保ち、バックグラウンド処理を準拠した状態にしてください。
• Data Safety フォームが SDK と権限に一致していることを確認してください。
• 公開されたプライバシーポリシーを提供し、アプリ内でリンクしてください。
• 広告と IAP フローの透明性とユーザーによる制御を検証してください。

必須のテーマ外観設定

すべての Android アプリは、Tools/Settings セクションにテーマ外観セレクターを含めなければなりません (MUST)。これは譲れない標準です — ユーザーがアプリの視覚テーマを制御できるようにする必要があります。

要件:

1. 3 つのオプション: システムデフォルト (デバイス設定に従う)、ライト、ダーク
2. デフォルト: システムデフォルト — 常にユーザーのデバイス全体の設定を尊重してください
3. 配置: Tools または Settings ハブ画面の「Appearance」セクションの下
4. 永続化: SharedPreferences に保存 (暗号化しない — 機密情報ではないため)
5. リアクティビティ: テーマ変更はアプリの再起動なしで即座に適用 (StateFlow を使用)

実装パターン:

// 1. ThemePreferences.kt (data/local/prefs/)
enum class ThemeMode(val key: String, val label: String) {
    SYSTEM("system", "System default"),
    LIGHT("light", "Light"),
    DARK("dark", "Dark");
    companion object {
        fun fromKey(key: String): ThemeMode =
            entries.firstOrNull { it.key == key } ?: SYSTEM
    }
}

@Singleton
class ThemePreferences @Inject constructor(
    @ApplicationContext context: Context
) {
    private val prefs = context.getSharedPreferences("theme_prefs", Context.MODE_PRIVATE)
    private val _themeMode = MutableStateFlow(loadThemeMode())
    val themeMode: StateFlow<ThemeMode> = _themeMode.asStateFlow()

    private fun loadThemeMode(): ThemeMode =
        ThemeMode.fromKey(prefs.getString("theme_mode", "system") ?: "system")

    fun setThemeMode(mode: ThemeMode) {
        prefs.edit().putString("theme_mode", mode.key).apply()
        _themeMode.value = mode
    }
}

// 2. MainActivity.kt — resolve ThemeMode to darkTheme boolean
val themeMode by themePreferences.themeMode.collectAsState()
val darkTheme = when (themeMode) {
    ThemeMode.SYSTEM -> isSystemInDarkTheme()
    ThemeMode.LIGHT -> false
    ThemeMode.DARK -> true
}
AppTheme(darkTheme = darkTheme) { /* content */ }

// 3. Tools/Settings screen — FilterChip row for selection
ThemeMode.entries.forEach { mode ->
    FilterChip(
        selected = selected == mode,
        onClick = { viewModel.setThemeMode(mode) },
        label = { Text(mode.label) },
        leadingIcon = if (selected == mode) { { Icon(Icons.Default.Check, null) } } else null
    )
}

フェーズ 1 ブートストラップパターン (SaaS モバイルアプリ)

既存の SaaS バックエンド向けにネイティブ Android アプリを構築する場合、常にフェーズ 1 を最初に実装してください: ログイン + ダッシュボード + 空のタブ。これはビジネス機能の前に必須の出発点です。

フェーズ 1 が提供するもの

1. JWT 認証 — ログイン/ログアウト、ローテーション付きトークンリフレッシュ、漏洩検知、暗号化ストレージ
2. ダッシュボード — 実際の KPI 統計、オフラインファーストの Room キャッシュ、プル・トゥ・リフレッシュ、シマー読み込み
3. 5 タブナビゲーション — 最大 5 タブのボトムバー、将来の機能用のプレースホルダー画面
4. 完全なインフラストラクチャ — Hilt DI、Retrofit インターセプターチェーン、Room DB、Material 3 テーマ、ネットワークモニター
5. 40 以上のユニットテスト — ViewModel、Use Case、リポジトリ、インターセプターをすべてテスト

なぜフェーズ 1 を最初に行うのか

• 垂直スライス全体 (Compose UI → ViewModel → UseCase → Repo → Retrofit → PHP → MySQL) を証明します
• 再利用可能なすべてのインフラストラクチャパターンを確立します
• ユーザーにすぐに動作するインストール可能なアプリを提供します
• バックエンド統合の問題を早期に発見します

完全なフェーズ 1 プランテンプレートについては android-saas-planning スキルを参照してください。

KMP プロジェクト

これが Kotlin Multiplatform プロジェクトの場合、このスキルは composeApp/ モジュール (Android UI とプラットフォーム統合) を統制します。shared/ モジュールは kmp-development スキルによって統制されます。composeApp/ では DI に Hilt を、shared/ では Koin を使用してください。共有モジュールのテスト駆動開発には kmp-development スキルを使用してください。

アンチパターン

• ビジネスロジックを Composable に配置する
• ViewModel で StateFlow の代わりに mutableStateOf を使用する
• デザイントークンの代わりに色/寸法をハードコードする
• UI でエラー状態をスキップする
• メインスレッドでネットワーク呼び出しを行う
• LazyColumn の項目で key パラメーターを欠落させる
• 神 ViewModel (画面単位ではなく機能単位で分割する)
• ライフサイクルを無視する (collectAsStateWithLifecycle を使用する)
• スマートフォン専用 UI を構築する — すべての画面はタブレット/折りたたみ式デバイスに適応する必要があります
• WindowSizeClass ブレークポイントの代わりにハードコードされた isTablet() チェックを使用する
• enableEdgeToEdge() の欠落 — Android 15 デバイスで即座にクラッシュを引き起こします
• window.statusBarColor を直接設定する — 非推奨であり、edge-to-edge と競合します
• 1 つの Android バージョンでのみテストする — 古いデバイス (minSdk) と新しいデバイス (最新) の両方で検証する必要があります

他のスキルとの統合

feature-planning           -> spec + implementation strategy
  |
android-development        -> Kotlin/Compose implementation
  |
android-ui-ux-design       -> premium Material 3 UX and screen quality
  |
mobile-platform-operations -> Play policy and submission readiness
  |
api-error-handling         -> Backend API error patterns
  |
mysql-best-practices       -> Database schema (backend)
  |
vibe-security-skill        -> Security review

Web 接続された Android アプリには、このスキルと併せて常に vibe-security-skill を適用してください。 Play Console への提出を準備する際には mobile-platform-operations を使用してください。

リファレンス実装

判断ルール

条件	選択
新しいユーザーインターフェース	Compose。既存の View システムは安定した境界の背後に分離します
画面間で共有されるビジネスルール	純粋な Kotlin ドメインのユースケース
Android フレームワークへの依存	ドメイン層の外に保ちます
環境によってリリースの挙動が異なる	型付きのビルドフレーバー設定。実行時にハードコードされた URL は使いません

縮退モード

ビルドやデバイスが利用できない場合は、レビュー可能なパッチを提供し、まだ実行が必要な Gradle、ユニット、インストルメンテーション、アクセシビリティ、最小 SDK の各チェックを正確に列挙してください。静的な検査だけでデバイス互換性を主張してはいけません。

Google は 3 つの公式リファレンスリポジトリを維持しています。これらを正規の例として使用してください:

Now in Android (github.com/android/nowinandroid)

本番品質の完全なアプリ。用途: マルチモジュールアーキテクチャ、規約プラグイン、オフラインファースト (Room + ネットワーク同期)、モジュール間の Hilt、バージョンカタログ、Gradle KTS ビルド設定。

Architecture Samples (github.com/android/architecture-samples)

レイヤードアーキテクチャの TODO アプリ。用途: MVVM パターンの明確さ、2 つのデータソースを持つ Repository パターン、Compose によるシングルアクティビティナビゲーション、プロダクトフレーバー (mock/prod)、包括的なテストスイート (ユニット + 統合 + E2E)、関心の分離の徹底。

Compose Samples (github.com/android/compose-samples)

焦点を絞った Compose アプリのコレクション。特定の UI パターンに使用:

サンプル	用途
JetNews	Material アプリの構造、テーマ設定、Compose テスト
Jetchat	Material 3、動的カラー、ナビゲーション、状態管理
Jetsnack	カスタムデザインシステム、レイアウト、アニメーション
Jetcaster	Redux スタイルのアーキテクチャ、動的テーマ設定、Room、コルーチン
Reply	アダプティブ UI (スマートフォン/タブレット/折りたたみ式)、Material 3
JetLagged	カスタムレイアウト、グラフィックス、Canvas/Path 描画

何かの実装方法に迷ったら、まずこれらのリポジトリを確認してください。

入力

成果物	必須?	目的
Android の要件、サポートする API レベル、アーキテクチャ、UX、バックエンドの契約	はい	実装の範囲を定めます

出力

• ライフサイクル、アクセシビリティ、テスト、パフォーマンス、リリースのエビデンスを伴う Android コードまたは設計を生成します。

ケイパビリティ契約

読み取り/検索およびローカルビルドはタスクの範囲に従います。署名、ストアへの公開、バックエンドの変更、デバイスデータの破壊には明示的な権限が必要です。