このドキュメントには、Android オープンソース プラットフォーム（AOSP）に関する一般的な質問への回答が記載されています。
android-latest-release について
aosp-main に送信できないのはなぜですか？
aosp-main は読み取り専用になっているため、aosp-main に送信することはできません。
AOSP の変更を提案するにはどうすればよいですか？
新しい変更は、android-latest-release（Repo を使用している場合）または android-latest-release マニフェストで指定された最新のリリース ブランチ（Git を直接使用している場合）に提案する必要があります。他のブランチ（aosp-main など）の既存の提案された変更を移動する必要はありません。
どのブランチに同期すればよいですか？
Repo を使用する場合は、次のコマンドを使用して
android-latest-releaseと同期します。repo init --partial-clone --no-use-superproject -b android-latest-release -u https://android.googlesource.com/platform/manifestGit を直接使用する場合は、
android-latest-releaseマニフェストで指定されたデフォルトのリビジョン ブランチに同期します。
ブランチの同期の詳細については、Repo クライアントの初期化をご覧ください。
android-latest-release のコードは aosp-main に統合されますか？
いいえ。コードは aosp-main にマージされません。aosp-main は 2025 年 3 月 27 日時点で読み取り専用ブランチです。
次のリリースのコードはどこに push されますか？
Google は、次のリリースのコードを最新の公開リリース ブランチに push し、そのブランチを参照するように android-latest-release マニフェストを更新します。
変更リクエストは、android-latest-release ブランチから内部 Gerrit に cherry-pick されますか？
提案された変更をアップロードすると、Google が確認し、承認された場合は内部 Gerrit にチェリーピックされます。
変更リクエストが承認されたかどうかを確認するにはどうすればよいですか？
承認され、チェリーピックされた変更は、Android ホストのリリース ブランチへの今後の push に表示され、android-latest-release を使用してリポジトリと同期できます。提案された変更が承認または拒否されたときの通知メカニズムはありません。
外部コントリビューターが変更を提案してから、最新のリリース ブランチにマージされるまでの一般的なワークフローはどのようなものですか？
外部コントリビューターが
android-latest-release（Repo を使用している場合）またはandroid-latest-releaseマニフェストで指定された最新のリリース ブランチ（Git を直接使用している場合）への変更を提案します。Google が変更を確認します。変更が次のいずれかの場合:
承認されると、Google はその変更をチェリーピックして内部開発ブランチにマージします。
承認されません。Google は変更を抜粋して採用することはありません。
外部コントリビューターは
android-latest-releaseで変更を確認します。
提案した変更が不要になった場合はどうすればよいですか？
提案された変更が不要になった場合、変更を統合したくない場合、または Google がすでに変更を確認していることがわかっている場合は、変更を破棄して Android ホストの提案された変更履歴に残します。
オープンソースに関する質問
Android ソースコードを公開したのはなぜですか？
Google は、モバイルアプリの立ち上げに関する経験を基に、AOSP を開始しました。当時求められていたのは、携帯通信会社、OEM、デベロッパーが革新的なアイデアを実現するために利用できるオープン プラットフォームです。また、業界の特定のプレーヤーが他のプレーヤーのイノベーションを制限したり、妨げたりすることがないように、一極集中を避ける必要もありました。つまり、AOSP の最も重要な目標は、オープンソース Android ソフトウェアの実装において多様性と互換性を可能な限り高め、誰もがメリットを得られるようにすることです。
Android は、どのような種類のオープンソース プロジェクトですか？
Google は、AOSP の中核部分の開発を担当しつつ、デベロッパーやユーザーの活発なコミュニティの構築を支援しています。Android ソースコードの大部分はコピーレフト ライセンスではなく、Apache License 2.0 のパーミッシブ ライセンスで提供されています。Android ソフトウェアの普及促進につながると考え、Apache 2.0 のライセンスを選択しました。詳細については、ライセンスをご覧ください。
Google が Android に取り組むのはなぜですか？
ソフトウェア プラットフォームの立ち上げには、さまざまな要素が関係します。長期的な成功を納めるにはプラットフォームがオープンであることが不可欠です。オープンであるからこそ、デベロッパーの投資を引き付け、高い水準の環境を維持することができます。また、プラットフォームはユーザーにとっても魅力的なプロダクトでなければなりません。
Google は、Android がソフトウェア プラットフォームとして優れた競争力を発揮できるように、必要となるプロフェッショナル エンジニア リソースの確保を進めてきました。Android プロジェクトを大規模なプロダクト開発事業として扱い、優れた Android デバイスの製品化に必要なパートナーシップを推進しています。
ユーザーの支持を着実に得ることで、プラットフォームとしての Android、オープンソース プロジェクトとしての Android が充実したものとなるよう取り組んでいます。支持を得られないプロダクトのソースコードを望む人はいないでしょう。
Google の目標は、Android を取り巻くエコシステムを成功させることです。Android のソースコードは公開されており、誰もが自分のニーズに合わせてソフトウェアの編集、配布を行うことができます。
Android プロダクトの開発に関して、Google はどのような方針をとっていますか？
Google は、競争の激しい市場に向けて優れたデバイスをリリースしています。そして、コア プラットフォームにさまざまなイノベーションや機能強化を組み込んで、次期バージョンとして投入します。
具体的には、Android のエンジニアリング チームは、少数の「フラッグシップ」デバイスに焦点を絞って、次期バージョンの Android ソフトウェアを開発し、プロダクトの立ち上げをサポートしています。フラッグシップ デバイスに焦点を絞ることで、プロダクトに関するリスクの多くを軽減でき、多様な OEM コミュニティの発展と、新しい機能を活用した多様なデバイスの開発を促進できます。Android プラットフォームが実際のデバイスに対するニーズに沿って進化していくように、Google はこのような方針を採用しています。
Android ソフトウェアの開発はどのように行われていますか？
Android の各プラットフォーム バージョン（1.5 や 8.1 など）は、オープンソース ツリー内にそれぞれ対応するブランチを持っています。最新のブランチが現在の安定版のブランチ バージョンになります。これは、android-latest-release マニフェストが参照するバージョンです。メーカーがデバイスに移植するのは、このブランチになります。このブランチは常に、リリースに適した状態を維持します。
また Google は、Android プラットフォームの次期バージョンの開発と、フラグシップ デバイスの開発にも取り組んでいます。
Android の一部が非公開で開発されているのはなぜですか？
デバイスの製品化には、通常 1 年以上の期間がかかります。デバイス メーカーはできる限り最新のソフトウェアを搭載したいと考えます。他方、アプリ デベロッパーにとっては、プラットフォームの新バージョンに毎回ついていくのは大変です。どちらのグループも、プロダクトのリリースと最新バージョンの反映のタイミングに苦心することになります。
このような点を踏まえ、コア プラットフォーム API など、Android の次期バージョンの一部については、非公開のブランチで開発を進めています。Android の次期バージョンは、このような API によって構成されます。この方針により、Google は、プラットフォームの次期バージョンを開発しながらも、Android ソースコードの現在の安定版に焦点を集めることができます。これによってデベロッパーや OEM は、進行中の取り組みを気にすることなく、単一のバージョンに集中できます。
ソースコードはいつリリースされますか？
準備が整った段階でリリースされます。ソースコードのリリースは非常に複雑なプロセスです。Android の一部（カーネルなど）はオープンソースで開発されており、その部分のソースコードは常に利用可能です。それ以外の部分は、最初は非公開ツリー内で開発され、次期バージョンのプラットフォームの準備が整った時点でソースコードがリリースされます。
リリースによっては、コア プラットフォーム API の準備が早く進み、デバイスのリリース前にソースコードをリリースすることもあります。ただし、これは例外的です。通常は、バージョンが安定していると見なされ、開発プロセス面でリリースを許容できる状態になった段階で、プラットフォームのソースがリリースされます。
新バージョンの Android ソースコードをリリースする際、どのような手続きを行っていますか？
新バージョンの Android プラットフォームのソースコードをリリースするプロセスは、非常に手間がかかります。まず、デバイスのシステム イメージにソフトウェアを組み込み、さまざまな認証手続きに合格する必要があります。たとえば、スマートフォンを展開する地域の規制当局による認証などが必要になります。また、コードに対して、携帯通信会社によるテストも行われます。これは、ソフトウェアの不具合の検出に役立つため、非常に重要なプロセスです。
リリースに対して規制当局と携帯通信会社から承認が得られると、メーカーはデバイスの量産を開始し、Google はソースコードをリリースします。
量産開始と同時に、Google チームはオープンソース リリースを準備するためにさまざまな取り組みを開始します。たとえば、API の最終的な変更、ドキュメントの更新（認定試験の間に加えられた修正の反映など）、新バージョン用の SDK の準備、プラットフォーム互換性情報の提供などを行います。
そして、Google の法務チームが、コードをオープンソースとしてリリースするための最終的な承認を行います。オープンソース コントリビューターがコントリビューションの知的財産権を証明するために「コントリビューター ライセンス契約」に署名する必要があるのと同様、Google も、コントリビューションに際してソースに問題がないか検証する必要があります。
ソフトウェアのリリース プロセスは通常、量産の開始時期から約 1 か月かかります。そのため、多くの場合ユーザーにデバイスが提供されるのとほぼ同じ時期に、ソースコードのリリースが行われることになります。
AOSP と Android 互換性プログラムはどのような関係ですか？
AOSP は、Android ソフトウェアのメンテナンスと新バージョンの開発を行います。Android ソフトウェアはオープンソースであるため、あらゆる目的に使用でき、たとえば、ソースは同じでも他のデバイスと互換性がないデバイスを開発することもできます。
Android 互換性プログラムは、各デベロッパーが開発するサードパーティ製アプリとの互換性を保持する Android 基本実装を定義することを目的としています。この「Android 互換」の要件を満たしたデバイスは、Google Play などの Android エコシステムに参加できます。互換性要件を満たしていないデバイスは、エコシステムには含まれません。
つまり、Android 互換性プログラムとは、Android 互換デバイスと、Android ソースコードの派生物をただ実行するだけのデバイスとを区別するための仕組みです。Android ソースコードは自由に使用できますが、Android エコシステムに参加するには、Android 互換性プログラムによって「Android 互換デバイスである」と認定される必要があります。
Android に対してコントリビューションを行うにはどのようにすればよいですか？
AOSP では、バグの報告や、Android 用アプリの開発、ソースコードのコントリビューションを受け付けています。
コードのコントリビューションについては制限があります。たとえば、完全な C++ ベース環境など、代替的なアプリケーション API をコントリビューションしようとしても、承認されることはありません。Android では、ART ランタイム環境でアプリを実行することが推奨されているからです。同様に、AOSP のライセンス目標に適合しない GPL ライブラリや LGPL ライブラリなどのコントリビューションも承認されません。
なお、ソースコードのコントリビューションを行おうとする場合は、その前に、Android コミュニティ ページに記載されているチャンネルからご連絡ください。詳細については、コントリビューションを行うをご覧ください。
Android コミッターになるにはどのようにすればよいですか？
AOSP には、コミッターの概念はありません。Google 社員が作成したものを含め、すべてのコントリビューションは、Gerrit と呼ばれるウェブベース システムを経由します。Gerrit は Android エンジニアリング プロセスの一部で、Git のソースコード管理システムと連携して、ソースコード コントリビューションを適切に管理します。
指定された承認者は、提案されたすべての変更を確認して承認する必要があります。通常は Google 社員が承認担当者となり、提出元にかかわらず、提出されたすべての変更案を、同じ承認担当者が担当します。
詳細については、パッチを提出するをご覧ください。