Android 2.2 互換性定義

Copyright © 2010, Google Inc. All rights reserved.
compatibility@android.com

目次

1. はじめに
2. 参考資料
3. ソフトウェア
4. リファレンス ソフトウェアの互換性
5. アプリ パッケージの互換性
6. マルチメディアの互換性
7. デベロッパー ツールの互換性
8. ハードウェアの互換性
9. パフォーマンスの互換性
10. セキュリティ モデルの互換性
11. 互換性テストスイート
12. アップデート可能なソフトウェア
13. お問い合わせ
付録 A - Bluetooth のテスト手順

1. はじめに

このドキュメントでは、スマートフォンが Android 2.2 との互換性を維持するために満たさなければならない要件を列挙しています。

「しなければならない」、「してはならない」、「要求される」、「するものとする」、「しないものとする」、「すべきである」、「すべきではない」、「推奨される」、「しても構わない」、「任意」の使用は、RFC2119 [参考資料、1] で規定されている IETF 標準に従います。

このドキュメントで使用する「デバイス実装者」または「実装者」とは、Android 2.2 を搭載したハードウェア / ソフトウェア ソリューションを開発する人または組織を指します。「デバイス実装」または「実装」とは、そのように開発されたハードウェア / ソフトウェア ソリューションを指します。

Android 2.2 と互換性があると見なされるには、デバイス実装で:

  • この互換性定義に示された要件（参照により盛り込まれたドキュメントを含む）を満たさなければなりません。
  • デバイス実装のソフトウェアが完成した時点で利用可能な最新バージョンの Android 互換性テストスイート（CTS）に合格しなければなりません（CTS は、Android オープンソース プロジェクト [参考資料、2] の一部として公開されています）。CTS は、このドキュメントで説明するコンポーネントの多くをテストしますが、すべてではありません。

この定義または CTS が、言及されていない、曖昧である、または不完全である場合、既存の実装との互換性を確保することはデバイス実装者の責任です。このため、Android オープンソース プロジェクト [参考資料、3] は Android のリファレンス実装であり、優先実装です。デバイス実装者は、Android オープンソース プロジェクトから入手できる「アップストリーム」のソースコードに基づいて実装することが強く推奨されます。一部のコンポーネントは仮に別の実装に置き換えることもできますが、CTS テストの合格が非常に困難になるため、そのような行為は行わないことが強く推奨されます。互換性テストスイートなどを含む標準的な Android 実装との完全な動作互換性を確保することは、実装者の責任です。なお、このドキュメントでは特定のコンポーネントの置き換えと変更が明示的に禁止されています。

2. 参考資料

  1. IETF RFC2119 要件レベル: http://www.ietf.org/rfc/rfc2119.txt
  2. Android 互換性プログラムの概要: http://source.android.com/docs/compatibility/index.html
  3. Android オープンソース プロジェクト: http://source.android.com/
  4. API の定義とドキュメント: http://developer.android.com/reference/packages.html
  5. Android 権限リファレンス: http://developer.android.com/reference/android/Manifest.permission.html
  6. android.os.Build リファレンス: http://developer.android.com/reference/android/os/Build.html
  7. Android 2.2 で許可されているバージョン文字列: http://source.android.com/docs/compatibility/2.2/versions.html
  8. android.webkit.WebView クラス: http://developer.android.com/reference/android/webkit/WebView.html
  9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
  10. Dalvik 仮想マシンの仕様: Android ソースコード（dalvik/docs）で入手可能
  11. AppWidget: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  12. 通知: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
  13. アプリケーション リソース: http://code.google.com/android/reference/available-resources.html
  14. ステータスバー アイコンのスタイルガイド: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
  15. 検索マネージャー: http://developer.android.com/reference/android/app/SearchManager.html
  16. トースト: http://developer.android.com/reference/android/widget/Toast.html
  17. ライブ壁紙: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  18. Android 向けアプリ: http://code.google.com/p/apps-for-android
  19. リファレンス ツールのドキュメント（adb、aapt、ddms）: http://developer.android.com/guide/developing/tools/index.html
  20. Android apk ファイルの説明: http://developer.android.com/guide/topics/fundamentals.html
  21. マニフェスト ファイル: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  22. Monkey テストツール: https://developer.android.com/studio/test/other-testing-tools/monkey
  23. Android のハードウェア機能のリスト: http://developer.android.com/reference/android/content/pm/PackageManager.html
  24. 複数画面のサポート: http://developer.android.com/guide/practices/screens_support.html
  25. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  26. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  27. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
  28. センサー座標空間: http://developer.android.com/reference/android/hardware/SensorEvent.html
  29. Android のセキュリティと権限に関するリファレンス: http://developer.android.com/guide/topics/security/security.html
  30. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

上記の参考資料の多くは、Android 2.2 SDK から直接的または間接的に派生したものであり、その SDK のドキュメントに記載されている情報と機能的にまったく同じです。この互換性定義または互換性テストスイートと SDK ドキュメントの間に相違がある場合、SDK ドキュメントが正式なものであるとみなされます。上記の参考資料に記載されている技術的な詳細情報はすべて、この互換性定義の一部とみなされます。

3. ソフトウェア

Android プラットフォームには、一連のマネージド API、一連のネイティブ API、いわゆる「ソフト」API の本体（インテント システム、ウェブ アプリケーション API など）が含まれています。このセクションでは、互換性に不可欠なハード API とソフト API、およびその他の関連する特定の技術やユーザー インターフェースの動作について詳しく説明します。デバイス実装は、このセクションのすべての要件に準拠しなければなりません。

3.1. マネージド API の互換性

マネージド（Dalvik ベース）実行環境は、Android アプリを実行するための主要な手段です。Android アプリケーション プログラミング インターフェース（API）は、マネージド VM 環境で実行されるアプリに公開される Andoid プラットフォーム インターフェースのセットです。デバイス実装は、Android 2.2 SDK [参考資料、4] で公開されているドキュメント化された API について、すべてのドキュメント化された動作も含めて、API の完全な実装を提供しなければなりません。

デバイス実装は、この互換性定義で特に許可される場合を除き、マネージド API の省略、API インターフェースまたは署名の変更、ドキュメント化された動作からの逸脱、NoOps の組み込みを行ってはなりません。

3.2. ソフト API の互換性

セクション 3.1 のマネージド API に加えて、Android には、アプリのコンパイル時には適用できない、Android アプリのインテントや権限などの形式で、重要なランタイム専用の「ソフト」API も含まれています。このセクションでは、Android 2.2 との互換性に必要な「ソフト」API とシステムの動作について詳しく説明します。デバイス実装は、このセクションに示されている要件をすべて満たさなければなりません。

3.2.1. 権限

デバイス実装者は、権限リファレンス ページ [参考資料、5] に記載されているすべての権限定数をサポートし、適用しなければなりません。なお、セクション 10 に、Android セキュリティ モデルに関連する追加の要件を記載しています。

3.2.2. ビルド パラメータ

Android API には、現在のデバイスを記述するための android.os.Build クラス [参考資料、6] の定数がいくつか含まれています。デバイス実装間で一貫した意味のある値を提供するために、これらの値の形式に関してデバイス実装が従わなければならない追加の制限を下記の表に示します。

パラメータ コメント
android.os.Build.VERSION.RELEASE 現在実行している Android システムのバージョン（人が読める形式）。このフィールドには、[参考資料、7] で定義された文字列値のいずれかを指定しなければなりません。
android.os.Build.VERSION.SDK 現在実行している Android システムのバージョン（サードパーティ アプリのコードからアクセスできる形式）。Android 2.2 の場合、このフィールドには整数値 8 を指定しなければなりません。
android.os.Build.VERSION.INCREMENTAL 現在実行している Android システムの特定のビルドを指定する、デバイス実装者が選択した値（人が読める形式）。この値については、エンドユーザーが利用できる別のビルドに再利用することは回避しなければなりません。このフィールドは主に、ビルドの生成に使用されたビルド番号またはソース管理変更 ID を示すために使用します。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。
android.os.Build.BOARD デバイスで使用される特定の内部ハードウェアを識別する、デバイス実装者が選択した値（人が読める形式）。このフィールドは、デバイスに電力を供給するボードの特定のリビジョンを示すために使用できます。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。
android.os.Build.BRAND デバイスを製作した企業、組織、個人などを識別する、デバイス実装者が選択した値（人が読める形式）。このフィールドは、デバイスを販売した OEM や携帯通信会社を示すために使用します。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。
android.os.Build.DEVICE デバイスの筐体の具体的な構成またはリビジョン（「工業デザイン」と呼ばれることもあります）を識別する、デバイス実装者が選択した値。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。
android.os.Build.FINGERPRINT このビルドを一意に識別する文字列。人が読める程度の形式にすべきです。次のテンプレートに従わなければなりません。
$(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
例:
acme/mydevice/generic/generic:2.2/ERC77/3359:userdebug/test-keys
フィンガープリントは空白文字を含んではなりません。上記のテンプレートに含まれる他のフィールドに空白文字がある場合は、ビルドのフィンガープリントでアンダースコア（_）などの別の文字に置き換えなければなりません。
android.os.Build.HOST ビルドが構築されたホストを一意に識別する文字列（人が読める形式）。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。
android.os.Build.ID 特定のリリースを参照するためにデバイス実装者が選択する識別子（人が読める形式）。このフィールドは android.os.Build.VERSION.INCREMENTAL と同じ内容にできますが、エンドユーザーがソフトウェア ビルドを区別できるような意味のある値にすべきです。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。
android.os.Build.MODEL エンドユーザーが知っているデバイスの名前を含む、デバイス実装者が選択した値。これは、デバイスが販売され、エンドユーザーに購入される際の名前と同じにすべきです。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。
android.os.Build.PRODUCT デバイスの開発名またはコードネームを含む、デバイス実装者が選択した値。人が読める形式でなければなりませんが、必ずしもエンドユーザーに表示することを意図したものではありません。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。
android.os.Build.TAGS ビルドをさらに区別する、デバイス実装者が選択したタグのカンマ区切りのリスト。たとえば「unsigned,debug」です。このフィールドは、null または空の文字列（""）であってはなりませんが、1 つのタグ（release など）は問題ありません。
android.os.Build.TIME ビルドが作成されたときのタイムスタンプを表す値。
android.os.Build.TYPE ビルドのランタイム構成を指定する、デバイス実装者が選択した値。このフィールドには、典型的な 3 つの Android ランタイム構成（user、userdebug、eng）に対応する値のいずれかを指定すべきです。
android.os.Build.USER ビルドを生成したユーザー（または自動ユーザー）の名前またはユーザー ID。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。

3.2.3. インテントの互換性

Android は、インテントを使用してアプリ間の疎結合統合を実現します。このセクションでは、デバイス実装で尊重しなければならないインテント パターンに関連する要件について説明します。「尊重する」とは、デバイス実装者が、一致するインテント フィルタを指定し、指定されたインテント パターンごとに正しい動作をバインドして実装する Android のアクティビティまたはサービスを提供しなければならないことを意味します。

3.2.3.1. コアアプリのインテント

Android のアップストリーム プロジェクトでは、電話アプリ、カレンダー、連絡先、音楽プレーヤーなど、多数のコアアプリを定義しています。デバイス実装者は、これらのアプリを代替バージョンに置き換えても構いません。

ただし、そのような代替バージョンはすべて、アップストリーム プロジェクトが提供するものと同じインテント パターンを尊重しなければなりません。たとえば、デバイスに代替の音楽プレーヤーが含まれている場合でも、サードパーティ アプリによって発行されたインテント パターンを尊重して曲を選択しなくてはなりません。

以下のアプリは、コア Android システムアプリとみなされます。

  • 卓上時計
  • ブラウザ
  • カレンダー
  • 電卓
  • カメラ
  • 連絡先
  • メール
  • ギャラリー
  • グローバル検索
  • ランチャー
  • LivePicker（ライブ壁紙選択アプリ。デバイスがセクション 3.8.5 に従ってライブ壁紙をサポートしていない場合は省略しても構いません）
  • メッセージ（別名「MMS」）
  • 音楽
  • 電話
  • 設定
  • 音声レコーダー

コア Android システムアプリには、「パブリック」とみなされるさまざまな Activity または Service コンポーネントが含まれます。つまり、属性「android:exported」が存在しないか、値が「true」である可能性があります。

デバイス実装は、android:exported 属性の値を「false」に設定することにより非パブリックとしてマークされていない、コア Android システムアプリのいずれかで定義されたすべての Activity または Service で、コア Android システムアプリと同じインテント フィルタ パターンを実装する同じタイプのコンポーネントを含まなければなりません。

つまり、デバイス実装はコア Android システムアプリを置き換えても構いませんが、その場合は、置き換えられる各コア Android システムアプリで定義されたすべてのインテント パターンをサポートしなければなりません。

3.2.3.2. インテントのオーバーライド

Android は拡張可能なプラットフォームであるため、デバイス実装者は、セクション 3.2.3.1 で参照されている各インテント パターンをサードパーティ アプリでオーバーライドできるようにしなければなりません。アップストリームの Android オープンソース プロジェクトでは、デフォルトでこれが可能です。デバイス実装者は、システムアプリがこれらのインテント パターンを使用することに対し特別な権限を付与したり、サードパーティ アプリがこれらのパターンにバインドして制御を引き受けることを妨げたりしてはなりません。これによって禁止される行為には、たとえば同じインテント パターンを処理する複数のアプリからユーザーが選択することを許可する「選択的」ユーザー インターフェースを無効にすることが含まれますが、これに限定されません。

3.2.3.3. インテントの名前空間

デバイス実装者は、android.* 名前空間に、ACTION、CATEGORY、または他のキー文字列を使用して、新しいインテントまたはブロードキャスト インテント パターンを尊重する Android コンポーネントを含めてはなりません。デバイス実装者は、別の組織に属するパッケージ スペースに、ACTION、CATEGORY、または他のキー文字列を使用して、新しいインテントまたはブロードキャスト インテント パターンを尊重する Android コンポーネントを含めてはなりません。デバイス実装者は、セクション 3.2.3.1 に記載されているコアアプリで使用されるインテント パターンのいずれについても変更または拡張してはなりません。

この制約は、セクション 3.6 の Java 言語クラスに指定された制約と同様のものです。

3.2.3.4. ブロードキャスト インテント

サードパーティ アプリは、特定のインテントをブロードキャストしてハードウェアまたはソフトウェア環境の変更を通知する際、プラットフォームに依存します。Android 互換デバイスは、該当するシステム イベントに応じてパブリック ブロードキャスト インテントをブロードキャストしなければなりません。ブロードキャスト インテントについては、SDK のドキュメントに記載されています。

3.3. ネイティブ API の互換性

Dalvik で動作するマネージド コードでは、アプリの .apk ファイルで提供されるネイティブ コードを、該当するデバイス ハードウェア アーキテクチャ向けにコンパイルされた ELF .so ファイルとして呼び出すことができます。デバイス実装は、標準の Java Native Interface（JNI）セマンティクスを使用して、ネイティブ コードを呼び出すためにマネージド環境で動作するコードのサポートを含まなければなりません。次の API は、ネイティブ コードで使用可能でなければなりません。

  • libc（C ライブラリ）
  • libm（math ライブラリ）
  • JNI インターフェース
  • libz（Zlib 圧縮）
  • liblog（Android ロギング）
  • C++ の最小限のサポート
  • 以下で説明する OpenGL のサポート

デバイス実装は、OpenGL ES 1.0 をサポートしなければなりません。ハードウェア アクセラレーションを備えていないデバイスでは、ソフトウェア レンダラを使用して OpenGL ES 1.0 を実装しなければなりません。デバイス実装は、デバイス ハードウェアのサポートの範囲内で最大限に OpenGL ES 1.1 を実装すべきです。OpenGL ES 2.0 の API でハードウェアが妥当なパフォーマンスを発揮できる場合、デバイス実装は OpenGL ES 2.0 の実装を提供すべきです。

これらのライブラリは、Android オープンソース プロジェクトによって Bionic で提供されるバージョンとソース互換（ヘッダー互換）かつバイナリ互換（特定のプロセッサ アーキテクチャ）でなければなりません。Bionic 実装は、GNU C ライブラリなどの他の実装と完全には互換性がないため、デバイス実装者は Android 実装を使用すべきです。これらのライブラリの別の実装を使用する場合、デバイス実装者はヘッダー、バイナリ、動作の互換性を確認しなければなりません。

デバイス実装は、android.os.Build.CPU_ABI API を介して、デバイスがサポートするネイティブ アプリケーション バイナリ インターフェース（ABI）を正確にレポートしなければなりません。ABI は、docs/CPU-ARCH-ABIS.txt ファイルの、Android NDK の最新バージョンで記載されているエントリのいずれかでなければなりません。Android NDK の今後のリリースで、追加の ABI のサポートが導入される可能性があります。

ネイティブ コードの互換性は難しい問題です。非常に重要であるため、デバイス実装者には、互換性を確保するために上記のライブラリのアップストリーム実装を使用することが強く推奨されます。

3.4. ウェブの互換性

多くのデベロッパーとアプリは、ユーザー インターフェースに関して android.webkit.WebView クラス [参考資料、8] の動作に依存しているため、WebView の実装に Android 実装間での互換性がなければなりません。同様に、完全なウェブ エクスペリエンスが Android ユーザー エクスペリエンスの中心です。デバイス実装は、アップストリームの Android ソフトウェアと一致するバージョンの android.webkit.WebView を含まなければならず、下記のとおり、最新の HTML5 対応ブラウザを含まなければなりません。

3.4.1. WebView の互換性

Android オープンソース実装では、WebKit レンダリング エンジンを使用して android.webkit.WebView を実装します。ウェブ レンダリング システムの包括的なテストスイートを開発することは現実的でないため、デバイス実装者は、WebView 実装に WebKit の特定のアップストリーム ビルドを使用しなければなりません。具体的には次のとおりです。

  • デバイス実装の android.webkit.WebView 実装は、Android 2.2 用のアップストリームの Android オープンソース ツリーにある 533.1 WebKit ビルドをベースとしていなければなりません。このビルドには、WebView の特定の機能セットとセキュリティ修正が含まれています。デバイス実装者は WebKit 実装のカスタマイズを含めても構いません。ただし、そのようなカスタマイズで WebView の動作（レンダリング動作など）を変更してはなりません。
  • WebView が報告するユーザー エージェント文字列は、次の形式でなければなりません。
    Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
    • $(VERSION) 文字列の値は、android.os.Build.VERSION.RELEASE の値と同じでなければなりません。
    • $(LOCALE) 文字列の値は、国コードと言語に関する ISO 規則に従うべきであり、デバイスの現在構成されているロケールを参照すべきです。
    • $(MODEL) 文字列の値は、android.os.Build.MODEL の値と同じでなければなりません。
    • $(BUILD) 文字列の値は、android.os.Build.ID の値と同じでなければなりません。

WebView の構成は、HTML5 データベース、アプリ キャッシュ、位置情報 API のサポートを含まなければなりません [参考資料、9]。WebView は、HTML5 の <video> タグのサポートを含まなければなりません。すべての JavaScript API と同様に、HTML5 API は、デベロッパーが通常の Android API を介して明示的に有効にしない限り、WebView でデフォルトで無効にしなければなりません。

3.4.2. ブラウザの互換性

デバイス実装は、一般ユーザーのウェブ ブラウジング用のスタンドアロン ブラウザアプリを含まなければなりません。スタンドアロン ブラウザは、WebKit 以外のブラウザ テクノロジーをベースにするものであっても構いません。ただし、代替ブラウザアプリを使用する場合でも、サードパーティ アプリに提供する android.webkit.WebView コンポーネントは、セクション 3.4.1 に記載されているように、WebKit をベースにするものでなければなりません。

実装は、スタンドアロン ブラウザアプリでカスタムのユーザー エージェント文字列を送信しても構いません。

スタンドアロン ブラウザアプリは（アップストリームの WebKit ブラウザアプリとサードパーティの代替アプリのどちらをベースとしているかにかかわらず）、可能な限り HTML5 [参考資料、9] をサポートすべきです。デバイス実装は少なくとも、スタンドアロンのブラウザアプリで、HTML5 の位置情報、アプリ キャッシュ、データベース API、<video> タグをサポートしなければなりません。

3.5. API 動作の互換性

各 API タイプ（マネージド、ソフト、ネイティブ、ウェブ）の動作は、アップストリームの Android オープンソース プロジェクト [参考資料、3] の優先実装と一貫性がなければなりません。互換性の具体的な内容は次のとおりです。

  • デバイスは、標準的なインテントの動作または意味を変更してはなりません。
  • デバイスは、特定の種類のシステム コンポーネント（Service、Activity、ContentProvider など）のライフサイクルまたはライフサイクル セマンティクスを変更してはなりません。
  • デバイスは、特定の権限のセマンティクスを変更してはなりません。

上記のリストはすべてを網羅しているわけではなく、動作の互換性を確保する責任はデバイス実装者にあります。このため、デバイス実装者は、システムの重要な部分を再実装するのではなく、可能であれば Android オープンソース プロジェクトを介して入手可能なソースコードを使用すべきです。

互換性テストスイート（CTS）は、動作の互換性についてプラットフォームの大部分をテストしますが、すべてではありません。Android オープンソース プロジェクトとの動作の互換性を確保することは、実装者の責任です。

3.6. API 名前空間

Android は、Java プログラミング言語で定義されたパッケージとクラスの名前空間規則に従います。サードパーティ アプリとの互換性を確保するために、デバイス実装者は、次のパッケージ名前空間に対して禁止されている変更（下記参照）を行ってはなりません。

  • java.*
  • javax.*
  • sun.*
  • android.*
  • com.android.*

次の変更は禁止されます。

  • デバイス実装は、メソッド シグネチャかクラス シグネチャを変更することで、またはクラスかクラス フィールドを削除することで、Android プラットフォームで一般公開されている API を変更してはなりません。
  • デバイス実装者は API の基盤となる実装を変更しても構いませんが、その変更は、一般公開されている API の所定の動作と Java 言語シグネチャに影響を及ぼしてはなりません。
  • デバイス実装者は、一般公開されている要素（クラスまたはインターフェース、既存のクラスまたはインターフェースのフィールドまたはメソッドなど）を上記の API に追加してはなりません。

「一般公開されている要素」とは、アップストリームの Android ソースコードの「@hide」マーカーで装飾されていない構成要素です。つまり、デバイス実装者は、上記の名前空間で新しい API を公開したり、既存の API を変更したりしてはなりません。デバイス実装者は内部のみの変更を行っても構いませんが、そのような変更をアドバタイズしたり、別の方法でデベロッパーに公開したりしてはなりません。

デバイス実装者はカスタム API を追加しても構いませんが、そのような API は別の組織が所有または参照している名前空間内に存在してはなりません。たとえば、デバイス実装者は、com.google.* などの名前空間に API を追加してはなりません。これを行えるのは Google のみです。同様に、Google は他社の名前空間に API を追加してはなりません。

デバイス実装者が上記パッケージ名前空間のいずれかの改善（既存の API に便利な新機能を追加する、新しい API を追加するなど）を提案する場合、実装者は source.android.com にアクセスし、サイトに記載されている情報に従って、変更とコードに貢献するプロセスを開始すべきです。

なお、上記の制限は、Java プログラミング言語の標準的な API 命名規則に対応しています。このセクションは、この互換性定義に含めることでそれらの規則を補強し、拘束力を持たせることのみを目的としています。

3.7. 仮想マシンの互換性

デバイス実装は、完全な Dalvik Executable（DEX）バイトコード仕様と Dalvik 仮想マシンのセマンティクスをサポートしなければなりません [参考資料、10]。

画面が中密度または低密度に分類されるデバイス実装は、各アプリに少なくとも 16 MB のメモリを割り当てるように Dalvik を構成しなければなりません。画面が高密度に分類されるデバイス実装は、各アプリに少なくとも 24 MB のメモリを割り当てるように Dalvik を構成しなければなりません。なお、デバイス実装は、これらの数値よりも多くのメモリを割り当てても構いません。

3.8. ユーザー インターフェースの互換性

Android プラットフォームには、デベロッパーがシステム ユーザー インターフェースに接続できるようにするデベロッパー API がいくつか含まれています。デバイス実装は、下記のとおり、開発するカスタム ユーザー インターフェースに標準の UI API を組み込まなければなりません。

3.8.1. ウィジェット

Android は、アプリが「AppWidget」をエンドユーザーに公開できるようにするコンポーネント タイプとそれに対応する API およびライフサイクルを定義しています [参考資料、11]。Android オープンソース リファレンス リリースには、ユーザーがホーム画面から AppWidget を追加、表示、削除できるユーザー インターフェース要素を含むランチャー アプリが含まれています。

デバイス実装者は、リファレンス ランチャー（ホーム画面）に代わるランチャーを使用しても構いません。代替ランチャーは、AppWidget の組み込みのサポートを含むべきであり、ランチャー内で直接 AppWidget を追加、構成、表示、削除するユーザー インターフェース要素を公開すべきです。代替ランチャーは、これらのユーザー インターフェース要素を省略しても構いません。ただしその場合、デバイス実装者は、ユーザーが AppWidget を追加、構成、表示、削除できるように、ランチャーからアクセス可能な別のアプリを提供しなければなりません。

3.8.2. 通知

Android には、デベロッパーが重要なイベントをユーザーに通知 [参考資料、12] するための API が含まれています。デバイス実装者は、定義された通知の各クラスのサポートを提供しなければなりません。具体的には、音、バイブレーション、ライト、ステータスバーです。

さらに、実装は、API [参考資料、13] で提供されるか、ステータスバー / システムバー アイコンのスタイルガイド [参考資料、14] に記載されているすべてのリソース（アイコンやサウンド ファイルなど）を正しくレンダリングしなければなりません。デバイス実装者は、通知について、リファレンス Android オープンソース実装で提供されているものと異なる代替ユーザー エクスペリエンスを提供しても構いません。ただし、そのような代替通知システムは、上記のように既存の通知リソースをサポートしなければなりません。

Android には、デベロッパーがアプリに検索を組み込んでアプリのデータをグローバル システム検索に公開するための API [参考資料、15] が含まれています。一般に、この機能はシステム全体にわたる単一のユーザー インターフェースで構成されており、ユーザーがクエリを入力し、その入力に対して候補を示して結果を表示できるようになっています。Android API を使用すると、デベロッパーは、このインターフェースを再利用して独自のアプリ内で検索を提供でき、共通のグローバル検索ユーザー インターフェースに結果を供給できます。

デバイス実装は、ユーザー入力に応じてリアルタイムで検索候補を表示できるような、システム全体にわたる単一の共有検索ユーザー インターフェースを含まなければなりません。デバイス実装は、デベロッパーがこのユーザー インターフェースを再利用してアプリ内で検索を提供できるような API を実装しなければなりません。デバイス実装は、サードパーティ アプリがグローバル検索モードで実行されたときに検索候補を検索ボックスに追加できるような API を実装しなければなりません。この機能を利用するサードパーティ アプリがインストールされていない場合は、デフォルトの動作として、ウェブ検索エンジンの検索結果と検索候補を表示すべきです。

デバイス実装は、代替の検索ユーザー インターフェースを使用しても構いませんが、任意のアプリが検索フレームワークを呼び出すためにいつでも使用できるハードまたはソフトの専用の検索ボタンを含め、API ドキュメントに記載されている動作をそのボタンに提供すべきです。

3.8.4. トースト

アプリは、「トースト」API（[参考資料、16] で定義）を使用して、短時間で消える短い非モーダル文字列をエンドユーザーに表示できます。デバイス実装は、アプリからエンドユーザーへのトーストを、なんらかの目立つ方法で表示しなければなりません。

3.8.5. ライブ壁紙

Android では、アプリがエンドユーザーに 1 つ以上の「ライブ壁紙」を公開するためのコンポーネント タイプと、対応する API およびライフサイクルを定義しています [参考資料、17]。ライブ壁紙とは、壁紙として他のアプリの背後に表示される、入力機能が制限されたアニメーション、パターン、またはそれらと類似した画像のことです。

ハードウェアは、他のアプリに悪影響を及ぼさず、妥当なフレームレートで、機能に制限なくすべてのライブ壁紙を実行できる場合、ライブ壁紙を確実に実行できるとみなされます。ハードウェアの制限によって、壁紙やアプリがクラッシュする、誤動作する、CPU やバッテリーを過剰に消費する、または許容できない低フレームレートで実行される場合、ハードウェアはライブ壁紙を実行できないとみなされます。たとえば、一部のライブ壁紙は、OpenGL 1.0 または 2.0 コンテキストを使用してコンテンツをレンダリングする場合があります。複数の OpenGL コンテキストをサポートしていないハードウェアでは、OpenGL コンテキストを使用するライブ壁紙が、OpenGL コンテキストを使用する他のアプリと競合する可能性があるため、ライブ壁紙を確実には実行できません。

上記のようにライブ壁紙を確実に実行できるデバイス実装は、ライブ壁紙を実装すべきです。ライブ壁紙を上記のように確実には実行しないと判断されたデバイス実装は、ライブ壁紙を実装してはなりません。

4. リファレンス ソフトウェアの互換性

デバイス実装者は、次のオープンソース アプリを使用して実装の互換性をテストしなければなりません。

  • Calculator（SDK に含まれる）
  • Lunar Lander（SDK に含まれる）
  • 「Android 向けアプリ」アプリ [参考資料、18]
  • Replica Island（Android マーケットで入手可能、OpenGL ES 2.0 でサポートするデバイス実装の場合にのみ必須）

上記の各アプリは、実装が互換性を持つとみなされるように、実装で正しく起動して動作しなければなりません。

さらに、デバイス実装は、各スモークテスト アプリの各メニュー項目（すべてのサブメニューを含む）をテストしなければなりません。

  • ApiDemos（SDK に含まれる）
  • ManualSmokeTests（CTS に含まれる）

上記のアプリの各テストケースは、デバイス実装で正しく動作しなければなりません。

5. アプリ パッケージの互換性

デバイス実装は、公式の Android SDK に含まれる「aapt」ツールによって生成された Android「.apk」ファイルをインストールして実行しなければなりません [参考資料、19]。

デバイス実装は、.apk [参考資料、20]、Android マニフェスト [参考資料、21]、Dalvik バイトコード [参考資料、10] のいずれかの形式を、他の互換デバイスで該当ファイルを正しくインストールおよび実行できなくなるような方法で拡張してはなりません。デバイス実装者は、Dalvik のリファレンス アップストリーム実装と、リファレンス実装のパッケージ管理システムを使用すべきです。

6. マルチメディアの互換性

デバイス実装は、すべてのマルチメディア API を完全に実装しなければなりません。デバイス実装は、下記のすべてのマルチメディア コーデックのサポートを含まなければならず、下記の音声処理ガイドラインを満たすべきです。

6.1. メディア コーデック

デバイス実装は、次のマルチメディア コーデックをサポートしなければなりません。以下のコーデックはすべて、Android オープンソース プロジェクトの推奨 Android 実装でソフトウェア実装として提供されています。

Google もオープン ハンドセット アライアンスも、これらのコーデックがサードパーティの特許の制約を受けないとは表明していないことにご注意ください。オープンソース ソフトウェアまたはシェアウェアを含め、このソースコードをハードウェアまたはソフトウェア製品で使用する場合は、このコードの実装に、関連する特許権者からの特許ライセンスが必要になることがあります。

音声
名前 エンコーダ デコーダ 詳細 ファイル / コンテナの形式
AAC LC/LTP   X 標準ビットレート 160 kbps とサンプリング レート 8～48 kHz の任意の組み合わせのモノラル / ステレオ コンテンツ 3GPP（.3gp）と MPEG-4（.mp4、.m4a）。raw AAC（.aac）に対するサポートなし
HE-AACv1（AAC+）   X
HE-AACv2（Enhanced AAC+）   X
AMR-NB X X 8 kHz でサンプリングされた 4.75～12.2 kbps。 3GPP（.3gp）
AMR-WB   X 16 kHz でサンプリングされた、6.60～23.85 kbps の 9 種類のレート。 3GPP（.3gp）
MP3   X モノラル / ステレオの 8～320 Kbps 固定ビットレート（CBR）または可変ビットレート（VBR） MP3（.mp3）
MIDI   X MIDI タイプ 0 と 1。DLS バージョン 1 と 2。XMF と Mobile XMF。着信音形式 RTTTL/RTX、OTA、iMelody をサポート タイプ 0 と 1（.mid、.xmf、.mxmf）。RTTTL/RTX（.rtttl、.rtx）、OTA（.ota）、iMelody（.imy）
Ogg Vorbis   X   Ogg（.ogg）
PCM   X 8 ビットと 16 ビットのリニア PCM（最大レートはハードウェアの上限値） WAVE（.wav）
画像
JPEG X X ベースラインとプログレッシブ  
GIF   X    
PNG X X    
BMP   X    
動画
H.263 X X   3GPP（.3gp）ファイル
H.264   X   3GPP（.3gp）と MPEG-4（.mp4）ファイル
MPEG-4 シンプル プロファイル   X   3GPP（.3gp）ファイル

上記の表は、ほとんどの動画コーデックの具体的なビットレート要件をリストしているわけではありません。実際には、関連する標準で要件として指定されているビットレートに正確に対応するビットレートを現在のデバイス ハードウェアが必ずしもサポートしていないためです。代わりに、デバイス実装は、仕様で規定されている上限までの、ハードウェアで実現できる最も高いビットレートをサポートすべきです。

6.2. 録音

デバイス実装は、アプリが android.media.AudioRecord API を使用して音声ストリームの記録を開始したとき、以下の各動作で音声をサンプリングして録音すべきです。

  • ノイズ リダクション処理が存在する場合は、無効にすべきです。
  • 自動ゲイン コントロールが存在する場合は、無効にすべきです。
  • デバイスは、ほぼ平坦な振幅周波数特性（具体的には ±3 dB、100 Hz～4,000 Hz）を示すべきです。
  • オーディオ入力感度は、1,000 Hz で音圧レベル（SPL）90 dB の音源が 16 ビットサンプルで RMS 5,000 になるように設定すべきです。
  • PCM 振幅レベルは、マイクでの 90 dB SPL から少なくとも 30 dB（-18 dB～+12 dB）の範囲で入力 SPL の変化を線形的にトラッキングすべきです。
  • 高調波ひずみの合計を、90 dB SPL の入力レベルで 100 Hz～4,000 Hz の 1% 未満にすべきです。

注: 上記の要件は、Android 2.2 では「すべき」と記載されていますが、将来のバージョンの互換性定義では「しなければならない」に変更される予定です。つまり、これらの要件は、Android 2.2 では任意ですが、将来のバージョンでは必須になります。Android 2.2 を搭載した既存または新規のデバイスは、Android 2.2 ではこれらの要件を満たすことが極めて強く推奨されます。そのようにしないと、将来のバージョンにアップグレードした場合に Android の互換性が実現されません。

6.3. オーディオ レイテンシ

オーディオ レイテンシとは、アプリが音声の再生または録音オペレーションをリクエストしてから、デバイス実装が実際にオペレーションを開始するまでの間隔として広く定義されます。アプリのクラスの多くで、サウンド エフェクトや VOIP 通信などのリアルタイム エフェクトを実現するには、レイテンシを短くする必要があります。デバイス実装は、このセクションで概説するオーディオ レイテンシ要件をすべて満たすべきです。

このセクションにおいて:

  • 「コールド出力レイテンシ」とは、アプリケーションがオーディオの再生をリクエストしてから、音声の再生開始（オーディオ システムがアイドル状態で電源がオフになるまでの時間）を指します。
  • 「ウォーム出力レイテンシ」とは、アプリケーションが音声の再生をリクエストしてから音声の再生を開始するまでの間隔として定義され、オーディオ システムが最近使用されたものの、現在アイドル状態（つまり、無音状態）である時間のことを指します。
  • 「連続出力レイテンシ」とは、デバイスが再生中のサンプルを発行してから、スピーカーが現在音声を再生しているときに、スピーカーが対応する音を物理的に再生する間隔を指します。
  • 「コールド入力レイテンシ」とは、アプリが音声録音をリクエストしてから、コールバックを通じて最初のサンプルがアプリに配信されるまでの間隔（オーディオ システムとマイクがアイドル状態で、リクエストの前に電源がオフになるまでの時間）として定義されます。
  • 「連続入力レイテンシ」とは、デバイスが録音モードになっているときに、アンビエント サウンドが発生し、そのサウンドに対応するサンプルがコールバックを通じて録音アプリに提供されるときのことを指します。

上記の定義を使用して、デバイス実装では、以下の各プロパティを示す必要があります。

  • 100 ミリ秒以下のコールド出力レイテンシ
  • 10 ミリ秒以下のウォーム出力レイテンシ
  • 45 ミリ秒以下の連続出力レイテンシ
  • 100 ミリ秒以下のコールド入力レイテンシ
  • 50 ミリ秒以下の連続入力レイテンシ

注: 上記の要件は、Android 2.2 では「すべき」と記載されていますが、将来のバージョンの互換性定義では「しなければならない」に変更される予定です。つまり、これらの要件は、Android 2.2 では任意ですが、将来のバージョンでは必須になります。Android 2.2 を搭載した既存または新規のデバイスは、Android 2.2 ではこれらの要件を満たすことが極めて強く推奨されます。そのようにしないと、将来のバージョンにアップグレードした場合に Android の互換性が実現されません。

7. デベロッパー ツールの互換性

デバイス実装は、Android SDK で提供されている Android デベロッパー ツールをサポートしなければなりません。具体的には、Android 互換デバイスは、以下のものと互換性がなければなりません。

  • Android Debug Bridge（adb）[参考資料、19]
    デバイス実装は、Android SDK に記載されているとおり、adb のすべての機能をサポートしなければなりません。デバイス側の adb デーモンはデフォルトで無効にすべきですが、Android Debug Bridge をオンにするための、ユーザーがアクセス可能なメカニズムがなければなりません。
  • Dalvik Debug Monitor Service（ddms） [参考資料、19]
    デバイス実装は、Android SDK に記載されているとおり、ddms のすべての機能をサポートしなければなりません。ddms は adb を使用するため、上記のとおり ddms のサポートはデフォルトで無効にすべきですが、ユーザーが Android Debug Bridge を有効にした場合は必ずサポートしなければなりません。
  • Monkey [参考資料、22]
    デバイス実装は、Monkey フレームワークを含まなければならず、アプリで使用できるようにしなければなりません。

8. ハードウェアの互換性

Android では、革新的なフォーム ファクタや構成を作成するデバイス実装者をサポートすることが意図されています。また、Android デベロッパーは、すべての Android デバイスに特定のハードウェア、センサー、API があることを想定しています。このセクションでは、すべての Android 2.2 対応デバイスでサポートしなければならないハードウェア機能をまとめています。

サードパーティ デベロッパー向けの対応する API を持つ特定のハードウェア コンポーネントがデバイスに搭載されている場合、デバイス実装は、Android SDK ドキュメントで定義されているように、その API を実装しなければなりません。任意であると明記されているハードウェア コンポーネントを SDK の API が操作し、デバイス実装がそのコンポーネントを備えていない場合:

  • コンポーネントの API のクラス定義が存在しなければなりません。
  • API の動作は、なんらかの合理的な方法で NoOps として実装しなければなりません。
  • API メソッドは、SDK ドキュメントで許可されている場合、null 値を返さなければなりません。
  • API メソッドは、null 値が SDK ドキュメントで許可されていないクラスでは NoOps 実装を返さなければなりません。

これらの要件が適用されるシナリオの典型例は、テレフォニー API です。電話以外のデバイスであっても、これらの API を妥当な NoOps として実装しなければなりません。

デバイス実装は、android.content.pm.PackageManager クラスの getSystemAvailableFeatures() メソッドと hasSystemFeature(String) メソッドを介して正確なハードウェア構成情報を正確にレポートしなければなりません。[参考資料、23]。

8.1. ディスプレイ

Android 2.2 には、サードパーティ アプリがさまざまなハードウェア構成で適切に動作するよう、状況に応じて特定の自動スケーリングと変換オペレーションを行う機能があります [参考資料、24]。このセクションで詳述するように、デバイスはこれらの動作を適切に実装しなければなりません。

以下は、Android 2.2 でサポートされる最も一般的なディスプレイ構成です。

画面タイプ 幅（ピクセル） 高さ（ピクセル） 対角長の範囲（インチ） 画面サイズグループ 画面密度グループ
QVGA 240 320 2.6～3.0 小 低
WQVGA 240 400 3.2～3.5 標準 低
FWQVGA 240 432 3.5～3.8 標準 低
HVGA 320 480 3.0～3.5 標準 中
WVGA 480 800 3.3～4.0 標準 高
FWVGA 480 854 3.5～4.0 標準 高
WVGA 480 800 4.8～5.5 大 中
FWVGA 480 854 5.0～5.8 大 中

上記の標準構成のいずれかに対応するデバイス実装は、android.content.res.Configuration [参考資料、24] クラスを介して、指定された画面サイズをアプリにレポートするように構成しなければなりません。

一部の .apk パッケージには、特定の密度範囲をサポートしているという指定がないマニフェストが含まれています。このようなアプリを実行する場合、次の制約が適用されます。

  • デバイス実装は、密度修飾子のない .apk 内のリソースをデフォルトで「中」（SDK ドキュメントでは「mdpi」と呼ばれます）と解釈しなければなりません。
  • 「低」密度画面で動作する場合、デバイス実装は中 / mdpi アセットを 0.75 倍にスケールダウンしなければなりません。
  • 「高」密度画面で動作する場合、デバイス実装は中 / mdpi アセットを 1.5 倍にスケールアップしなければなりません。
  • デバイス実装は、同一の密度範囲内でアセットをスケーリングしてはならず、これらの倍率を確実に使用し、密度範囲をまたいでアセットをスケーリングしなければなりません。

8.1.2. 標準以外のディスプレイ構成

セクション 8.1.1 に記載されている標準構成のいずれとも一致しないディスプレイ構成では、互換性を保つために別の点を考慮、実施する必要があります。デバイス実装者は、セクション 13 に記載されているとおり Android 互換性チームに連絡し、画面サイズのバケット、密度、スケーリング ファクタの分類を取得しなければなりません。この情報が提供されたら、デバイス実装はそれを指定されたとおりに実装しなければなりません。

なお、一部のディスプレイ構成（非常に大きい画面や非常に小さい画面、特殊なアスペクト比など）は、Android 2.2 と基本的に互換性がありません。そのため、デバイス実装者は開発プロセスのできるだけ早い段階で Android 互換性チームに連絡することをおすすめします。

8.1.3. ディスプレイの指標

デバイス実装は、android.util.DisplayMetrics [参考資料、26] で規定されているすべてのディスプレイ指標について、正しい値をレポートしなければなりません。

8.1.4. 画面のサポートの宣言

アプリは任意で、AndroidManifest.xml ファイルの <supports-screens> 属性を介して、サポートする画面サイズを示します。デバイス実装は、Android SDK ドキュメントに記載されているように、小、中、大の画面についてアプリが表明しているサポートを正しく尊重しなければなりません。

8.2. キーボード

デバイス実装は:

  • developer.android.com に詳述されているように、サードパーティ デベロッパーがソフト キーボードなどの入力管理エンジンを作成できる入力管理フレームワークをサポートしなければなりません。
  • （ハード キーボードが存在するかどうかにかかわらず）少なくとも 1 つのソフト キーボード実装を提供しなければなりません。
  • 追加のソフト キーボード実装を含んでも構いません。
  • ハードウェア キーボードを含んでも構いません。
  • android.content.res.Configuration.keyboard [参考資料、25] で指定された形式（QWERTY または 12 キー）のいずれかと一致しないハードウェア キーボードを含んではなりません。

8.3. タップ以外のナビゲーション

デバイス実装は:

  • タップ以外のナビゲーション オプション（つまり、トラックボール、D-pad、ホイール）を省略しても構いません。
  • android.content.res.Configuration.navigation [参考資料、25] の正しい値をレポートしなければなりません。

8.4. 画面の向き

互換性のあるデバイスは、アプリが画面の向きを動的に横向きまたは縦向きに変更することをサポートしなければなりません。つまりデバイスは、特定の画面の向きに関するアプリからのリクエストを尊重しなければなりません。デバイス実装は、横向きまたは縦向きのいずれかをデフォルトとして選択しても構いません。

デバイスは、android.content.res.Configuration.orientation、android.view.Display.getOrientation()、またはその他の API を介してクエリされた場合は常に、デバイスの現在の画面の向きについて、正しい値をレポートしなければなりません。

8.5. タッチスクリーン入力

デバイス実装は:

  • タッチスクリーンがなければなりません。
  • 静電容量式または抵抗膜式のタッチスクリーンでも構いません。
  • デバイス上の具体的なタッチスクリーンの種類に対応する android.content.res.Configuration [参考資料、25] の値をレポートしなければなりません。
  • タッチスクリーンが複数のポインタをサポートしている場合、完全に独立してトラックされるポインタをサポートすべきです。

8.6. USB

デバイス実装は:

  • 標準の USB-A ポートで USB ホストに接続できる USB クライアントを実装しなければなりません。
  • USB 経由の Android Debug Bridge を実装しなければなりません（セクション 7 を参照）。
  • デバイスに接続されているホストが /sdcard ボリュームの内容にアクセスできるように、USB マスストレージの仕様を実装しなければなりません。
  • デバイス側でマイクロ USB フォーム ファクタを使用すべきです。
  • デバイス側に標準以外のポートを含んでも構いませんが、その場合、カスタムピン配列を標準 USB-A ポートに接続できるケーブルが付属していなければなりません。
  • USB マスストレージ仕様のサポートを実装すべきです（ホスト PC からデバイスのリムーバブル ストレージまたは固定ストレージにアクセスできるようになります）。

8.7. ナビゲーション キー

ホーム機能、メニュー機能、戻る機能は、Android のナビゲーション パラダイムに不可欠です。デバイス実装は、アプリの状態にかかわらず、常にこうした機能をユーザーが利用できるようにしなければなりません。これらの機能は、専用のボタンを介して実装すべきです。ソフトウェア、ジェスチャー、タッチパネルなどを使用して実装しても構いませんが、常にアクセス可能でなければならず、アプリが利用する表示領域を隠したり、干渉したりしてはなりません。

デバイス実装者は専用の検索キーも提供すべきです。デバイス実装者は、通話の送信キーと終了キーを提供しても構いません。

8.8. ワイヤレス データ ネットワーキング

デバイス実装は、ワイヤレス高速データ ネットワークのサポートを含まなければなりません。具体的には、デバイス実装は、200 Kbit/sec 以上の能力を持つ、少なくとも 1 つのワイヤレス データ標準のサポートを含まなければなりません。この要件を満たす技術の例としては、EDGE、HSPA、EV-DO、802.11g などがあります。

Android SDK に API が含まれる特定のモダリティ（つまり Wi-Fi、GSM、CDMA のいずれか）を含むデバイス実装は、その API をサポートしなければなりません。

デバイスは、複数の形式のワイヤレス データ接続を実装しても構いません。デバイスは、有線データ接続（イーサネットなど）を実装しても構いませんが、上記のように少なくとも 1 つの形式のワイヤレス接続を含まなければなりません。

8.9. カメラ

デバイス実装は背面カメラを含まなければなりません。含まれる背面カメラは:

  • 解像度が 2 メガピクセル以上でなければなりません。
  • カメラドライバでハードウェア オートフォーカスまたはソフトウェア オートフォーカスを実装すべきです（アプリ ソフトウェアに対して透過的）。
  • 固定フォーカスまたは EDOF（拡張被写界深度）のハードウェアがあっても構いません。
  • フラッシュを含んでも構いません。カメラがフラッシュを含む場合、android.hardware.Camera.PreviewCallback インスタンスがカメラ プレビュー サーフェスに登録されている間は、アプリが Camera.Parameters オブジェクトの FLASH_MODE_AUTO 属性または FLASH_MODE_ON 属性を有効にすることによってフラッシュを明示的に有効にしていない限り、フラッシュ ランプを点灯してはなりません。なお、この制約は、デバイスの内蔵システム カメラアプリには適用されず、Camera.PreviewCallback を使用するサードパーティ アプリにのみ適用されます。

デバイス実装は、カメラ関連の API のために次の動作を実装しなければなりません。

  1. アプリで android.hardware.Camera.Parameters.setPreviewFormat(int) が一度も呼び出されていない場合、デバイスはアプリのコールバックに提供されるプレビュー データに android.hardware.PixelFormat.YCbCr_420_SP を使用しなければなりません。
  2. アプリが android.hardware.Camera.PreviewCallback インスタンスを登録し、プレビュー形式が YCbCr_420_SP のときに onPreviewFrame() メソッドを呼び出す場合、onPreviewFrame() に渡される byte[] のデータは NV21 エンコード形式でなければなりません（これは、7K ハードウェア ファミリーでネイティブに使用される形式です）。つまり、NV21 がデフォルトでなければなりません。

デバイス実装は、デバイスにハードウェア オートフォーカスなどの機能があるかどうかにかかわらず、Android 2.2 SDK のドキュメント [参考資料、27] に含まれる Camera API を完全に実装しなければなりません。たとえば、オートフォーカスのないカメラは、（オートフォーカスのないカメラには関係がなくとも）登録された android.hardware.Camera.AutoFocusCallback インスタンスを引き続き呼び出さなければなりません。

デバイス実装は、基盤となるハードウェアがこの機能をサポートしている場合、android.hardware.Camera.Parameters クラスの定数として定義された各パラメータ名を認識し、尊重しなければなりません。デバイス ハードウェアが機能をサポートしていない場合、API はドキュメントに記載されているとおりに動作しなければなりません。逆に、デバイス実装は android.hardware.Camera.Parameters で定数として記述されているもの以外の、android.hardware.Camera.setParameters() メソッドに渡された文字列定数を使用または認識してはなりません。つまりデバイス実装は、ハードウェアが許すならば標準的なカメラ パラメータをすべてサポートしなければならず、カスタムのカメラ パラメータ タイプをサポートしてはなりません。

デバイス実装は前面カメラを含んでも構いません。ただし、デバイス実装が前面カメラを含む場合、デバイスに実装されるカメラ API は、デフォルトで前面カメラを使用してはなりません。つまり、Android 2.2 のカメラ API は背面カメラ専用であり、前面カメラが存在する場合、デバイス実装はその API を再利用またはオーバーロードしてはなりません。前面カメラをサポートするためにデバイス実装者が追加したカスタム API は、セクション 3.5 と 3.6 に従わなければなりません。たとえば、前面カメラをサポートするためにカスタム android.hardware.Camera サブクラスまたは Camera.Parameters サブクラスを提供する場合は、セクション 3.5 と 3.6. に記載されているとおり、既存の名前空間に配置してはなりません。なお、前面カメラを含むことによって、デバイスが背面カメラを含むという要件を満たすことはできません。

8.10. 加速度計

デバイス実装は 3 軸加速度計を含まなければならず、50 Hz 以上でイベントを配信できなければなりません。加速度計で使用する座標系は、Android API で詳述されているとおり、Android センサー座標系に準拠しなければなりません（[参考資料、28] を参照）。

8.11. コンパス

デバイス実装は 3 軸コンパスを含まなければならず、10 Hz 以上でイベントを配信できなければなりません。コンパスで使用する座標系は、Android API で明示されているとおり、Android センサー座標系に準拠しなければなりません（[参考資料、28] を参照）。

8.12. GPS

デバイス実装は GPS レシーバーを含まなければならず、GPS ロックオン時間を最小化するために、なんらかの形式の「アシスト GPS」技術を含むべきです。

8.13. 電話

Android 2.2 は、電話ハードウェアを含まないデバイスで使用しても構いません。つまり、Android 2.2 はスマートフォンではないデバイスに対応しています。ただし、デバイス実装に GSM または CDMA の電話が含まれる場合、その技術の API の完全なサポートを実装しなければなりません。電話ハードウェアを含まないデバイス実装は、完全な API を NoOps として実装しなければなりません。

セクション 8.8「ワイヤレス データ ネットワーキング」もご覧ください。

8.14. メモリとストレージ

デバイス実装には、カーネルとユーザー空間で使用できるメモリが少なくとも 92 MB 存在しなければなりません。この 92 MB は、カーネルの制御下にない無線やメモリなどのハードウェア コンポーネント専用のメモリとは別に用意しなければなりません。

デバイス実装には、ユーザーデータに使用できる不揮発性ストレージが少なくとも 150 MB 存在しなければなりません。つまり、/data パーティションは少なくとも 150 MB でなければなりません。

上記の要件を超えて、デバイス実装には、カーネルの制御下にないハードウェア コンポーネント専用のメモリとは別に、カーネルとユーザー空間で使用できるメモリが少なくとも 128 MB 存在すべきです。デバイス実装には、ユーザーデータに使用できる不揮発性ストレージが少なくとも 1 GB 存在すべきです。なお、これらの高い方の要件は、Android の将来のバージョンでハードウェアの最低要件になる予定です。デバイス実装は、今すぐこれらの要件を満たすことが強く推奨されます。そのようにしないと、将来のバージョンの Android との互換性が得られなくなる可能性があります。

8.15. アプリ共有ストレージ

デバイス実装は、アプリ用の共有ストレージを提供しなければなりません。提供される共有ストレージの容量は 2 GB 以上でなければなりません。

デバイス実装は、共有ストレージをデフォルトでマウントして（「すぐに使える」ように）構成しなければなりません。共有ストレージが Linux パス /sdcard にマウントされない場合、デバイスは、/sdcard から実際のマウント ポイントへの Linux シンボリック リンクを含まなければなりません。

デバイス実装は、この共有ストレージに対する android.permission.WRITE_EXTERNAL_STORAGE 権限を、ドキュメントに記載されているとおりに適用しなければなりません。そうしない場合、共有ストレージは、その権限を取得するすべてのアプリから書き込み可能でなければなりません。

デバイス実装は、ユーザーによるアクセスが可能なリムーバブル ストレージ（セキュア デジタル カードなど）のハードウェアを備えていても構いません。あるいは、デバイス実装は、アプリ用の共有ストレージとして内部（取り外し不可能な）ストレージを割り当てても構いません。

使用する共有ストレージの形式に関係なく、セクション 8.6 に記載されているとおり、共有ストレージは USB マスストレージを実装しなければなりません。デバイスをユーザーが使用し始める時点で、共有ストレージは FAT ファイル システムでマウントされていなければなりません。

説明のために 2 つの一般的な例を示します。デバイス実装に共有ストレージ要件を満たす SD カード スロットが含まれる場合、FAT でフォーマットされた 2 GB 以上の SD カードがユーザーに販売されるデバイスに付属しなければならず、デフォルトでマウントされなければなりません。または、デバイス実装が内部固定ストレージを使用してこの要件を満たす場合、そのストレージは 2 GB 以上であって、FAT でフォーマットされ、/sdcard にマウントされなければなりません（/sdcard は、物理的な場所以外にマウントされる場合、物理的な場所へのシンボリック リンクでなければなりません）。

複数の共有ストレージパス（SD カードスロットと共有内部ストレージの両方など）を含むデバイス実装は、メディア スキャナや ContentProvider などのコアアプリを変更して、両方の場所に配置されたファイルを透過的にサポートすべきです。

8.16. Bluetooth

デバイス実装は、Bluetooth トランシーバーを含まなければなりません。デバイス実装は、SDK ドキュメント [参考資料、30] に記載されているとおり、RFCOMM ベースの Bluetooth API を有効にしなければなりません。デバイス実装は、デバイスに応じて、A2DP、AVRCP、OBEX などの関連する Bluetooth プロファイルを実装すべきです。

互換性テストスイートには、Android RFCOMM Bluetooth API の基本的なオペレーションに関するケースが含まれます。ただし、Bluetooth はデバイス間の通信プロトコルであるため、1 台のデバイスで実行される単体テストで完全にテストすることはできません。したがって、デバイス実装は、付録 A に記載されている人間による Bluetooth テスト手順にも合格しなければなりません。

9. パフォーマンスの互換性

Android 互換性プログラムの目標の一つは、ユーザーに一貫したアプリ エクスペリエンスを提供することです。互換性のある実装は、デバイス上でアプリが単に正しく動作するだけでなく、妥当なパフォーマンスと全体的に優れたユーザー エクスペリエンスをアプリが提供できるようにしなければなりません。デバイス実装は、下表で定義されている Android 2.2 対応デバイスの主要なパフォーマンス指標を満たさなければなりません。

指標 パフォーマンスしきい値 コメント
アプリ起動時間 次のアプリは、示された時間内に起動すべきです。
  • ブラウザ: 1,300 ミリ秒未満
  • MMS / SMS: 700 ミリ秒未満
  • 目覚まし時計: 650 ミリ秒未満
 起動時間は、アプリのデフォルト アクティビティの読み込みを完了するまでにかかる合計時間として測定されます。これには、Linux プロセスを開始し、Android パッケージを Dalvik VM に読み込み、onCreate を呼び出すのに要する時間が含まれます。
同時アプリ 複数のアプリが起動されている場合、起動後に実行中のアプリを再起動するまでにかかる時間は、元の起動時間より短くなければなりません。  

10. セキュリティ モデルの互換性

デバイス実装は、Android デベロッパー向けドキュメントに含まれる API のセキュリティと権限に関するリファレンス ドキュメント [参考資料、29] で規定されているとおり、Android プラットフォームのセキュリティ モデルと整合するセキュリティ モデルを実装しなければなりません。デバイス実装は、サードパーティ / 認証局からの追加の許可 / 証明書を必要とせずに、自己署名アプリのインストールをサポートしなければなりません。具体的には、互換性のあるデバイスは、以降のサブセクションに記載されているセキュリティ メカニズムをサポートしなければなりません。

10.1. 権限

デバイス実装は、Android デベロッパー向けドキュメント [参考資料、29] で規定されているとおり、Android 権限モデルをサポートしなければなりません。具体的には、実装は SDK ドキュメントで規定されている各権限を適用しなければならず、どの権限も省略、変更、無視することはできません。実装は、新しい権限 ID 文字列が android.* 名前空間にない場合、権限を追加しても構いません。

10.2. UID とプロセスの分離

デバイス実装は、Android アプリ サンドボックス モデル（各アプリが個別のプロセスで一意の Unix 形式の UID として動作するモデル）をサポートしなければなりません。デバイス実装は、セキュリティと権限に関するリファレンス [参考資料 29] で規定されているようにアプリが適切に署名されて構築されている場合は、同じ Linux ユーザー ID での複数のアプリの実行をサポートしなければなりません。

10.3. ファイルシステムの権限

デバイス実装は、セキュリティと権限に関するリファレンス [参考資料、29] で規定されているとおり、Android ファイル アクセス権限モデルをサポートしなければなりません。

10.4. 代替実行環境

デバイス実装は、Dalvik 仮想マシンまたはネイティブ コード以外のソフトウェアまたは技術を使用してアプリを実行するランタイム環境を含んでも構いません。ただし、このセクションで説明しているように、そのような代替実行環境は、Android セキュリティ モデル、またはインストール済みの Android アプリのセキュリティを侵害してはなりません。

代替ランタイムは、それ自体が Android アプリでなければならず、セクション 10 の他の部分に記載されているとおり、標準の Android セキュリティ モデルに準拠しなければなりません。

代替ランタイムには、<uses-permission> メカニズムを介して、ランタイムの AndroidManifest.xml ファイルでリクエストされていない権限によって保護されたリソースへのアクセス権を付与してはなりません。

代替ランタイムは、システムアプリに限定された Android 権限で保護された機能の利用をアプリに許可してはなりません。

代替ランタイムは、Android サンドボックス モデルに従わなければなりません。詳細は以下のとおりです。

  • 代替ランタイムは、PackageManager を介してアプリを個別の Android サンドボックス（Linux ユーザー ID など）にインストールするべきです。
  • 代替ランタイムは、代替ランタイムを使用するすべてのアプリで共有される単一の Android サンドボックスを提供しても問題ありません。
  • 代替ランタイムと、代替ランタイムを使用するインストール済みのアプリは、共有ユーザー ID と署名証明書の標準的な Android メカニズムを使用する場合を除き、デバイスにインストールされている他のアプリのサンドボックスを再利用してはなりません。
  • 代替ランタイムは、他の Android アプリに対応するサンドボックスで起動されてはならず、そのサンドボックスへのアクセス権を付与する、または付与されることを回避しなければなりません。

代替ランタイムは、スーパーユーザー（root）または他のユーザー ID の特権で起動されてはならず、その特権を付与される、または付与することを回避しなければなりません。

代替ランタイムの .apk ファイルは、デバイス実装のシステム イメージに含まれていても構いませんが、デバイス実装に含まれる他のアプリの署名に使用される鍵とは異なる鍵で署名されなければなりません。

代替ランタイムは、アプリのインストール時に、アプリが使用する Android 権限についてユーザーの同意を取得しなければなりません。つまり、対応する Android 権限があるデバイス リソース（カメラや GPS など）をアプリが利用する必要がある場合、代替ランタイムは、アプリがそのリソースにアクセスできることをユーザーに通知しなければなりません。ランタイム環境がこの方法でアプリの機能を記録しない場合、ランタイム環境は、そのランタイムを使用してアプリをインストールするときに、そのランタイムが持つすべての権限をリストしなければなりません。

11. 互換性テストスイート

デバイス実装は、デバイス上の最終出荷ソフトウェアを使用して、Android オープンソース プロジェクトから入手できる Android 互換性テストスイート（CTS）[参考資料、2] に合格しなければなりません。さらに、デバイス実装者は可能な限り Android オープンソース ツリーのリファレンス実装を使用すべきであり、CTS で不明確な点があった場合やリファレンス ソースコードの一部を再実装する場合に互換性を確保しなければなりません。

CTS は、実際のデバイスで動作するように設計されています。他のソフトウェアと同様に、CTS 自体にもバグが含まれている可能性があります。CTS はこの互換性定義とは別にバージョニングされ、Android 2.2 用に CTS の複数のリビジョンがリリースされる可能性があります。デバイス実装は、デバイス ソフトウェアが完成した時点で利用可能な最新バージョンの CTS に合格しなければなりません。

12. アップデート可能なソフトウェア

デバイス実装は、システム ソフトウェア全体を置き換えるメカニズムを含まなければなりません。このメカニズムは、「ライブ」アップグレードを実施する必要はありません。つまり、デバイスの再起動が必要となっても構いません。

デバイスにプリインストールされているソフトウェア全体を置き換えることができるのであれば、どの方法でも使用できます。たとえば、次のどの方法も、この要件を満たします。

  • 再起動によるオフライン アップデートを伴う無線（OTA）ダウンロード
  • ホスト PC から USB 経由で行う「テザリング」アップデート
  • 再起動による「オフライン」アップデートとリムーバブル ストレージ上のファイルからのアップデート

使用するアップデート メカニズムは、ユーザーデータをワイプせずにアップデートをサポートしなければなりません。なお、アップストリームの Android ソフトウェアには、この要件を満たすアップデート メカニズムが含まれています。

リリース後に、ただし妥当な製品寿命の期間内にデバイス実装でエラーが見つかり、Android 互換性チームとの協議において、サードパーティ アプリの互換性に影響を与えると判断された場合、デバイス実装者は前述のメカニズムによって適用できる、利用可能なソフトウェア アップデートを介してエラーを修正しなければなりません。

13. お問い合わせ

ご不明な点やドキュメントでカバーされていないと思われる問題については、ドキュメントの作成者あてに compatibility@android.com までお問い合わせください。

付録 A - Bluetooth のテスト手順

互換性テストスイートには、Android RFCOMM Bluetooth API の基本的なオペレーションに関するケースが含まれます。ただし、Bluetooth はデバイス間の通信プロトコルであるため、1 台のデバイスで実行される単体テストで完全にテストすることはできません。したがって、デバイス実装は、以下に記載されている人間による Bluetooth テスト手順にも合格しなければなりません。

テスト手順は、Android オープンソース プロジェクト ツリーに含まれている BluetoothChat サンプルアプリに基づいています。この手順では、次の 2 つのデバイスが必要です。

  • テスト対象のソフトウェア ビルドを実行するデバイス実装候補
  • 互換性があることがわかっている別のデバイス実装であって、テスト対象のデバイス実装のモデルであるもの（「既知の正常な」デバイス実装）

以下のテスト手順では、これらのデバイスをそれぞれ「候補」デバイス、「既知の正常な」デバイスと呼んでいます。

設定とインストール

  1. Android ソースコード ツリーの「make samples」を使用して BluetoothChat.apk をビルドします。
  2. 既知の正常なデバイスに BluetoothChat.apk をインストールします。
  3. 候補デバイスに BluetoothChat.apk をインストールします。

アプリによる Bluetooth コントロールのテスト

  1. Bluetooth を無効にした状態で、候補のデバイスで Bluetooth チャットを起動します。
  2. 候補デバイスが Bluetooth をオンにするか、Bluetooth をオンにするよう促すダイアログを表示することを確認します。

ペア設定と通信をテストする

  1. 両方のデバイスで Bluetooth チャットアプリを起動します。
  2. メニューを使用して既知の正常なデバイスを BluetoothChat 内で検出できるようにします。
  3. 候補デバイスで、メニューを使用して BluetoothChat 内から Bluetooth デバイスをスキャンし、既知の正常なデバイスとペア設定します。
  4. 各デバイスから 10 件以上のメッセージを送信し、別のデバイスで正しく受信されたことを確認します。
  5. 両方のデバイスの Bluetooth アプリをホームを押して閉じます。
  6. デバイス設定アプリを使用して、各デバイスとのペア設定を解除します。

逆方向のペア設定と通信をテストする

  1. 両方のデバイスで Bluetooth チャットアプリを起動します。
  2. Bluetooth チャットから候補デバイスを検出可能にします（メニューを使用）。
  3. 既知の正常なデバイスで、メニューを使用して Bluetooth チャット内で Bluetooth デバイスをスキャンし、候補デバイスとペア設定します。
  4. 各デバイスから 10 件のメッセージを送信し、別のデバイスで正しく受信していることを確認します。
  5. [戻る] を繰り返し押してランチャーに移動し、両方のデバイスの Bluetooth チャットアプリを閉じます。

テストの再リリース

  1. 両方のデバイスで Bluetooth チャットアプリを再起動します。
  2. 各デバイスから 10 件のメッセージを送信し、別のデバイスで正しく受信していることを確認します。

注: 上記のテストでは、ホームを使用してテスト セクションを終了するケースと、戻るセクションを使用するケースがあります。これらのテストは冗長ではなく、また任意ではありません。その目的は、アクティビティを明示的に終了した場合に（ユーザーが「戻る」を押して、finish() を呼び出すことで）Bluetooth API とスタックが正しく機能することを確認し、暗黙的にバックグラウンドに送信される（ユーザーがホームを押すことによって）ようにすることです。各テスト シーケンスは、説明のとおりに実行しなければなりません。