Android 2.2 互換性定義

著作権 © 2010、Google Inc. 無断複写・転載を禁じます。
互換性@android.com

目次

1. はじめに

この文書には、携帯電話が Android 2.2 と互換性を持つために満たさなければならない要件が列挙されています。

「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨される」、「してもよい」、および「オプション」の使用は、IETF 標準に従っています。 RFC2119 [参考文献、1 ] で定義されています。

このドキュメントで使用される「デバイス実装者」または「実装者」とは、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 仮想マシンの仕様: dalvik/docs の Android ソース コードで入手可能
11. アプリウィジェット: 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#statusbarstructor
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、およびインテント システムや Web アプリケーション API などのいわゆる「ソフト」API の本体が含まれています。このセクションでは、互換性に不可欠なハード API とソフト API、およびその他の関連する技術およびユーザー インターフェイスの動作について詳しく説明します。デバイス実装は、このセクションのすべての要件に準拠しなければなりません。

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

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

この互換性定義で特に許可されている場合を除き、デバイス実装は、マネージド API を省略したり、API インターフェイスや署名を変更したり、文書化された動作から逸脱したり、no-ops を含めたりしてはなりません。

3.2.ソフト API の互換性

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

3.2.1.権限

デバイス実装者は、パーミッションのリファレンス ページ [参考文献、5 ] に記載されているすべてのパーミッション定数をサポートし、強制しなければなりません (MUST)。セクション 10 には、Android セキュリティ モデルに関連する追加要件がリストされていることに注意してください。

3.2.2.ビルドパラメータ

Android API には、現在のデバイスを記述することを目的としたandroid.os.Buildクラス [ Resources, 6 ] の多数の定数が含まれています。デバイス実装間で一貫した意味のある値を提供するために、以下の表には、デバイス実装が準拠しなければならないこれらの値の形式に関する追加の制限が含まれています。

3.2.3.インテントの互換性

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

3.2.3.1.コアアプリケーションの意図

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

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

次のアプリケーションは、コア Android システム アプリケーションとみなされます。

• 卓上時計
• ブラウザ
• カレンダー
• 電卓
• カメラ
• 連絡先
• Eメール
• ギャラリー
• グローバルサーチ
• ランチャー
• LivePicker (つまり、ライブ壁紙ピッカー アプリケーション。デバイスがライブ壁紙をサポートしていない場合は、セクション 3.8.5 に従って省略できます)。
• メッセージング (別名「MMS」)
• 音楽
• 電話
• 設定
• サウンドレコーダー

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

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

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

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

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

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 で実行されるマネージド コードは、適切なデバイス ハードウェア アーキテクチャ用にコンパイルされた ELF .so ファイルとしてアプリケーションの .apk ファイルで提供されるネイティブ コードを呼び出すことができます。デバイス実装には、標準の Java Native Interface (JNI) セマンティクスを使用して、ネイティブ コードを呼び出すために管理環境で実行されるコードのサポートが含まれなければなりません (MUST)。次の API をネイティブ コードで使用できる必要があります。

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

デバイス実装は OpenGL ES 1.0 をサポートしなければなりません。ハードウェア アクセラレーションを備えていないデバイスは、ソフトウェア レンダラーを使用して OpenGL ES 1.0 を実装する必要があります。デバイス実装は、デバイスのハードウェアがサポートする限りの OpenGL ES 1.1 を実装する必要があります (SHOULD)。ハードウェアがこれらの API で適切なパフォーマンスを発揮できる場合、デバイス実装は OpenGL ES 2.0 の実装を提供する必要があります (SHOULD)。

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

デバイス実装は、 android.os.Build.CPU_ABI API を介して、デバイスによってサポートされるネイティブ アプリケーション バイナリ インターフェイス (ABI) を正確に報告しなければなりません。 ABI は、最新バージョンの Android NDK のファイルdocs/CPU-ARCH-ABIS.txtに文書化されたエントリの 1 つである必要があります。 Android NDK の追加リリースでは、追加の ABI のサポートが導入される可能性があることに注意してください。

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

3.4.ウェブ互換性

多くの開発者とアプリケーションは、ユーザー インターフェイスとしてandroid.webkit.WebViewクラス [ Resources, 8 ] の動作に依存しているため、WebView 実装は Android 実装間で互換性がある必要があります。同様に、完全な Web エクスペリエンスは Android ユーザー エクスペリエンスの中心です。デバイス実装には、上流の Android ソフトウェアと一致するバージョンのandroid.webkit.WebViewが含まれなければなりません (MUST)。また、以下で説明するように、最新の HTML5 対応ブラウザが含まれなければなりません (MUST)。

3.4.1. WebView の互換性

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

• デバイス実装のandroid.webkit.WebView実装は、Android 2.2 のアップストリーム Android オープンソース ツリーからの 533.1 WebKit ビルドに基づいていなければなりません。このビルドには、WebView の特定の機能セットとセキュリティ修正が含まれています。デバイス実装者は、WebKit 実装にカスタマイズを含めることができます (MAY)。ただし、そのようなカスタマイズによって、レンダリング動作を含む 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 規則に従っている必要があり (SHOULD)、デバイスの現在設定されているロケールを参照する必要があります (SHOULD)。
  • $(MODEL) 文字列の値は、 android.os.Build.MODELの値と同じでなければなりません。
  • $(BUILD) 文字列の値は、 android.os.Build.IDの値と同じでなければなりません。

WebView 構成には、HTML5 データベース、アプリケーション キャッシュ、地理位置情報 API のサポートが含まれなければなりません [参考文献、9 ]。 WebView には、HTML5 <video>タグのサポートが含まれている必要があります。 HTML5 API は、すべての JavaScript API と同様、開発者が通常の Android API 経由で明示的に有効にしない限り、WebView ではデフォルトで無効にしなければなりません (MUST)。

3.4.2.ブラウザの互換性

デバイス実装には、一般ユーザーの Web ブラウジング用のスタンドアロン ブラウザ アプリケーションが含まれなければなりません。スタンドアロン ブラウザは、WebKit 以外のブラウザ テクノロジに基づいていてもよい (MAY)。ただし、代替ブラウザ アプリケーションが出荷されている場合でも、セクション 3.4.1 で説明されているように、サードパーティ アプリケーションに提供されるandroid.webkit.WebViewコンポーネントは WebKit に基づいていなければなりません。

実装では、スタンドアロンのブラウザ アプリケーションにカスタム ユーザー エージェント文字列を含めることができます (MAY)。

スタンドアロンのブラウザ アプリケーション (上流の WebKit ブラウザ アプリケーションに基づいているか、サードパーティの代替品に基づいているかに関係なく) には、可能な限り HTML5 のサポートを含めるべきです [参考文献、9 ]。少なくとも、デバイス実装は、HTML5 地理位置情報、アプリケーション キャッシュ、データベース API、およびスタンドアロンのブラウザ アプリケーションの <video> タグをサポートしなければなりません。

3.5. API の動作の互換性

各 API タイプ (マネージド、ソフト、ネイティブ、Web) の動作は、上流の Android オープンソース プロジェクトの推奨実装と一致している必要があります [参考文献、3 ]。互換性のある具体的な領域は次のとおりです。

• デバイスは標準インテントの動作や意味を変更してはなりません
• デバイスは、特定の種類のシステム コンポーネント (サービス、アクティビティ、コンテンツ プロバイダーなど) のライフサイクルまたはライフサイクル セマンティクスを変更してはなりません (MUST NOT)。
• デバイスは特定の権限のセマンティクスを変更してはなりません

上記のリストは包括的なものではなく、動作の互換性を確保する責任はデバイス実装者にあります。このため、デバイス実装者は、システムの重要な部分を再実装するのではなく、可能な限り Android オープンソース プロジェクト経由で入手可能なソース コードを使用する必要があります (SHOULD)。

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

3.6. API 名前空間

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

• ジャバ.*
• javax.*
• 太陽。*
• アンドロイド。*
• com.android.*

禁止されている変更には次のようなものがあります。

• デバイス実装は、メソッドやクラスのシグネチャを変更したり、クラスやクラス フィールドを削除したりして、Android プラットフォーム上で公開されている API を変更してはなりません。
• デバイス実装者は、API の基礎となる実装を変更してもよい (MAY) が、そのような変更は、公開されている API の規定された動作や Java 言語の署名に影響を与えてはなりません (MUST NOT)。
• デバイス実装者は、公開されている要素 (クラスやインターフェイス、既存のクラスやインターフェイスへのフィールドやメソッドなど) を上記の API に追加してはなりません。

「公開要素」とは、アップストリームの Android ソース コード内で「@hide」マーカーで修飾されていない構成要素です。言い換えれば、デバイス実装者は、上記の名前空間で新しい API を公開したり、既存の API を変更したりしてはなりません。デバイス実装者は内部のみの変更を行うことができますが、それらの変更を宣伝したり、開発者に公開したりしてはなりません。

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

デバイス実装者が上記のパッケージ名前空間の 1 つを改善することを提案する場合 (既存の API に有用な新機能を追加する、または新しい API を追加するなど)、実装者はsource.android.com にアクセスし、変更を提供するプロセスを開始する必要があります (SHOULD)。そのサイトの情報によると、コード。

上記の制限は、Java プログラミング言語での API の命名に関する標準規則に対応していることに注意してください。このセクションは単にこれらの規約を強化し、この互換性定義に含めることによって拘束力を持たせることを目的としています。

3.7.仮想マシンの互換性

デバイス実装は、Dalvik Executable (DEX) バイトコード仕様と Dalvik Virtual Machine セマンティクスを完全にサポートしなければなりません [参考文献、10 ]。

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

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

Android プラットフォームには、開発者がシステム ユーザー インターフェイスに接続できるようにするいくつかの開発者 API が含まれています。以下で説明するように、デバイス実装は、開発するカスタム ユーザー インターフェイスにこれらの標準 UI API を組み込む必要があります。

3.8.1.ウィジェット

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

デバイス実装者は、参照ランチャー (つまり、ホーム画面) の代替を置き換えることができます。代替ランチャーには、AppWidget のサポートが組み込まれており、Launcher 内で直接 AppWidget を追加、構成、表示、削除するためのユーザー インターフェイス要素を公開する必要があります (SHOULD)。代替ランチャーは、これらのユーザー インターフェイス要素を省略してもよいです。ただし、これらが省略された場合、デバイス実装者は、ユーザーが AppWidget を追加、構成、表示、削除できるように、Launcher からアクセスできる別のアプリケーションを提供しなければなりません (MUST)。

3.8.2.通知

Android には、開発者が注目すべきイベントをユーザーに通知できる API が含まれています [参考文献、12 ]。デバイス実装者は、そのように定義された通知の各クラスのサポートを提供しなければなりません (MUST)。具体的には、音、振動、ライト、ステータスバーです。

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

3.8.3.検索

Android には、開発者がアプリケーションに検索を組み込み、アプリケーションのデータをグローバル システム検索に公開できるようにする API [参考文献、15 ] が含まれています。一般に、この機能は、ユーザーがクエリを入力し、入力時に提案を表示し、結果を表示できる単一のシステム全体のユーザー インターフェイスで構成されます。 Android API を使用すると、開発者はこのインターフェイスを再利用して独自のアプリ内で検索を提供し、共通のグローバル検索ユーザー インターフェイスに結果を提供できるようになります。

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

デバイス実装は、代替の検索ユーザー インターフェイスを同梱してもよい (MAY) が、API ドキュメントで規定されている動作で、アプリ内でいつでも検索フレームワークを呼び出すために使用できる、ハードまたはソフトの専用検索ボタンを含めるべきです (SHOULD)。

3.8.4.乾杯

アプリケーションは、「トースト」API ([参考文献、16 ] で定義) を使用して、短い非モーダル文字列をエンド ユーザーに表示できます。この文字列は短時間で消えます。デバイス実装は、アプリケーションからエンドユーザーへのトーストを、何らかの視認性の高い方法で表示しなければなりません (MUST)。

3.8.5.ライブ壁紙

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

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

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

4. 参照ソフトウェアの互換性

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

• 電卓（SDKに含まれています）
• ルナーランダー (SDK に含まれています)
• 「Apps for Android」アプリケーション [参考文献、18 ]。
• レプリカ アイランド (Android マーケットで入手可能。OpenGL ES 2.0 をサポートするデバイス実装にのみ必要)

実装が互換性があるとみなされるためには、上記の各アプリが実装上で正しく起動し、動作する必要があります。

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

• ApiDemos (SDK に含まれています)
• ManualSmokeTests (CTS に含まれます)

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

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

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

デバイス実装は、他の互換性のあるデバイス上でのファイルのインストールと正常な実行を妨げるような方法で、.apk [ Resources, 20 ]、Android Manifest [ Resources, 21 ]、または Dalvik バイトコード [ Resources, 10 ] 形式を拡張してはなりません (MUST NOT) 。デバイス実装者は、Dalvik のリファレンス上流実装とリファレンス実装のパッケージ管理システムを使用する必要があります (SHOULD)。

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

デバイス実装は、すべてのマルチメディア API を完全に実装しなければなりません。デバイス実装には、以下に説明するすべてのマルチメディア コーデックのサポートが含まれなければならず、以下に説明するサウンド処理ガイドラインを満たす必要があります。

6.1.メディアコーデック

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

Google も Open Handset Alliance も、これらのコーデックがサードパーティの特許によって妨げられていないことを表明するものではないことに注意してください。このソース コードをハードウェアまたはソフトウェア製品で使用する予定の場合は、オープン ソース ソフトウェアまたはシェアウェアを含むこのコードの実装には、関連する特許所有者からの特許ライセンスが必要になる場合があることに注意してください。

上の表には、ほとんどのビデオ コーデックの特定のビットレート要件がリストされていないことに注意してください。その理由は、実際には、現在のデバイスのハードウェアが、関連する標準で指定されている必要なビットレートに正確にマッピングされるビットレートを必ずしもサポートしていないためです。代わりに、デバイス実装は、仕様で定義された制限まで、ハードウェア上で実用的な最高のビットレートをサポートする必要があります (SHOULD)。

6.2.録音

アプリケーションがandroid.media.AudioRecord API を使用してオーディオ ストリームの録音を開始した場合、デバイス実装は次のそれぞれの動作でオーディオをサンプリングして録音する必要があります。

• ノイズ低減処理が存在する場合、それを無効にする必要があります(SHOULD)。
• 自動ゲイン制御が存在する場合は、無効にする必要があります(SHOULD)。
• デバイスは、ほぼ平坦な振幅対周波数特性を示すべきです。具体的には、100 Hz ～ 4000 Hz で±3 dB
• オーディオ入力感度は、1000 Hz で 90 dB の音響出力レベル (SPL) ソースが 16 ビット サンプルで 5000 の RMS を生成するように設定する必要があります (SHOULD)。
• PCM 振幅レベルは、マイクでの 90 dB SPL に対して、-18 dB から +12 dB までの少なくとも 30 dB の範囲にわたる入力 SPL 変化を線形に追跡する必要があります。
• 全高調波歪みは、90 dB SPL 入力レベルで 100 Hz ～ 4000 Hz で 1% 未満である必要があります。

注:上記の要件は Android 2.2 では「すべきである」と記載されていますが、将来のバージョンの互換性定義ではこれらを「必須」に変更する予定です。つまり、これらの要件は Android 2.2 ではオプションですが、将来のバージョンでは必須になります。 Android 2.2 Android を実行する既存および新規のデバイスは、Android 2.2 でこれらの要件を満たすことが強く推奨されます。そうしないと、将来のバージョンにアップグレードしたときに Android との互換性を確保できなくなります。

6.3.オーディオ遅延

オーディオ遅延は、アプリケーションがオーディオの再生または録音操作を要求してから、デバイス実装が実際に操作を開始するまでの間隔として広義に定義されます。多くのクラスのアプリケーションは、音響効果や VOIP 通信などのリアルタイム効果を実現するために、短い遅延に依存しています。デバイスの実装は、このセクションで概説されているすべてのオーディオ遅延要件を満たしている必要があります。

このセクションの目的:

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

上記の定義を使用すると、デバイス実装は次の各プロパティを示す必要があります。

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

注:上記の要件は Android 2.2 では「すべきである」と記載されていますが、将来のバージョンの互換性定義ではこれらを「必須」に変更する予定です。つまり、これらの要件は Android 2.2 ではオプションですが、将来のバージョンでは必須になります。 Android 2.2 Android を実行する既存および新規のデバイスは、Android 2.2 でこれらの要件を満たすことが強く推奨されます。そうしないと、将来のバージョンにアップグレードしたときに Android との互換性を確保できなくなります。

7. 開発者ツールの互換性

デバイス実装は、Android SDK で提供される Android 開発者ツールをサポートしなければなりません。具体的には、Android 互換デバイスは以下と互換性がなければなりません。

• Android Debug Bridge (adb として知られる) [リソース、19 ]
  デバイス実装は、Android SDK に記載されているすべてのadb関数をサポートしなければなりません。デバイス側のadbデーモンはデフォルトでは非アクティブである必要がありますが、Android デバッグ ブリッジをオンにするためのユーザーがアクセスできるメカニズムがなければなりません。
• Dalvik デバッグ モニター サービス (ddms として知られる) [リソース、19 ]
  デバイス実装は、Android SDK に記載されているすべてのddms機能をサポートしなければなりません。 ddms adbを使用するため、 ddmsのサポートはデフォルトでは非アクティブであるべきです(SHOULD)が、上記のようにユーザーが Android Debug Bridge をアクティブにしたときは常にサポートされなければなりません(MUST)。
• サル[リソース、22 ]
  デバイス実装には、Monkey フレームワークが含まれており、アプリケーションで使用できるようにする必要があります。

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

Android は、革新的なフォーム ファクターと構成を作成するデバイス実装者をサポートすることを目的としています。同時に、Android 開発者は、すべての Android デバイスで特定のハードウェア、センサー、API を期待しています。このセクションでは、すべての Android 2.2 互換デバイスがサポートする必要があるハードウェア機能をリストします。

サードパーティ開発者向けの対応する API を持つ特定のハードウェア コンポーネントがデバイスに含まれている場合、デバイス実装は Android SDK ドキュメントで定義されているようにその API を実装しなければなりません。 SDK の API がオプションとして指定されているハードウェア コンポーネントと対話し、デバイス実装がそのコンポーネントを所有していない場合:

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

これらの要件が適用されるシナリオの典型的な例はテレフォニー API です。電話以外のデバイスであっても、これらの API は合理的な no-ops として実装される必要があります。

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

8.1.画面

Android 2.2 には、サードパーティのアプリケーションがさまざまなハードウェア構成で適切に動作することを保証するために、状況によっては特定の自動スケーリングおよび変換操作を実行する機能が含まれています [参考文献、24 ]。このセクションで詳しく説明するように、デバイスはこれらの動作を適切に実装しなければなりません。

Android 2.2 の場合、最も一般的なディスプレイ構成は次のとおりです。

上記の標準構成のいずれかに対応するデバイス実装は、指定された画面サイズをandroid.content.res.Configuration [ Resources, 24 ] クラス経由でアプリケーションに報告するように構成されなければなりません (MUST)。

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

• デバイス実装は、密度修飾子のない .apk 内のリソースをデフォルトの「medium」(SDK ドキュメントでは「mdpi」として知られています) として解釈しなければなりません (MUST)。
• 「低」密度の画面で動作する場合、デバイス実装は中/MDPI アセットを 0.75 分の 1 にスケールダウンしなければなりません。
• 「高密度」画面で動作する場合、デバイス実装は中/MDPI アセットを 1.5 倍にスケールアップする必要があります。
• デバイス実装は、密度範囲内でアセットをスケーリングしてはならず、密度範囲間で正確にこれらの係数によってアセットをスケーリングしなければなりません。

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

セクション 8.1.1 にリストされている標準構成のいずれにも一致しないディスプレイ構成には、互換性を持たせるために追加の考慮事項と作業が必要です。デバイス実装者は、セクション 13 で説明されているように Android 互換性チームに連絡して、画面サイズのバケット、密度、およびスケーリング係数の分類を取得しなければなりません。この情報が提供された場合、デバイス実装は指定どおりにそれらを実装しなければなりません (MUST)。

一部のディスプレイ構成 (非常に大きい画面または非常に小さい画面、および一部のアスペクト比など) は Android 2.2 と基本的に互換性がないことに注意してください。したがって、デバイス実装者は、開発プロセスのできるだけ早い段階で Android 互換性チームに連絡することをお勧めします。

8.1.3.メトリクスの表示

デバイス実装は、 android.util.DisplayMetrics [参考文献、26 ] で定義されているすべての表示メトリクスの正しい値を報告しなければなりません (MUST)。

8.1.4.宣言された画面サポート

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

8.2.キーボード

デバイスの実装:

• 入力管理フレームワーク (サードパーティ開発者が入力管理エンジン、つまりソフト キーボードを作成できるようにする) のサポートを含める必要があります (詳細は、developer.android.com を参照)。
• 少なくとも 1 つのソフト キーボード実装を提供しなければなりません (ハード キーボードが存在するかどうかに関係なく)
• 追加のソフト キーボード実装が含まれる場合があります
• ハードウェア キーボードが含まれる場合があります
• android.content.res.Configuration.keyboard [ Resources, 25 ] (つまり、QWERTY または 12 キー) で指定された形式のいずれかに一致しないハードウェア キーボードを含めてはなりません。

8.3.非タッチナビゲーション

デバイスの実装:

• 非タッチ ナビゲーション オプションを省略してもよい (つまり、トラックボール、方向パッド、またはホイールを省略してもよい)
• android.content.res.Configuration.navigationの正しい値を報告しなければなりません [参考文献、25 ]

8.4.画面の向き

互換性のあるデバイスは、アプリケーションによる縦向きまたは横向きの画面の向きへの動的な向きをサポートしなければなりません。つまり、デバイスは、特定の画面の向きに対するアプリケーションの要求を尊重する必要があります。デバイス実装は、デフォルトとして縦向きまたは横向きのいずれかを選択してもよい(MAY)。

デバイスは、android.content.res.Configuration.orientation、android.view.Display.getOrientation()、またはその他の API を介してクエリされるたびに、デバイスの現在の向きの正しい値を報告しなければなりません。

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

デバイスの実装:

• タッチスクリーンが必要です
• 容量性タッチスクリーンまたは抵抗性タッチスクリーンのいずれかを搭載する場合があります
• デバイス上の特定のタッチスクリーンのタイプに対応するandroid.content.res.Configuration [ Resources, 25 ] の値を報告しなければなりません。
• タッチスクリーンが複数のポインタをサポートする場合、完全に独立して追跡されるポインタをサポートすべきです(SHOULD)。

8.6. USB

デバイスの実装:

• 標準の USB-A ポートを備えた USB ホストに接続可能な USB クライアントを実装する必要があります
• USB 経由で Android Debug Bridge を実装しなければなりません (セクション 7 で説明)
• デバイスに接続されているホストが /sdcard ボリュームのコンテンツにアクセスできるようにするには、USB 大容量ストレージ仕様を実装しなければなりません
• デバイス側ではマイクロ USB フォームファクタを使用すべきです
• デバイス側に非標準ポートが含まれていてもよいが、その場合は、カスタム ピン配置を標準 USB-A ポートに接続できるケーブルを同梱しなければなりません。
• USB 大容量ストレージ仕様のサポートを実装すべきです (デバイス上のリムーバブルまたは固定ストレージにホスト PC からアクセスできるようにするため)

8.7.ナビゲーションキー

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

デバイス実装者は、専用の検索キーも提供すべきです(SHOULD)。デバイス実装者は、通話の送信キーと終了キーを提供してもよい(MAY)。

8.8。無線データネットワーキング

デバイス実装には、無線高速データ ネットワーキングのサポートが含まれなければなりません。具体的には、デバイス実装には、200Kbit/秒以上の能力を持つ少なくとも 1 つの無線データ規格のサポートが含まれなければなりません (MUST)。この要件を満たすテクノロジーの例には、EDGE、HSPA、EV-DO、802.11g などが含まれます。

デバイス実装に、Android SDK に API (WiFi、GSM、または CDMA) が含まれる特定のモダリティが含まれている場合、実装はその API をサポートしなければなりません (MUST)。

デバイスは、複数の形式の無線データ接続を実装してもよい(MAY)。デバイスは有線データ接続 (イーサネットなど) を実装してもよいですが、上記のように、少なくとも 1 つの形式の無線接続を含めなければなりません (MUST)。

8.9.カメラ

デバイス実装には背面カメラが含まれなければなりません。付属の背面カメラ:

• 少なくとも2メガピクセルの解像度が必要です
• ハードウェア オート フォーカス、またはソフトウェア オート フォーカスをカメラ ドライバーに実装する必要があります (アプリケーション ソフトウェアに対して透過的)。
• 固定焦点または EDOF (拡張被写界深度) ハードウェアを備えている場合があります
• フラッシュが含まれる場合があります。カメラにフラッシュが含まれている場合、android.hardware.Camera.PreviewCallback インスタンスがカメラ プレビュー サーフェスに登録されている間は、アプリケーションがFLASH_MODE_AUTO明示的に有効にしてフラッシュを有効にしていない限り、 FLASH_MODE_ONランプを点灯してはなりません (MUST NOT)。 Camera.Parametersオブジェクト。この制約は、デバイスの組み込みシステム カメラ アプリケーションには適用されず、 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 ] に含まれる完全なカメラ API を実装しなければなりません。たとえば、オートフォーカスを備えていないカメラは、登録されているandroid.hardware.Camera.AutoFocusCallbackインスタンスを呼び出さなければなりません (これはオートフォーカス以外のカメラには関係ありませんが)。

デバイス実装は、基盤となるハードウェアがその機能をサポートしている場合、 android.hardware.Camera.Parametersクラスの定数として定義された各パラメータ名を認識し、尊重しなければなりません (MUST)。デバイスのハードウェアが機能をサポートしていない場合、API は文書に従って動作する必要があります。逆に、デバイス実装は、 android.hardware.Camera.Parameters の定数として文書化されているもの以外の、 android.hardware.Camera.Parameters android.hardware.Camera.setParameters()メソッドに渡される文字列定数を尊重または認識してはなりません (MUST NOT)。つまり、デバイス実装は、ハードウェアが許可する場合はすべての標準カメラ パラメータをサポートしなければならず、カスタム カメラ パラメータ タイプをサポートしてはなりません。

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

8.10。加速度計

デバイス実装には 3 軸加速度計が含まれなければならず、50 Hz 以上でイベントを配信できなければなりません。加速度計で使用される座標系は、Android API で詳しく説明されているように、Android センサーの座標系に準拠しなければなりません ([参考文献、28 ] を参照)。

8.11。方位磁針

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

8.12 GPS

デバイス実装には GPS 受信機が含まれなければならず (MUST)、GPS ロックオン時間を最小限に抑えるために何らかの形式の「アシスト GPS」技術を含めるべきです (SHOULD)。

8.13。電話

Android 2.2 は、テレフォニー ハードウェアを含まないデバイスで使用できます。つまり、Android 2.2 は電話以外のデバイスと互換性があります。ただし、デバイス実装に GSM または CDMA 電話が含まれる場合は、そのテクノロジーの API の完全なサポートを実装しなければなりません。テレフォニー ハードウェアを含まないデバイス実装は、完全な API を no-ops として実装しなければなりません (MUST)。

セクション 8.8「ワイヤレス データ ネットワーク」も参照してください。

8.14。メモリとストレージ

デバイス実装には、カーネルとユーザー空間で使用できる少なくとも 92MB のメモリが必要です。 92MB は、カーネルの制御下にない無線、メモリなどのハードウェア コンポーネント専用のメモリに追加する必要があります。

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

上記の要件に加えて、デバイス実装には、カーネルの制御下にないハードウェア コンポーネント専用のメモリに加えて、カーネルとユーザー空間で利用可能な少なくとも 128MB のメモリが必要です (SHOULD)。デバイス実装には、ユーザー データに使用できる少なくとも 1 GB の不揮発性ストレージが必要です。これらのより高い要件は、Android の将来のバージョンではハードミニマムとなる予定であることに注意してください。デバイス実装は、現時点でこれらの要件を満たすことを強くお勧めします。満たさないと、Android の将来のバージョンとの互換性が得られなくなる可能性があります。

8.15。アプリケーション共有ストレージ

デバイス実装は、アプリケーションに共有ストレージを提供しなければなりません。提供される共有ストレージのサイズは少なくとも 2GB である必要があります。

デバイス実装は、「すぐに使える」デフォルトでマウントされた共有ストレージを使用して構成する必要があります。共有ストレージがLinux Path /sdcardにマウントされていない場合、デバイスには/sdcardから実際のマウントポイントへのLinuxシンボリックリンクを含める必要があります。

デバイスの実装は、 android.permission.WRITE_EXTERNAL_STORAGE許可を文書化したように、この共有ストレージの許可を強制する必要があります。それ以外の場合、共有ストレージは、その許可を取得するアプリケーションによって書かれている必要があります。

デバイスの実装には、安全なデジタルカードなど、ユーザーアクセス可能な取り外し可能なストレージ用のハードウェアがあります。あるいは、デバイスの実装は、アプリの共有ストレージとして内部（除外性のない）ストレージを割り当てる場合があります。

使用される共有ストレージの形式に関係なく、セクション8.6で説明されているように、共有ストレージはUSB大量ストレージを実装する必要があります。箱から出荷されると、共有ストレージはFATファイルシステムに取り付けなければなりません。

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

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

8.16。ブルートゥース

デバイスの実装には、Bluetoothトランシーバーを含める必要があります。デバイスの実装では、SDKドキュメント[リソース、30 ]で説明されているように、RFCOMMベースのBluetooth APIを有効にする必要があります。デバイスの実装は、デバイスに適しているように、A2DP、AVRCP、OBEXなどの関連するBluetoothプロファイルを実装する必要があります。

互換性テストスイートには、Android RFComm Bluetooth APIの基本的な操作をカバーするケースが含まれています。ただし、Bluetoothはデバイス間の通信プロトコルであるため、単一のデバイスで実行されているユニットテストでは完全にテストすることはできません。したがって、デバイスの実装は、付録Aで説明した人間駆動のBluetoothテスト手順にも合格する必要があります。

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

Android互換性プログラムの目標の1つは、消費者に一貫したアプリケーションエクスペリエンスを可能にすることです。互換性のある実装は、アプリケーションがデバイスで単に正しく実行されるだけでなく、合理的なパフォーマンスと全体的な優れたユーザーエクスペリエンスでそうすることを保証する必要があります。デバイスの実装は、以下の表で定義されているAndroid 2.2互換性のあるデバイスの主要なパフォーマンスメトリックを満たす必要があります。

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

デバイスの実装は、Android開発者ドキュメントのAPI [ Resources、29 ]のセキュリティおよび権限リファレンスドキュメントで定義されているように、Androidプラットフォームセキュリティモデルと一致するセキュリティモデルを実装する必要があります。デバイスの実装は、第三者/当局からの追加の権限/証明書を必要とせずに、自己署名アプリケーションのインストールをサポートする必要があります。具体的には、互換性のあるデバイスは、フォローサブセクションで説明されているセキュリティメカニズムをサポートする必要があります。

10.1.権限

デバイスの実装は、Android開発者のドキュメント[リソース、29 ]で定義されているAndroid Permissions Modelをサポートする必要があります。具体的には、実装は、SDKドキュメントで説明されているように定義された各許可を実施する必要があります。許可は省略、変更、または無視することはできません。新しい許可ID文字列がAndroidにない場合、実装は追加のアクセス許可を追加する場合があります。*名前空間。

10.2. UID とプロセスの分離

デバイスの実装は、各アプリケーションが独自のUNIXスタイルのUIDとして、別のプロセスで実行されるAndroidアプリケーションサンドボックスモデルをサポートする必要があります。デバイスの実装は、セキュリティおよび権限リファレンス[リソース、29 ]で定義されているように、アプリケーションが適切に署名および構築されている場合、同じLinuxユーザーIDとして複数のアプリケーションの実行をサポートする必要があります。

10.3.ファイルシステムのアクセス許可

デバイスの実装は、Androidファイルアクセス許可モデルをサポートする必要があります。これは、セキュリティおよびアクセス許可リファレンス[リソース、29 ]で定義されていると定義されています。

10.4.代替実行環境

デバイスの実装には、Dalvik仮想マシンまたはネイティブコード以外のソフトウェアまたはテクノロジーを使用してアプリケーションを実行するランタイム環境が含まれる場合があります。ただし、このセクションで説明されているように、このような代替実行環境は、AndroidセキュリティモデルやインストールされているAndroidアプリケーションのセキュリティを妥協してはなりません。

セクション10の他の場所で説明されているように、代替ランタイム自体がAndroidアプリケーションであり、標準のAndroidセキュリティモデルを順守する必要があります。

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

代替ランタイムは、システムアプリケーションに制限されたAndroid許可によって保護されている機能を使用することを許可してはなりません。

Android Sandboxモデルには、代替のランタイムが順守する必要があります。具体的には：

• 代替のランタイムは、PackageManagerを介してアプリを個別のAndroidサンドボックス（つまり、LinuxユーザーIDなど）にインストールする必要があります。
• 代替ランタイムは、代替ランタイムを使用してすべてのアプリケーションで共有される単一のAndroidサンドボックスを提供する場合があります。
• 代替ランタイムとインストールされたアプリケーションを使用して、代替ランタイムを使用して、共有ユーザーIDおよび署名証明書の標準的なAndroidメカニズムを除き、デバイスにインストールされている他のアプリのサンドボックスを再利用しないでください
• 代替のランタイムは、他のAndroidアプリケーションに対応するサンドボックスへのアクセスを起動、付与、または許可されてはなりません。

代替のランタイムは、スーパーユーザー（root）または他のユーザーIDの特権を他のアプリケーションで起動、許可、または付与する必要はありません。

代替ランタイムの.apkファイルは、デバイスの実装のシステム画像に含まれる場合がありますが、デバイスの実装に含まれる他のアプリケーションに署名するために使用されるキーとは異なるキーで署名する必要があります。

アプリケーションをインストールする場合、代替の実行タイムは、アプリケーションで使用されているAndroid許可のユーザー同意を取得する必要があります。つまり、アプリケーションが対応するAndroid許可（カメラ、GPなど）があるデバイスリソースを使用する必要がある場合、代替ランタイムは、アプリケーションがそのリソースにアクセスできることをユーザーに通知する必要があります。 。ランタイム環境がこの方法でアプリケーション機能を記録しない場合、ランタイム環境は、そのランタイムを使用してアプリケーションをインストールするときにランタイム自体が保持するすべてのアクセス許可をリストする必要があります。

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

デバイスの実装は、デバイス上の最終配送ソフトウェアを使用して、Androidオープンソースプロジェクトから利用可能なAndroid互換性テストスイート（CTS）[リソース、2 ]に合格する必要があります。さらに、デバイスの実装者は、Androidオープンソースツリーの参照実装を可能な限り使用する必要があり、CTSのあいまいさの場合および参照ソースコードの部分の再実装の互換性を確保する必要があります。

CTSは、実際のデバイスで実行されるように設計されています。他のソフトウェアと同様に、CTS自体にバグが含まれている場合があります。 CTSはこの互換性の定義とは無関係にバージョンされ、CTSの複数の改訂はAndroid 2.2のためにリリースされる場合があります。デバイスの実装は、デバイスソフトウェアが完了したときに利用可能な最新のCTSバージョンに合格する必要があります。

12.更新可能なソフトウェア

デバイスの実装には、システムソフトウェア全体を置き換えるメカニズムを含める必要があります。メカニズムは「ライブ」アップグレードを実行する必要はありません。つまり、デバイスの再起動が必要になる場合があります。

デバイスにプリインストールされたソフトウェア全体を交換できる場合、すべての方法を使用できます。たとえば、次のアプローチのいずれかがこの要件を満たします。

• Over-The-Air（OTA）は、再起動を介してオフラインの更新を備えたダウンロード
• ホストPCからUSBを介した「テザー」アップデート
• 「オフライン」は、取り外し可能なストレージ上のファイルからの再起動と更新を介して更新されます

使用される更新メカニズムは、ユーザーデータを拭かないで更新をサポートする必要があります。上流のAndroidソフトウェアには、この要件を満たす更新メカニズムが含まれていることに注意してください。

リリース後にデバイスの実装でエラーが見つかったが、Android互換性チームと協議してTHID-Partyアプリケーションの互換性に協議して決定される合理的な製品寿命の範囲内で、デバイスの実装者はソフトウェアを介してエラーを修正する必要があります。これまでに説明したメカニズムに従って適用できる更新を利用可能にします。

13. お問い合わせ

Compatibility@android.comのドキュメント著者に連絡して、明確化については、ドキュメントがカバーしていないと思われる問題を提起することができます。

付録A -Bluetoothテスト手順

互換性テストスイートには、Android RFComm Bluetooth APIの基本的な操作をカバーするケースが含まれています。ただし、Bluetoothはデバイス間の通信プロトコルであるため、単一のデバイスで実行されているユニットテストでは完全にテストすることはできません。したがって、デバイスの実装は、以下で説明する人間主導のBluetoothテスト手順にも合格する必要があります。

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

• テストするソフトウェアビルドを実行する候補デバイスの実装
• 互換性があることが既に知られている別のデバイス実装、およびテスト対象のデバイス実装のモデル、つまり「既知の良い」デバイスの実装

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

セットアップとインストール

1. Androidソースコードツリーから「Make Samples」を介してBluetoothchat.apkを構築します。
2. 既知のGoodデバイスにbluetoothchat.apkをインストールします。
3. 候補デバイスにbluetoothchat.apkをインストールします。

アプリによるBluetoothコントロールをテストします

1. Bluetoothが無効になっている間、候補デバイスでBluetoothChatを起動します。
2. 候補デバイスがBluetoothをオンにするか、ユーザーにダイアログを使用してBluetoothをオンにすることを確認します。

ペアリングと通信をテストします

1. 両方のデバイスでBluetoothチャットアプリを起動します。
2. Bluetoothchat内から既知の優れたデバイスを発見できるようにします（メニューを使用）。
3. 候補デバイスでは、BluetoothChat内（メニューを使用）内からBluetoothデバイスをスキャンし、既知のGoodデバイスとペアリングします。
4. 各デバイスから10以上のメッセージを送信し、他のデバイスがそれらを正しく受信していることを確認します。
5. 家を押して、両方のデバイスのBluetoothchatアプリを閉じます。
6. デバイス設定アプリを使用して、各デバイスが他のデバイスから対応しません。

ペアリングと通信を逆方向にテストします

1. 両方のデバイスでBluetoothチャットアプリを起動します。
2. Bluetoothchat内から候補デバイスを発見できるようにします（メニューを使用）。
3. 既知の優れたデバイスでは、BluetoothChat内（メニューを使用）内からBluetoothデバイスをスキャンし、候補デバイスとペアリングします。
4. 各デバイスから10個またはメッセージを送信し、他のデバイスがそれらを正しく受信していることを確認します。
5. 両方のデバイスのBluetoothチャットアプリを閉じて、繰り返し戻してランチャーに到達します。

再起動をテストします

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

注：上記のテストには、ホームを使用してテストセクションを終了する場合があり、一部はバックを使用しています。これらのテストは冗長であり、オプションではありません。目的は、アクティビティが明示的に終了したときにBluetooth APIとスタックが正しく機能していることを確認することです（ユーザーを押すとfinish（）を呼び出します）、そして暗黙的にバックグラウンドに送信されます（ユーザーが家を押します。）各テストシーケンスは、説明どおりに実行する必要があります。