Android 2.1 互換性定義

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

1. はじめに

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

原文における「must」（しなければならない）、「must not」（してはならない）、「required」（要求される）、「shall」（するものとする）、「shall not」（しないものとする）、「should」（すべきである）、「should not」（すべきではない）、「recommended」（推奨される）、「may」（しても構わない）「optional」（任意）の使用は、RFC2119 [参考資料、1] で定義されている IETF 規格に従います。

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

Android 2.1 に対応しているとみなされるデバイス実装の条件は以下のとおりです。

  • この互換性定義に示された要件（参照により盛り込まれたドキュメントを含む）を満たさなければなりません。
  • デバイス実装のソフトウェアが完成した時点で利用可能な最新バージョンの 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/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.1 で許可されているバージョン文字列: http://source.android.com/docs/compatibility/2.1/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. AppWidgets: 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. 複数画面のサポート: http://developer.android.com/guide/practices/screens_support.html
  24. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  25. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  26. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
  27. センサー座標空間: http://developer.android.com/reference/android/hardware/SensorEvent.html
  28. Android のセキュリティと権限に関するリファレンス: http://developer.android.com/guide/topics/security/security.html
  29. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

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

3. ソフトウェア

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

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

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

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

3.2. ソフト API の互換性

セクション 3.1 のマネージド API に加えて、Android には、アプリのコンパイル時には適用できない、Android アプリのインテントや権限などの形式で、重要なランタイム専用の「ソフト」API も含まれています。このセクションでは、Android 2.1 との互換性に必要な「ソフト」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.1 の場合、このフィールドには整数値 7 を指定しなければなりません。
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.1-update1/ERC77/3359:userdebug/test-keys
フィンガープリントにスペースを含めてはなりません。上記のテンプレートに含まれる他のフィールドにスペースがある場合、フィンガープリントでは ASCII アンダースコア（_）で置き換えるべきです。
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 は拡張可能なプラットフォームであるため、デバイス実装者は、コア システムアプリで定義されている各インテント パターンをサードパーティ アプリでオーバーライドできるようにしなければなりません。アップストリームの Android オープンソース プロジェクトでは、デフォルトでこれが可能です。デバイス実装者は、システムアプリがこれらのインテント パターンを使用することに対し特別な権限を付与したり、サードパーティ アプリがこれらのパターンにバインドして制御を引き受けることを妨げたりしてはなりません。これによって禁止される行為には、たとえば同じインテント パターンを処理する複数のアプリからユーザーが選択することを許可する「選択的」ユーザー インターフェースを無効にすることが含まれますが、これに限定されません。

注: このセクションは Erratum EX6580 によって変更されました。

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. ウェブ API の互換性

多くのデベロッパーとアプリは、ユーザー インターフェースに関して android.webkit.WebView クラス [参考資料、8] の動作に依存しているため、WebView の実装に Android 実装間での互換性がなければなりません。Android オープンソース実装では、WebKit レンダリング エンジンを使用して WebView を実装します。

ウェブブラウザの包括的なテストスイートを開発することは現実的でないため、デバイス実装者は WebView 実装に WebKit の特定のアップストリーム ビルドを使用しなければなりません。詳細は以下のとおりです。

  • WebView は、Android 2.1 用のアップストリームの Android オープンソース ツリーにある 530.17 WebKit ビルドを使用しなければなりません。このビルドには、WebView の特定の機能セットとセキュリティ修正が含まれています。
  • WebView がレポートするユーザー エージェント文字列は、次の形式でなければなりません。
    Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17
    • $(VERSION) 文字列の値は、android.os.Build.VERSION.RELEASE の値と同じでなければなりません。
    • $(LOCALE) 文字列の値は、国コードと言語に関する ISO 規則に従うべきであり、デバイスの現在構成されているロケールを参照すべきです。
    • $(MODEL) 文字列の値は、android.os.Build.MODEL の値と同じでなければなりません。
    • $(BUILD) 文字列の値は、android.os.Build.ID の値と同じでなければなりません。

実装は、スタンドアロン ブラウザアプリでカスタムのユーザー エージェント文字列を送信しても構いません。さらに、スタンドアロン ブラウザは、代替ブラウザ テクノロジー（Firefox、Opera など）をベースとしていても構いません。ただし、代替ブラウザアプリを使用する場合でも、サードパーティ アプリに提供する WebView コンポーネントは、先述のとおり WebKit をベースとしなければなりません。

WebView の構成には、HTML5 データベース、アプリ キャッシュ、位置情報 API のサポートが含まれなければなりません [参考資料、9]。WebView には、なんらかの形式で HTML5 <video> タグのサポートが含まれていなければなりません。スタンドアロン ブラウザアプリ（アップストリームの WebKit ブラウザアプリをベースとするか、サードパーティの代替アプリをベースとするかにかかわらず）には、WebView 向けにリストされたものと同じ HTML5 機能のサポートが含まれていなければなりません。

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]

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

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

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

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

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

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

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

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

デバイス実装は、次のマルチメディア コーデックをサポートしなければなりません。以下のコーデックはすべて、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）ファイル

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

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.1 対応デバイスでサポートしなければならないハードウェア機能をまとめています。

サードパーティ デベロッパー向けの対応する 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) メソッドを介して正確なハードウェア構成情報を正確にレポートしなければなりません。

8.1. ディスプレイ

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

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

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

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

8.1.3. ディスプレイの指標

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

8.2. キーボード

デバイス実装は:

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

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

デバイス実装は:

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

8.4. 画面の向き

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

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

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

デバイス実装は:

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

8.6. USB

デバイス実装は:

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

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.1 SDK のドキュメント [参考資料、26] に含まれる Camera API を完全に実装しなければなりません。つまり、オートフォーカスのないカメラであっても、（オートフォーカスのないカメラには関係がなくとも）登録された android.hardware.Camera.AutoFocusCallback インスタンスを呼び出さなければなりません。

デバイス実装は、基盤となるハードウェアがこの機能をサポートしている場合、android.hardware.Camera.Parameters クラスの定数として定義された各パラメータ名を認識し、尊重しなければなりません。デバイス ハードウェアが機能をサポートしていない場合、API はドキュメントに記載されているとおりに動作する必要があります。逆に、デバイス実装は android.hardware.Camera.Parameters で定数として記述されているもの以外の、android.hardware.Camera.setParameters() メソッドに渡された文字列定数を尊重および認識してはなりません（ただし、定数の先頭にデバイス実装者の名前を示す文字列接頭辞が付加されている場合を除く）。つまりデバイス実装は、ハードウェアが許すならば標準的なカメラ パラメータをすべてサポートしなければならず、文字列接頭辞によって非標準であることがパラメータ名で明示的に示されていない限り、カスタムのカメラ パラメータ タイプをサポートしてはなりません。

8.10. 加速度計

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

8.11. コンパス

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

8.12. GPS

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

8.13. 電話

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

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

8.14. メモリとストレージ

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

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

注: このセクションは Erratum EX6580 によって変更されました。

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 以上でなければならず、/sdcard にマウントされなければなりません（/sdcard は、物理的なロケーション以外にマウントされる場合、物理的なロケーションへのシンボリック リンクでなければなりません）。

注: このセクションは Erratum EX6580 によって追加されました。

8.16. Bluetooth

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

注: このセクションは Erratum EX6580 によって追加されました。

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

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

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

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

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

10.1. 権限

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

10.2. UID とプロセスの分離

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

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

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

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

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

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

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

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

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

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

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

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

13. お問い合わせ

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