Android Jetpackを支えるAndroidX開発リポジトリ

AOSPと同期するandroidxの役割

androidx/androidxはAndroid Jetpack拡張ライブラリを開発する環境で、androidx名前空間のコードを含みます。READMEはAndroid Jetpackの主開発ブランチとAOSPのframeworks/supportが同期する関係を示しています。Activity、AppCompat、Biometric、Collection、Compose Runtime、Core、DataStore、Fragment、Lifecycle、Navigation、Paging、Room、WorkManagerなど領域が広く、単一ライブラリのリポジトリではありません。問題を調べるときはトップレベルの規模で判断せず、該当するmoduleとそのテスト、OWNERSを起点に読む必要があります。

バグ修正にテストが必要な理由

受け付ける貢献にはバグ修正、綴りの修正、ドキュメント更新、未カバー領域の新しいテストがあります。バグ修正にはAndroid Issue Trackerの対応報告が必要で、各修正にはテストを伴わせることが期待されています。既存ライブラリへの新機能はAndroidXチームメンバーが承認したfeature request bugが条件です。つまり、コードを先に送るより、再現条件と対象APIをIssue Trackerで特定し、module内に回帰テストを置けるかを確認することが提出の前提です。

レビューへ進むrepo uploadの流れ

変更を作った後はrepo uploadを実行し、r.android.comでレビューを開きます。適切なreviewerは対象ファイルを最近多く変更した担当者をgit logで探すか、そのディレクトリのOWNERSを確認して選びます。レビュー作法を守ることは巨大な共有コードベースでの責任範囲を明確にします。ローカルで通ったことだけを根拠に提出せず、影響するAPI、テスト、公開ドキュメントを変更単位にまとめ、レビュアーが同じmoduleを再現できる状態を作ることが重要です。

Hermetic buildを支える依存物

AndroidXはGradleのバイナリ依存物をgitで管理し、prebuilts/androidx/internalとprebuilts/androidx/externalにコピーを置きます。これらはgoogle()やmavenCentral()からも得られると説明されていますが、チェックアウト内のコピーは再現性を保つための材料です。新しい依存関係はdevelopment/importMavenのツールで取り込む手順が示されています。依存を直接更新する前に、対象のprebuilts分類、生成物の差分、影響するCIジョブを確認し、ローカルのキャッシュだけで成功していないかを切り分ける必要があります。

巨大な木を安全に変更する

このリポジトリは複数のJetpack領域を束ねるため、変更の影響が対象moduleの外へ及ぶ可能性があります。最初にmoduleのREADME、テスト、OWNERS、Issue Trackerの報告を読み、必要な範囲だけをチェックアウトしてビルドします。READMEは個々のライブラリの性能保証やアプリ互換性を一括で約束していません。Apache-2.0の利用条件もコードの採用判断とは別に確認します。レビュー提出前には変更対象のテストを実行し、依存物を含む差分とCI結果を記録するのがAndroidXに即した確認です。

module単位で変更の影響を絞る

AndroidXでは、トップレベルのビルドが成功しても対象ライブラリのAPI契約が保たれたとは限りません。まずActivityやRoomなど該当moduleのREADME、テスト、OWNERSを読み、Issue Trackerの再現手順に沿ったテストを追加します。Compose RuntimeやLifecycleのように依存する利用者が多い領域では、公開APIの変更、Binary Compatibility、ドキュメントの差分を別々に確認します。prebuilts/androidx/internalとexternalを更新する場合は、importMavenの生成結果とGradleの解決先を比較し、手元のMaven cacheに依存していないCIを走らせます。repo upload後はr.android.comのレビューIDとレビュアーを変更記録に紐付け、修正前後のテストログを残します。Apache-2.0の条件は依存物ごとに確認し、AOSP同期のタイミングもリリース計画へ反映します。

依存更新をCIの条件で再現する

AndroidXの変更では、対象moduleのテストを通すだけでなく、prebuilts/androidx/internalとexternalの依存が同じ解決結果になるかを見ます。development/importMavenで取り込んだartifactをGradleの依存グラフと比較し、google()やmavenCentral()へ偶然フォールバックしていないCIで実行します。公開APIを変更するActivity、Room、Lifecycleの例では、既存テストに加えてbinary compatibilityの差を確認します。OWNERSに沿ってレビュアーを選び、git logで変更履歴を読み、repo upload後のr.android.comにテスト結果とIssue番号を結び付けます。AOSPのframeworks/supportとの同期点も明記し、Apache-2.0依存物の通知をリリース資料へ含めます。

レビューに必要な証跡を揃える

対象moduleのIssue Tracker報告、OWNERS、テストを先に固定し、バグ修正の回帰テストを追加します。prebuilts/androidx/internalとexternalを変更した場合はimportMavenの結果とCIの依存解決を比較します。git logでレビュアーを選び、repo upload、r.android.com、テストログ、Apache-2.0通知を一つの変更記録へまとめます。実施記録には対象版と入力条件を残し、成功した結果だけでなく失敗した場合の出力も保存します。設定を変更した前後で同じ確認を繰り返せるようにし、READMEに書かれた機能と自分の環境で確認できた事実を分けます。採用判断では、導入できたかだけでなく、更新、障害、切り戻し、権限、ライセンスを同じ担当者が追跡できるかを確かめます。 新機能を提案する場合は、承認済みのfeature request bugがあるかを確認します。綴りや文書変更でも対象moduleのCIを通し、prebuiltsの差分が不要なら変更に含めません。

編集部の結論

AndroidXのライブラリ自体を修正したい開発者には、提出要件とレビュー経路を確認する一次資料です。利用者が通常のアプリ依存を追加する場所ではないため、作業前に対象モジュールを絞り、対応テストを実行し、repo upload後のレビューとライセンス条件を個別に確認してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository