Android 2.3 互換性の定義

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

目次

1. はじめに

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

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

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

Android 2.3 と互換性があるとみなされるには、デバイス実装は、参照によって組み込まれたドキュメントを含め、この互換性定義に示されている要件を満たさなければなりません。

この定義またはセクション 10で説明されているソフトウェア テストが沈黙、曖昧、または不完全である場合、既存の実装との互換性を確保するのはデバイス実装者の責任です。このため、Android オープンソース プロジェクト [参考文献、3 ] は、Android のリファレンスであり、推奨される実装でもあります。デバイス実装者には、Android オープンソース プロジェクトから入手可能な「アップストリーム」ソース コードを可能な限り最大限に基づいて実装することが強く推奨されます。一部のコンポーネントは仮想的に代替実装に置き換えることができますが、ソフトウェア テストに合格することが大幅に困難になるため、この方法は使用しないことを強くお勧めします。互換性テスト スイートを含む、標準の Android 実装との完全な動作互換性を確保するのは実装者の責任です。最後に、特定のコンポーネントの置換や変更はこの文書で明示的に禁止されていることに注意してください。

この互換性定義は、Android の 2.3.3 アップデート (API レベル 10) に対応するために発行されていることに注意してください。この定義は廃止され、2.3.3 より前の Android 2.3 バージョンの互換性定義に置き換わります。 (つまり、バージョン 2.3.1 と 2.3.2 は廃止されています。) Android 2.3 を実行する将来の Android 互換デバイスには、バージョン 2.3.3 以降が搭載されていなければなりません。

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.3 で許可されるバージョン文字列: http://source.android.com/docs/compatibility/2.3/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. HTML5 オフライン機能: http://dev.w3.org/html5/spec/Overview.html#offline
11. HTML5 ビデオタグ: http://dev.w3.org/html5/spec/Overview.html#video
12. HTML5/W3C 地理位置情報 API: http://www.w3.org/TR/geolocation-API/
13. HTML5/W3C ウェブデータベース API: http://www.w3.org/TR/webdatabase/
14. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
15. Dalvik 仮想マシンの仕様: dalvik/docs の Android ソース コードで入手可能
16. アプリウィジェット: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
17. 通知: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
18. アプリケーション リソース: http://code.google.com/android/reference/available-resources.html
19. ステータス バー アイコンのスタイル ガイド: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructor
20. 検索マネージャー: http://developer.android.com/reference/android/app/SearchManager.html
21. トースト: http://developer.android.com/reference/android/widget/Toast.html
22. ライブ壁紙: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
23. リファレンス ツール ドキュメント (adb、aapt、ddms 用): http://developer.android.com/guide/developing/tools/index.html
24. Android APK ファイルの説明: http://developer.android.com/guide/topics/fundamentals.html
25. マニフェスト ファイル: http://developer.android.com/guide/topics/manifest/manifest-intro.html
26. Monkey テストツール: https://developer.android.com/studio/test/other-testing-tools/monkey
27. Android ハードウェア機能リスト: http://developer.android.com/reference/android/content/pm/PackageManager.html
28. 複数の画面のサポート: http://developer.android.com/guide/practices/screens_support.html
29. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
30. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
31. センサー座標空間: http://developer.android.com/reference/android/hardware/SensorEvent.html
32. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html
33. NDEF プッシュ プロトコル: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
34. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
35. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
36. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
37. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
38. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
39. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
40. カメラ方向 API: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
41. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
42. Android のセキュリティと権限のリファレンス: http://developer.android.com/guide/topics/security/security.html
43. Android 用アプリ: http://code.google.com/p/apps-for-android

これらのリソースの多くは Android 2.3 SDK から直接的または間接的に派生しており、機能的にはその SDK のドキュメントの情報と同一です。この互換性定義または互換性テスト スイートが SDK ドキュメントと一致しない場合は、SDK ドキュメントが信頼できるものとみなされます。上記の参考文献に記載されている技術的な詳細は、この互換性定義の一部として含められるものと見なされます。

3. ソフトウェア

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

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

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

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

この互換性定義では、Android に API が含まれる一部のタイプのハードウェアをデバイス実装で省略することが許可されています。このような場合でも、API は依然として存在し、適切な方法で動作する必要があります。このシナリオの具体的な要件については、セクション 7 を参照してください。

3.2.ソフト API の互換性

セクション 3.1 のマネージド API に加えて、Android には、インテント、アクセス許可、およびアプリケーションのコンパイル時に強制できない Android アプリケーションの同様の側面などの形式で、ランタイム専用の重要な「ソフト」API も含まれています。このセクションでは、Android 2.3 との互換性に必要な「ソフト」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メール
• ギャラリー
• グローバルサーチ
• ランチャー
• 音楽
• 設定

コア 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 ファイルで提供されるネイティブ コードを呼び出すことができます。ネイティブ コードは基盤となるプロセッサ テクノロジに大きく依存しているため、Android は Android NDK のファイルdocs/CPU-ARCH-ABIS.txtで多数のアプリケーション バイナリ インターフェイス (ABI) を定義しています。デバイス実装が 1 つ以上の定義された ABI と互換性がある場合、以下のように Android NDK との互換性を実装する必要があります (SHOULD)。

デバイス実装に Android ABI のサポートが含まれている場合、次のようになります。

• 標準の Java Native Interface (JNI) セマンティクスを使用して、ネイティブ コードを呼び出すために管理環境で実行されるコードのサポートを含めなければなりません。
• 以下のリストにある必要なライブラリごとに、ソース互換性 (つまり、ヘッダー互換性) およびバイナリ互換性 (ABI の場合) がなければなりません。
• android.os.Build.CPU_ABI API を介して、デバイスによってサポートされているネイティブ アプリケーション バイナリ インターフェイス (ABI) を正確に報告しなければなりません。
• Android NDK の最新バージョンdocs/CPU-ARCH-ABIS.txtに文書化されている ABI のみを報告しなければなりません (MUST)。
• 上流の Android オープンソース プロジェクトで利用可能なソース コードとヘッダー ファイルを使用してビルドする必要があります (SHOULD)

次のネイティブ コード API は、ネイティブ コードを含むアプリで利用できなければなりません。

• libc (C ライブラリ)
• libm (数学ライブラリ)
• C++ の最小限のサポート
• JNIインターフェース
• liblog (Android ログ)
• libz (Zlib 圧縮)
• libdl (動的リンカー)
• libGLESv1_CM.so (OpenGL ES 1.0)
• libGLESv2.so (OpenGL ES 2.0)
• libEGL.so (ネイティブ OpenGL サーフェス管理)
• libjnigraphics.so
• libOpenSLES.so (オープン サウンド ライブラリのオーディオ サポート)
• libandroid.so (ネイティブ Android アクティビティ サポート)
• 以下で説明する OpenGL のサポート

Android NDK の将来のリリースでは、追加の ABI のサポートが導入される可能性があることに注意してください。デバイス実装が既存の事前定義された ABI と互換性がない場合、ABI のサポートをまったく報告してはなりません (MUST NOT)。

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

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.3 のアップストリーム 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 のサポートを含めるべきです ( SHOULD )。少なくとも、デバイス実装は、WebView の HTML5 に関連付けられた次の API をそれぞれサポートしなければなりません。

• アプリケーションキャッシュ/オフライン操作 [参考文献、10 ]
• <video> タグ [リソース、11 ]
• 地理位置情報 [リソース、12 ]

さらに、デバイス実装は HTML5/W3C Webstorage API [参考文献、13 ] をサポートしなければならず、HTML5/W3C IndexedDB API [参考文献、14 ] をサポートすべきです。 Web 開発標準化団体が WebStorage よりも IndexedDB を優先する方向に移行しているため、IndexedDB は Android の将来のバージョンで必須のコンポーネントになることが予想されます。

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 をそれぞれサポートしなければなりません。

• アプリケーションキャッシュ/オフライン操作 [参考文献、10 ]
• <video> タグ [リソース、11 ]
• 地理位置情報 [リソース、12 ]

さらに、デバイス実装は HTML5/W3C Webstorage API [参考文献、13 ] をサポートしなければならず、HTML5/W3C IndexedDB API [参考文献、14 ] をサポートすべきです。 Web 開発標準化団体が WebStorage よりも IndexedDB を優先する方向に移行しているため、IndexedDB は Android の将来のバージョンで必須のコンポーネントになることが予想されます。

3.5. API の動作の互換性

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

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

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

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 を追加してはなりません。さらに、デバイス実装に標準の Android 名前空間外のカスタム API が含まれている場合、それらの API を Android 共有ライブラリにパッケージ化し、( <uses-library>メカニズム経由で) それらの API を明示的に使用するアプリのみがメモリ使用量の増加の影響を受けるようにする必要があります。そのような API の。

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

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

3.7.仮想マシンの互換性

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

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

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

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

3.8.1.ウィジェット

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

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

3.8.2.通知

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

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

3.8.3.検索

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

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

デバイスの実装では、代替検索ユーザーインターフェイスを発送する場合がありますが、APIドキュメントで提供されている動作を使用して、任意のアプリ内でいつでも使用できるハードまたはソフトの専用検索ボタンを含める必要があります。

3.8.4.乾杯

アプリケーションは、「トースト」API（[リソース、21 ]で定義されている）を使用して、短い期間後に消えるエンドユーザーに短い非モーダル文字列を表示できます。デバイスの実装では、アプリケーションからエンドユーザーへのトーストをいくつかの視認性の高い方法で表示する必要があります。

3.8.5.ライブ壁紙

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

ハードウェアは、他のアプリケーションに悪影響を及ぼさない合理的なフレームレートで、機能に制限がなく、すべてのライブ壁紙を実行できる場合、ライブウォールペーパーを確実に実行できると見なされます。ハードウェアの制限により、壁紙やアプリケーションがクラッシュ、誤動作、過度のCPUまたはバッテリー電源の消費、または容認できないほど低いフレームレートで実行される場合、ハードウェアはライブの壁紙を実行できないと見なされます。例として、一部のライブ壁紙は、オープンGL 1.0または2.0コンテキストを使用してコンテンツをレンダリングする場合があります。 Live Wallpaperは、OpenGLコンテキストのライブ壁紙の使用がOpenGLコンテキストを使用する他のアプリケーションと競合する可能性があるため、複数のOpenGLコンテキストをサポートしないハードウェアで確実に実行されません。

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

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

デバイスの実装は、公式Android SDK [ Resources、23 ]に含まれる「AAPT」ツールによって生成されたAndroid「.APK」ファイルをインストールして実行する必要があります。

デバイスの実装は、.apk [リソース、24 ]、Androidマニフェスト[リソース、25 ]、またはDalvik Bytecode [ Resources、15 ]のいずれかを、他の互換性のあるデバイスにそれらのファイルが正しくインストールおよび実行できないように拡張してはなりません。 。デバイスの実装者は、Dalvikのリファレンスアップストリーム実装と、参照実装のパッケージ管理システムを使用する必要があります。

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

デバイスの実装は、すべてのマルチメディアAPIを完全に実装する必要があります。デバイスの実装には、以下に説明するすべてのマルチメディアコーデックのサポートを含める必要があり、以下のサウンド処理ガイドラインを満たす必要があります。デバイスの実装には、スピーカー、ヘッドフォンジャック、外部スピーカー接続など、少なくとも1つのフォームのオーディオ出力を含める必要があります。

5.1.メディアコーデック

デバイスの実装は、次のセクションで詳述されているように、マルチメディアコーデックをサポートする必要があります。これらのコーデックはすべて、Androidオープンソースプロジェクトからの好ましいAndroid実装のソフトウェア実装として提供されます。

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

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

5.1.1.メディアデコーダー

デバイスの実装には、以下の表に記載されている各コーデックと形式のデコーダーの実装を含める必要があります。これらの各メディアタイプのデコーダーは、上流のAndroidオープンソースプロジェクトによって提供されていることに注意してください。

5.1.2.メディアエンコーダー

デバイスの実装には、セクション5.1.1にリストされている多くのメディア形式のエンコーダーを含める必要があります。できるだけ。ただし、一部のエンコーダーは、特定のオプションのハードウェアがないデバイスについては意味がありません。たとえば、デバイスにカメラがない場合、H.263ビデオのエンコーダーは意味がありません。したがって、デバイスの実装は、以下の表に記載されている条件に従ってメディアエンコーダを実装する必要があります。

デバイスの実装によってハードウェアが省略される可能性のある条件の詳細については、セクション7を参照してください。

上記のエンコーダーに加えて、デバイスの実装にはH.264エンコーダーを含める必要があります。将来のバージョンの互換性の定義は、この要件を「必須」に変更するために計画されていることに注意してください。つまり、H.264エンコーディングはAndroid 2.3ではオプションですが、将来のバージョンでは必要になります。 Android 2.3を実行する既存および新しいデバイスは、Android 2.3でこの要件を満たすことを非常に強く奨励しています。または、将来のバージョンにアップグレードしたときにAndroid互換性を達成することはできません。

5.2.録音

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

• 存在する場合は、ノイズリダースプロセッシングを無効にする必要があります。
• 存在する場合は、自動ゲイン制御を無効にする必要があります。
• デバイスは、周波数特性に対してほぼ平坦な振幅を示す必要があります。具体的には、±3 dB、100 Hzから4000 Hzまで
• オーディオ入力感度は、1000 Hzの90 dBサウンドパワーレベル（SPL）ソースが16ビットサンプルで5000のRMSを生成するように設定する必要があります。
• PCM振幅レベルは、マイクで-18 dBから+12 dB RE 90 dB SPLの少なくとも30 dBの範囲で入力SPLの変化を直線的に追跡する必要があります。
• 総高調波の歪みは、90 dB SPL入力レベルで100 Hzから4000 Hzまで1％未満でなければなりません。

注：上記の要件はAndroid 2.3の「Subls」と述べられていますが、将来のバージョンの互換性の定義は、これらを「必須」に変更することが計画されています。つまり、これらの要件はAndroid 2.3ではオプションですが、将来のバージョンでは必要になります。 Android 2.3を実行する既存および新しいデバイスは、Android 2.3のこれらの要件を満たすことを非常に強く奨励しています。または、将来のバージョンにアップグレードしたときにAndroid互換性を達成することはできません。

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

オーディオレイテンシは、アプリケーションがオーディオ再生またはレコード操作を要求したときの間隔として、およびデバイスの実装が実際に操作を開始するときの間隔として広く定義されます。多くのクラスのアプリケーションは、短いレイテンシに依存しており、そのようなサウンドエフェクトやVoIP通信などのリアルタイム効果を実現しています。マイクハードウェアを含むデバイスの実装とandroid.hardware.microphoneを宣言するデバイスは、このセクションで概説されているすべてのオーディオレイテンシ要件を満たす必要があります。デバイスの実装によってマイクハードウェアが省略される可能性のある条件の詳細については、セクション7を参照してください。

このセクションの目的のために：

• 「コールド出力レイテンシ」は、アプリケーションがオーディオ再生をリクエストするときとサウンドの再生を開始するときの間隔であると定義されます。
• 「ウォーム出力レイテンシ」は、アプリケーションがオーディオ再生を要求するときとサウンドの再生を開始するときの間隔であると定義されます。
• 「連続出力レイテンシ」は、アプリケーションが再生されるサンプルを発行するときとスピーカーが対応するサウンドを物理的に再生するときの間隔であると定義されます。
• 「コールド入力レイテンシ」は、アプリケーションがオーディオ録音を要求するときと、オーディオシステムとマイクがリクエストの前にアイドル状態で電源を削減したときに、最初のサンプルがコールバックを介してアプリケーションに配信されるときの間隔であると定義されます。
• 「連続入力レイテンシ」は、周囲の音が発生したときとその音に対応するサンプルがコールバックを介して録音アプリケーションに配信されるときに定義されます。

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

• 100ミリ秒以下のコールド出力遅延
• 10ミリ秒以下の温かい出力遅延
• 45ミリ秒以下の連続出力遅延
• 100ミリ秒以下のコールド入力遅延
• 50ミリ秒以下の連続入力遅延

注：上記の要件はAndroid 2.3の「Subls」と述べられていますが、将来のバージョンの互換性の定義は、これらを「必須」に変更することが計画されています。つまり、これらの要件はAndroid 2.3ではオプションですが、将来のバージョンでは必要になります。 Android 2.3を実行する既存および新しいデバイスは、Android 2.3のこれらの要件を満たすことを非常に強く奨励しています。または、将来のバージョンにアップグレードしたときにAndroid互換性を達成することはできません。

デバイスの実装がこのセクションの要件を満たしている場合、 android.content.pm.PackageManagerクラスを介して「android.hardware.audio.low-latency」という機能を報告することにより、低遅延のオーディオのサポートを報告することができます。 [リソース、27 ]逆に、デバイスの実装がこれらの要件を満たしていない場合、低遅延のオーディオのサポートを報告してはなりません。

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

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

• Android Debug Bridge（ADBとして知られる） [リソース、23 ]
  デバイスの実装は、Android SDKで文書化されているすべてのadb機能をサポートする必要があります。デバイス側のadbデーモンはデフォルトでは非アクティブである必要がありますが、Androidデバッグブリッジをオンにするにはユーザーアクセス可能なメカニズムが必要です。
• Dalvik Debug Monitorサービス（DDMSと呼ばれる） [リソース、23 ]
  デバイスの実装は、Android SDKで文書化されているすべてのddms機能をサポートする必要があります。 ddms adbを使用するため、 ddmsのサポートはデフォルトでは非アクティブである必要がありますが、ユーザーがAndroid Debug Bridgeを上記のようにアクティブ化した場合はいつでもサポートする必要があります。
• モンキー[リソース、26 ]
  デバイスの実装には、モンキーフレームワークを含め、アプリケーションを使用できるようにする必要があります。

ほとんどのLinuxベースのシステムとApple Macintoshシステムは、追加のサポートなしで標準のAndroid SDKツールを使用してAndroidデバイスを認識しています。ただし、Microsoft Windowsシステムには通常、新しいAndroidデバイスのドライバーが必要です。 （たとえば、新しいベンダーIDや新しいデバイスIDには、Windowsシステム用のカスタムUSBドライバーが必要です。）デバイスの実装が標準のAndroid SDKで提供されているadbツールによって認識されていない場合、デバイスの実装者は開発者が接続できるようにするWindowsドライバーを提供する必要があります。 adbプロトコルを使用したデバイス。これらのドライバーは、32ビットと64ビットの両方のバージョンで、Windows XP、Windows Vista、およびWindows 7に提供する必要があります。

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

Androidは、デバイスの実装者が革新的なフォームファクターと構成を作成できるようにすることを目的としています。同時に、Android開発者は、Android APIを通じて利用可能なさまざまなハードウェアと機能に依存する革新的なアプリケーションを作成します。このセクションの要件は、デバイスの実装者が利用できるイノベーションと、アプリが適切に実行されるデバイスのみがアプリが利用できるようにするための開発者のニーズのバランスをとっています。

デバイスにサードパーティ開発者に対応するAPIを備えた特定のハードウェアコンポーネントが含まれている場合、デバイスの実装は、Android SDKドキュメントで説明されているようにそのAPIを実装する必要があります。 SDKのAPIがオプションであると述べられているハードウェアコンポーネントと対話し、デバイスの実装にはそのコンポーネントがありません。

• コンポーネントのAPIの完全なクラス定義（SDKによって文書化されている）はまだ存在する必要があります
• APIの動作は、何らかの合理的な方法でノーオープとして実装する必要があります
• APIメソッドは、SDKドキュメントで許可されている場合にnull値を返す必要があります
• APIメソッドは、SDKドキュメントでnull値が許可されていないクラスのNO-op実装を返す必要があります
• APIメソッドは、SDKドキュメントによって文書化されていない例外をスローしてはなりません

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

デバイスの実装は、 android.content.pm.PackageManagerクラスのgetSystemAvailableFeatures()およびhasSystemFeature(String)メソッドを介して正確なハードウェア構成情報を正確に報告する必要があります。 [リソース、27 ]

7.1.ディスプレイとグラフィックス

Android 2.3には、デバイスに適切にアプリケーションアセットとUIレイアウトを自動的に調整する機能が含まれており、さまざまなハードウェア構成[リソース、28 ]でサードパーティのアプリケーションが適切に実行されるようにします。このセクションで詳述されているように、デバイスはこれらのAPIと動作を適切に実装する必要があります。

7.1.1.画面構成

デバイスの実装は、次の要件を満たしていれば、ピクセル寸法の画面を使用する場合があります。

• 画面は物理的な斜めのサイズが少なくとも2.5インチでなければなりません
• 密度は少なくとも100 dpiでなければなりません
• アスペクト比は1.333（4：3）から1.779（16：9）でなければなりません
• 使用されるディスプレイテクノロジーは、平方ピクセルで構成されています

上記の要件を満たす画面を満たすデバイスの実装は互換性があり、追加のアクションは必要ありません。 Androidフレームワークの実装は、画面サイズのバケットや密度バケットなどの表示特性を自動的に計算します。ほとんどの場合、フレームワークの決定は正しいものです。デフォルトのフレームワーク計算が使用されている場合、追加のアクションは必要ありません。デフォルトの変更を希望するデバイスの実装者、または上記の要件を満たしていない画面を使用しているデバイスの実装者は、セクション12で規定されているように、ガイダンスのためにAndroid互換性チームに連絡する必要があります。

上記の要件で使用される単位は、次のように定義されています。

• 「物理的斜めのサイズ」とは、ディスプレイの照らされた部分の2つの反対側の角の間のインチの距離です。
• 「DPI」（「インチあたりのドット」を意味する）は、1 "の線形水平または垂直スパンに含まれるピクセル数です。DPI値がリストされている場合、水平DPIと垂直DPIの両方が範囲内に収まる必要があります。
• 「アスペクト比」とは、画面の長い寸法の短い寸法の比率です。たとえば、480x854ピクセルの表示は854 /480 = 1.779、またはほぼ「16：9」です。

デバイスの実装では、単一の静的構成でディスプレイのみを使用する必要があります。つまり、デバイスの実装は、複数の画面構成を有効にしてはなりません。たとえば、典型的なテレビは1080p、720pなどの複数の解像度をサポートしているため、この構成はAndroid 2.3と互換性がありません。 （ただし、そのような構成のサポートは調査中であり、Androidの将来のバージョンのために計画されています。）

7.1.2.メトリックを表示します

デバイスの実装は、 android.util.DisplayMetrics [リソース、29 ]で定義されているすべてのディスプレイメトリックの正しい値を報告する必要があります。

7.1.3。宣言された画面サポート

アプリケーションは、オプションで、AndroidManifest.xmlファイルの<supports-screens>属性を介してサポートする画面サイズを示します。 Android SDKドキュメントで説明されているように、デバイスの実装は、小規模、中、大規模な画面に対する適切なサポートを正しく称える必要があります。

7.1.4。スクリーンオリエンテーション

互換性のあるデバイスは、ポートレートまたはランドスケープスクリーンの向きのいずれかへのアプリケーションにより、動的方向をサポートする必要があります。つまり、デバイスは、特定の画面向きのアプリケーションの要求を尊重する必要があります。デバイスの実装では、デフォルトとしてポートレートまたはランドスケープオリエンテーションのいずれかを選択できます。物理的に回転できないデバイスは、利用可能なディスプレイの一部のみを使用して、ポートレートモードを要求する「レターボックス化」アプリケーションによってこの要件を満たすことができます。

デバイスは、Android.content.res.configuration.orientation、android.view.display.getorientation（）、またはその他のAPIを介して照会されるたびに、デバイスの現在の方向の正しい値を報告する必要があります。

7.1.5. 3Dグラフィックスアクセラレーション

Android 2.3 APIで要求されるように、デバイスの実装はOpenGL ES 1.0をサポートする必要があります。 3Dアクセラレーションハードウェアを欠くデバイスの場合、OpenGL ES 1.0のソフトウェア実装は、アップストリームAndroidオープンソースプロジェクトによって提供されます。デバイスの実装は、OpenGL ES 2.0をサポートする必要があります。

実装は、Open GL ES 2.0サポートを省略する場合があります。ただし、サポートが省略されている場合、デバイスの実装はOpenGL ES 2.0をサポートするものとして報告してはなりません。具体的には、デバイスの実装にOpenGL ES 2.0のサポートがない場合：

• マネージドAPI（via GLES10.getString()メソッドなど）は、OpenGL ES 2.0のサポートを報告してはなりません
• ネイティブC/C ++ OpenGL API（つまり、libgles_v1cm.so、libgles_v2.so、またはlibegl.so経由でアプリが利用できるもの）は、OpenGL ES 2.0のサポートを報告してはなりません。

逆に、デバイスの実装がOpenGL ES 2.0をサポートしている場合、リストされているルートを介してそのサポートを正確に報告する必要があります。

Android 2.3には、オプションで特定のOpenGLテクスチャ圧縮形式が必要であることをオプションで指定するためのアプリケーションのサポートが含まれていることに注意してください。これらの形式は通常、ベンダー固有のものです。特定のテクスチャ圧縮形式を実装するために、Android 2.3ではデバイスの実装は必要ありません。ただし、OpenGL APIのgetString()メソッドを介して、サポートするテクスチャ圧縮形式を正確に報告する必要があります。

7.2.入力デバイス

Android 2.3は、ユーザー入力の多くのモダリティをサポートしています。デバイスの実装は、このセクションで規定されているユーザー入力デバイスをサポートする必要があります。

7.2.1.キーボード

デバイスの実装:

• Developer.Android.comで詳細に記載されているように、入力管理フレームワーク（サードパーティの開発者が入力管理エンジン、つまりソフトキーボードを作成できるようにする）のサポートを含める必要があります。
• 少なくとも1つのソフトキーボードの実装を提供する必要があります（ハードキーボードが存在するかどうかに関係なく）
• 追加のソフトキーボードの実装が含まれる場合があります
• ハードウェアキーボードが含まれる場合があります
• android.content.res.Configuration.keyboard [リソース、30 ]（つまり、qwerty、または12-key）で指定された形式の1つと一致しないハードウェアキーボードを含めないでください。

7.2.2.タッチナビゲーション

デバイスの実装:

• タッチ以外のナビゲーションオプションを省略する可能性があります（つまり、トラックボール、Dパッド、またはホイールを省略する場合があります）
• android.content.res.Configuration.navigationの正しい値を報告する必要があります[リソース、30 ]
• 入力管理エンジンと互換性のあるテキストの選択と編集のための合理的な代替ユーザーインターフェイスメカニズムを提供する必要があります。上流のAndroidオープンソースコードには、タッチナビゲーションの入力がないデバイスでの使用に適した選択メカニズムが含まれています。

7.2.3.ナビゲーションキー

Androidナビゲーションパラダイムにとって、家、メニュー、バック機能は不可欠です。デバイスの実装は、アプリケーションの状態に関係なく、常にユーザーが利用できるようにする必要があります。これらの機能は、専用ボタンを介して実装する必要があります。それらは、ソフトウェア、ジェスチャー、タッチパネルなどを使用して実装される場合がありますが、もしそうなら、それらは常にアクセスしやすく、利用可能なアプリケーションディスプレイ領域をあいまいにしたり妨害したりする必要があります。

デバイスの実装者は、専用の検索キーも提供する必要があります。デバイスの実装者は、電話に送信および終了キーを提供することもできます。

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

デバイスの実装:

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

7.3.センサー

Android 2.3には、さまざまなセンサータイプにアクセスするためのAPIが含まれています。通常、デバイスの実装は、以下のサブセクションで規定されているように、これらのセンサーを省略する場合があります。デバイスにサードパーティ開発者に対応するAPIを備えた特定のセンサータイプが含まれている場合、デバイスの実装は、Android SDKドキュメントで説明されているようにそのAPIを実装する必要があります。たとえば、デバイスの実装：

• android.content.pm.PackageManagerクラスごとにセンサーの有無を正確に報告する必要があります。 [リソース、27 ]
• SensorManager.getSensorList()および同様の方法を介して、サポートされているセンサーの正確なリストを返す必要があります
• 他のすべてのセンサーAPIに対して合理的に動作する必要があります（たとえば、アプリケーションがリスナーを登録しようとする場合、適切な場合は真またはfalseを返すことにより、対応するセンサーが存在しない場合など、センサーリスナーなどを呼び出すことはありません。

上記のリストは包括的ではありません。 Android SDKの文書化された動作は、権威あると見なされます。

一部のセンサータイプは合成です。つまり、他の1つ以上のセンサーから提供されるデータから導出できます。 （例には、方向センサーと線形加速センサーが含まれます。）デバイスの実装は、前提条件の物理センサーを含む場合、これらのセンサータイプを実装する必要があります。

Android 2.3 APIは、データが変更された場合だけでなく、データを継続的に返す「ストリーミング」センサーの概念を導入します。デバイスの実装は、Android 2.3 SDKドキュメントで示されるAPIの定期的なデータサンプルをストリーミングセンサーとして継続的に提供する必要があります。

7.3.1.加速度計

デバイスの実装には、3軸アクセルメーターを含める必要があります。デバイスの実装に3軸アクセルメーターが含まれている場合、それは次のとおりです。

• 50 Hz以上でイベントを提供できる必要があります
• Android APIで詳述されているように、Androidセンサー座標系に準拠する必要があります（[リソース、31 ]を参照）
• 3次元ベクターでは、自由落下から2倍の重力（2G）以上まで測定できる必要があります
• 8ビット以上の精度が必要です
• 0.05 m/s^2以下の標準偏差が必要です

7.3.2.磁力計

デバイスの実装には、3軸の磁力計（つまりコンパス）を含める必要があります。デバイスに3軸磁力計が含まれている場合、それは次のとおりです。

• 10 Hz以上でイベントを配信できる必要があります
• Android APIで詳述されているように、Androidセンサー座標系に準拠する必要があります（[リソース、31 ]を参照）。
• 地磁場をカバーするのに適したさまざまなフィールド強度をサンプリングできる必要があります
• 8ビット以上の精度が必要です
• 0.5 µt以下の標準偏差が必要です

7.3.3. GPS

デバイスの実装には、GPSレシーバーを含める必要があります。デバイスの実装にGPSレシーバーが含まれている場合、GPSのロックオン時間を最小限に抑えるために、何らかの形の「Assisted GPS」技術を含める必要があります。

7.3.4.ジャイロスコープ

デバイスの実装には、ジャイロスコープ（すなわち角度変化センサー）を含める必要があります。デバイスは、3軸の加速度計も含まれていない限り、ジャイロスコープセンサーを含めるべきではありません。デバイスの実装にジャイロスコープが含まれている場合、それ：

• 最大5.5*piラジアン/秒（つまり、1秒あたり約1,000度）までの方向変更を測定できる必要があります
• 100 Hz以上でイベントを提供できる必要があります
• 8ビット以上の精度が必要です

7.3.5.バロメーター

デバイスの実装には、バロメーター（すなわち周囲の空気圧センサー）が含まれる場合があります。デバイスの実装にバロメーターが含まれている場合、それは次のとおりです。

• 5 Hz以上でイベントを提供できる必要があります
• 高度の推定を有効にするには、適切な精度が必要です

7.3.7.温度計

デバイスの実装には、温度計（つまり温度センサー）を含めることはできませんが、デバイスの実装に温度計が含まれている場合、デバイスCPUの温度を測定する必要があります。他の温度を測定してはなりません。 （このセンサータイプはAndroid 2.3 APIで非推奨されていることに注意してください。）

7.3.7.測光器

デバイスの実装には、光度計（すなわち周囲光センサー）が含まれる場合があります。

7.3.8.近接センサー

デバイスの実装には、近接センサーが含まれる場合があります。デバイスの実装に近接センサーが含まれている場合、画面と同じ方向のオブジェクトの近接を測定する必要があります。つまり、このセンサータイプの主な意図は、ユーザーが使用している携帯電話を検出することであるため、近接センサーは画面に近いオブジェクトを検出するために方向付けられる必要があります。デバイスの実装に他の方向を備えた近接センサーが含まれている場合、このAPIを通じてアクセスできないでください。デバイスの実装に近接センサーがある場合、1ビットの精度以上が必要です。

7.4.データ接続性

ネットワークの接続とインターネットへのアクセスは、Androidの重要な機能です。一方、デバイスとデバイス間の相互作用は、Androidデバイスとアプリケーションに大きな価値を追加します。このセクションのデバイスの実装は、データ接続要件を満たす必要があります。

7.4.1.電話

Android 2.3 APIで使用される「テレフォニー」とこのドキュメントは、GSMまたはCDMAネットワークを介して音声通話の配置とSMSメッセージの送信に関連するハードウェアを特に指します。これらの音声呼び出しはパケットスイッチに巻き込まれている場合とそうでない場合がありますが、同じネットワークを使用して実装される可能性のあるデータ接続とは無関係にAndroid 2.3の目的のためです。言い換えれば、Androidの「テレフォニー」機能とAPIは、音声通話とSMSを特に指します。たとえば、SMSメッセージを通話または送信/受信できないデバイスの実装は、データ接続にセルラーネットワークを使用するかどうかに関係なく、「Android.hardware.telephony」機能またはサブ機能を報告してはなりません。

Android 2.3は、テレフォニーハードウェアを含まないデバイスで使用できます。つまり、Android 2.3は、電話ではないデバイスと互換性があります。ただし、デバイスの実装にGSMまたはCDMAテレフォニーが含まれている場合、そのテクノロジーのAPIの完全なサポートを実装する必要があります。テレフォニーハードウェアを含まないデバイスの実装は、完全なAPIをNO-OPSとして実装する必要があります。

7.4.2. IEEE 802.11（wifi）

Android 2.3デバイスの実装には、802.11（b/g/a/nなど）の1つ以上のフォームのサポートを含める必要があります。デバイスの実装に802.11のサポートが含まれている場合、対応するAndroid APIを実装する必要があります。

7.4.3.ブルートゥース

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

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

7.4.4.近いフィールド通信

デバイスの実装には、近いフィールド通信（NFC）のためのトランシーバーと関連するハードウェアを含める必要があります。デバイスの実装にNFCハードウェアが含まれている場合、それ：

• android.content.pm.PackageManager.hasSystemFeature()メソッドからandroid.hardware.nfc機能を報告する必要があります。 [リソース、27 ]
• 次のNFC標準を介してNDEFメッセージを読み書きできる必要があります。
  • NFCフォーラムリーダー/ライターとして行動できる必要があります（NFCフォーラムの技術仕様で定義されているように、NFCForum-TS-DigitalProtocol-1.0）次のNFC標準を介して：
    • NFCA（ISO14443-3a）
    • NFCB（ISO14443-3B）
    • NFCF（JIS 6319-4）
    • NFCV（ISO 15693）
    • ISODEP（ISO 14443-4）
    • NFCフォーラムタグタイプ1、2、3、4（NFCフォーラムで定義）
  • 次のピアツーピア標準とプロトコルを介してデータを送信および受信できる必要があります。
    • ISO 18092
    • LLCP 1.0（NFCフォーラムで定義）
    • SDP 1.0（NFCフォーラムで定義）
    • NDEFプッシュプロトコル[リソース、33 ]
  • NFCディスカバリーモード中に、すべてのサポートされているテクノロジーをスキャンする必要があります。
  • 画面がアクティブになってデバイスが目を覚ましている間に、NFCディスカバリーモードである必要があります。

  （上記で引用したJIS、ISO、およびNFCフォーラムの仕様では、公開されているリンクは利用できないことに注意してください。）

  さらに、デバイスの実装は、次の広く展開されたMIFAREテクノロジーをサポートする必要があります。

  • Mifare Classic（NXP MF1S503X [リソース、34 ]、MF1S703X [リソース、35 ]）
  • Mifare ultralight（NXP MF0ICU1 [リソース、36 ]、MF0ICU2 [リソース、37 ]）
  • Mifare ClassicのNDEF（NXP AN130511 [リソース、38 ]、AN130411 [リソース、39 ]）

  Android 2.3.3には、これらのMIFAREタイプのAPIが含まれていることに注意してください。デバイスの実装がMIFAREをサポートしている場合、それ：

  • Android SDKによって文書化されているように、対応するAndroid APIを実装する必要があります
  • android.content.pm.PackageManager.hasSystemFeature()メソッドから機能com.nxp.mifareを報告する必要があります。 [ Resources、27 ]これは標準的なAndroid機能ではないため、 PackageManagerクラスでは定数として表示されないことに注意してください。
  • 対応するAndroid APIを実装したり、このセクションで説明したように一般的なNFCサポートも実装しない限り、com.nxp.mifare機能を報告したりしないでください

  デバイスの実装にNFCハードウェアが含まれていない場合、 android.content.pm.PackageManager.hasSystemFeature()メソッド[リソース、27 ]からandroid.hardware.nfc機能を宣言してはなりません。 NO-OP。

  クラスandroid.nfc.NdefMessageおよびandroid.nfc.NdefRecordプロトコルに依存しないデータ表現形式を表すため、NFCのサポートを含めたり、Android.hardware.nfc機能を宣言しても、デバイスの実装はこれらのAPIを実装する必要があります。

  7.4.5.最小ネットワーク機能

  デバイスの実装には、1つ以上の形式のデータネットワーキングのサポートを含める必要があります。具体的には、デバイスの実装には、200kbit/sec以上が可能な少なくとも1つのデータ標準のサポートを含める必要があります。 Examples of technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, Ethernet, etc.

  Device implementations where a physical networking standard (such as Ethernet) is the primary data connection SHOULD also include support for at least one common wireless data standard, such as 802.11 (WiFi).

  Devices MAY implement more than one form of data connectivity.

  7.5。カメラ

  Device implementations SHOULD include a rear-facing camera, and MAY include a front-facing camera. A rear-facing camera is a camera located on the side of the device opposite the display; that is, it images scenes on the far side of the device, like a traditional camera. A front-facing camera is a camera located on the same side of the device as the display; that is, a camera typically used to image the user, such as for video conferencing and similar applications.

  7.5.1. Rear-Facing Camera

  Device implementations SHOULD include a rear-facing camera. If a device implementation includes a rear-facing camera, it:

  • MUST have a resolution of at least 2 megapixels
  • SHOULD have either hardware auto-focus, or software auto-focus implemented in the camera driver (transparent to application software)
  • MAY have fixed-focus or EDOF (extended depth of field) hardware
  • MAY include a flash. If the Camera includes a flash, the flash lamp MUST NOT be lit while an android.hardware.Camera.PreviewCallback instance has been registered on a Camera preview surface, unless the application has explicitly enabled the flash by enabling the FLASH_MODE_AUTO or FLASH_MODE_ON attributes of a Camera.Parameters object. Note that this constraint does not apply to the device's built-in system camera application, but only to third-party applications using Camera.PreviewCallback .

  7.5.2. Front-Facing Camera

  Device implementations MAY include a front-facing camera. If a device implementation includes a front-facing camera, it:

  • MUST have a resolution of at least VGA (that is, 640x480 pixels)
  • MUST NOT use a front-facing camera as the default for the Camera API. That is, the camera API in Android 2.3 has specific support for front-facing cameras, and device implementations MUST NOT configure the API to to treat a front-facing camera as the default rear-facing camera, even if it is the only camera onデバイス。
  • MAY include features (such as auto-focus, flash, etc.) available to rear-facing cameras as described in Section 7.5.1.
  • MUST horizontally reflect (ie mirror) the stream displayed by an app in a CameraPreview, as follows:
  • If the device implementation is capable of being rotated by user (such as automatically via an accelerometer or manually via user input), the camera preview MUST be mirrored horizontally relative to the device's current orientation.
  • If the current application has explicitly requested that the Camera display be rotated via a call to the android.hardware.Camera.setDisplayOrientation() [ Resources, 40 ] method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application.
  • Otherwise, the preview MUST be mirrored along the device's default horizontal axis.
  • MUST mirror the image data returned to any "postview" camera callback handlers, in the same manner as the camera preview image stream. (If the device implementation does not support postview callbacks, this requirement obviously does not apply.)
  • MUST NOT mirror the final captured still image or video streams returned to application callbacks or committed to media storage

  7.5.3. Camera API Behavior

  Device implementations MUST implement the following behaviors for the camera-related APIs, for both front- and rear-facing cameras:

  1. If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int), then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to application callbacks.
  2. If an application registers an android.hardware.Camera.PreviewCallback instance and the system calls the onPreviewFrame() method when the preview format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame() must further be in the NV21 encoding format. That is, NV21 MUST be the default.
  3. Device implementations SHOULD support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. Note that the Compatibility Definition for a future version is planned to change this requirement to "MUST". That is, YV12 support is optional in Android 2.3 but will be required by a future version. Existing and new devices that run Android 2.3 are very strongly encouraged to meet this requirement in Android 2.3 , or they will not be able to attain Android compatibility when upgraded to the future version.

  Device implementations MUST implement the full Camera API included in the Android 2.3 SDK documentation [ Resources, 41 ]), regardless of whether the device includes hardware autofocus or other capabilities. For instance, cameras that lack autofocus MUST still call any registered android.hardware.Camera.AutoFocusCallback instances (even though this has no relevance to a non-autofocus camera.) Note that this does apply to front-facing cameras; for instance, even though most front-facing cameras do not support autofocus, the API callbacks must still be "faked" as described.

  Device implementations MUST recognize and honor each parameter name defined as a constant on the android.hardware.Camera.Parameters class, if the underlying hardware supports the feature. If the device hardware does not support a feature, the API must behave as documented. Conversely, Device implementations MUST NOT honor or recognize string constants passed to the android.hardware.Camera.setParameters() method other than those documented as constants on the android.hardware.Camera.Parameters . That is, device implementations MUST support all standard Camera parameters if the hardware allows, and MUST NOT support custom Camera parameter types.

  7.5.4.カメラの向き

  Both front- and rear-facing cameras, if present, MUST be oriented so that the long dimension of the camera aligns with the screen's long dimension. That is, when the device is held in the landscape orientation, a cameras MUST capture images in the landscape orientation. This applies regardless of the device's natural orientation; that is, it applies to landscape-primary devices as well as portrait-primary devices.

  7.6.メモリとストレージ

  The fundamental function of Android 2.3 is to run applications. Device implementations MUST the requirements of this section, to ensure adequate storage and memory for applications to run properly.

  7.6.1. Minimum Memory and Storage

  Device implementations MUST have at least 128MB of memory available to the kernel and userspace. The 128MB MUST be in addition to any memory dedicated to hardware components such as radio, memory, and so on that is not under the kernel's control.

  Device implementations MUST have at least 150MB of non-volatile storage available for user data. That is, the /data partition MUST be at least 150MB.

  Beyond the requirements above, device implementations SHOULD have at least 1GB of non-volatile storage available for user data. Note that this higher requirement is planned to become a hard minimum in a future version of Android. Device implementations are strongly encouraged to meet these requirements now, or else they may not be eligible for compatibility for a future version of Android.

  The Android APIs include a Download Manager that applications may use to download data files. The Download Manager implementation MUST be capable of downloading individual files 55MB in size, or larger. The Download Manager implementation SHOULD be capable of downloading files 100MB in size, or larger.

  7.6.2. Application Shared Storage

  Device implementations MUST offer shared storage for applications. The shared storage provided MUST be at least 1GB in size.

  Device implementations MUST be configured with shared storage mounted by default, "out of the box". If the shared storage is not mounted on the Linux path /sdcard , then the device MUST include a Linux symbolic link from /sdcard to the actual mount point.

  Device implementations MUST enforce as documented the android.permission.WRITE_EXTERNAL_STORAGE permission on this shared storage. Shared storage MUST otherwise be writable by any application that obtains that permission.

  Device implementations MAY have hardware for user-accessible removable storage, such as a Secure Digital card. Alternatively, device implementations MAY allocate internal (non-removable) storage as shared storage for apps.

  Regardless of the form of shared storage used, device implementations MUST provide some mechanism to access the contents of shared storage from a host computer, such as USB mass storage or Media Transfer Protocol.

  It is illustrative to consider two common examples. If a device implementation includes an SD card slot to satisfy the shared storage requirement, a FAT-formatted SD card 1GB in size or larger MUST be included with the device as sold to users, and MUST be mounted by default. Alternatively, if a device implementation uses internal fixed storage to satisfy this requirement, that storage MUST be 1GB in size or larger and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere.)

  Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) SHOULD modify the core applications such as the media scanner and ContentProvider to transparently support files placed in both locations.

  7.7. USB

  デバイスの実装:

  • MUST implement a USB client, connectable to a USB host with a standard USB-A port
  • MUST implement the Android Debug Bridge over USB (as described in Section 7)
  • MUST implement the USB mass storage specification, to allow a host connected to the device to access the contents of the /sdcard volume
  • SHOULD use the micro USB form factor on the device side
  • MAY include a non-standard port on the device side, but if so MUST ship with a cable capable of connecting the custom pinout to standard USB-A port

  8. Performance Compatibility

  Compatible implementations must ensure not only that applications simply run correctly on the device, but that they do so with reasonable performance and overall good user experience. Device implementations MUST meet the key performance metrics of an Android 2.3 compatible device defined in the table below:

  メトリック	Performance Threshold	コメント
  Application Launch Time	The following applications should launch within the specified time. Browser: less than 1300ms MMS/SMS: less than 700ms AlarmClock: less than 650ms	The launch time is measured as the total time to complete loading the default activity for the application, including the time it takes to start the Linux process, load the Android package into the Dalvik VM, and call onCreate.
  Simultaneous Applications	When multiple applications have been launched, re-launching an already-running application after it has been launched must take less than the original launch time.

  9. Security Model Compatibility

  Device implementations MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 42 ] in the Android developer documentation. Device implementations MUST support installation of self-signed applications without requiring any additional permissions/certificates from any third parties/authorities. Specifically, compatible devices MUST support the security mechanisms described in the follow sub-sections.

  9.1.権限

  Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 42 ]. Specifically, implementations MUST enforce each permission defined as described in the SDK documentation; no permissions may be omitted, altered, or ignored. Implementations MAY add additional permissions, provided the new permission ID strings are not in the android.* namespace.

  9.2. UID and Process Isolation

  Device implementations MUST support the Android application sandbox model, in which each application runs as a unique Unix-style UID and in a separate process. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 42 ].

  9.3. Filesystem Permissions

  Device implementations MUST support the Android file access permissions model as defined in as defined in the Security and Permissions reference [ Resources, 42 ].

  9.4. Alternate Execution Environments

  Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik virtual machine or native code. However, such alternate execution environments MUST NOT compromise the Android security model or the security of installed Android applications, as described in this section.

  Alternate runtimes MUST themselves be Android applications, and abide by the standard Android security model, as described elsewhere in Section 9.

  Alternate runtimes MUST NOT be granted access to resources protected by permissions not requested in the runtime's AndroidManifest.xml file via the <uses-permission> mechanism.

  Alternate runtimes MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications.

  Alternate runtimes MUST abide by the Android sandbox model.具体的には：

  • Alternate runtimes SHOULD install apps via the PackageManager into separate Android sandboxes (that is, Linux user IDs, etc.)
  • Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime.
  • Alternate runtimes and installed applications using an alternate runtime MUST NOT reuse the sandbox of any other app installed on the device, except through the standard Android mechanisms of shared user ID and signing certificate
  • Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications.

  Alternate runtimes MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID.

  The .apk files of alternate runtimes MAY be included in the system image of a device implementation, but MUST be signed with a key distinct from the key used to sign other applications included with the device implementation.

  When installing applications, alternate runtimes MUST obtain user consent for the Android permissions used by the application. That is, if an application needs to make use of a device resource for which there is a corresponding Android permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application will be able to access that resource 。 If the runtime environment does not record application capabilities in this manner, the runtime environment MUST list all permissions held by the runtime itself when installing any application using that runtime.

  10. Software Compatibility Testing

  The Android Open-Source Project includes various testing tools to verify that device implementations are compatible. Device implementations MUST pass all tests described in this section.

  However, note that no software test package is fully comprehensive. For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android 2.3 available from the Android Open-Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

  10.1. Compatibility Test Suite

  Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 2 ] available from the Android Open Source Project, using the final shipping software on the device. Additionally, device implementers SHOULD use the reference implementation in the Android Open Source tree as much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any reimplementations of parts of the reference source code.

  The CTS is designed to be run on an actual device. Like any software, the CTS may itself contain bugs. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 2.3. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

  MUST pass the most recent version of the Android Compatibility Test Suite (CTS) available at the time of the device implementation's software is completed. (The CTS is available as part of the Android Open Source Project [ Resources, 2 ].) The CTS tests many, but not all, of the components outlined in this document.

  10.2. CTS 検証者

  Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

  The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional. Device implementations MUST pass all tests for hardware which they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier. Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

  Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verfier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

  10.3.参考アプリケーション

  Device implementers MUST test implementation compatibility using the following open-source applications:

  • The "Apps for Android" applications [ Resources, 43 ].
  • Replica Island (available in Android Market; only required for device implementations that support with OpenGL ES 2.0)

  Each app above MUST launch and behave correctly on the implementation, for the implementation to be considered compatible.

  11. Updatable Software

  Device implementations MUST include a mechanism to replace the entirety of the system software. The mechanism need not perform "live" upgrades -- that is, a device restart MAY be required.

  Any method can be used, provided that it can replace the entirety of the software preinstalled on the device. For instance, any of the following approaches will satisfy this requirement:

  • Over-the-air (OTA) downloads with offline update via reboot
  • "Tethered" updates over USB from a host PC
  • "Offline" updates via a reboot and update from a file on removable storage

  The update mechanism used MUST support updates without wiping user data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

  If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a software update available that can be applied per the mechanism just described.

  12. Contact Us

  You can contact the document authors at compatibility@android.com for clarifications and to bring up any issues that you think the document does not cover.

  Appendix A - Bluetooth Test Procedure

  The Compatibility Test Suite includes cases that cover basic operation of the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications protocol between devices, it cannot be fully tested by unit tests running on a single device. Consequently, device implementations MUST also pass the human-operated Bluetooth test procedure described below.

  The test procedure is based on the BluetoothChat sample app included in the Android open-source project tree. The procedure requires two devices:

  • a candidate device implementation running the software build to be tested
  • a separate device implementation already known to be compatible, and of a model from the device implementation being tested -- that is, a "known good" device implementation

  The test procedure below refers to these devices as the "candidate" and "known good" devices, respectively.

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

  1. Build BluetoothChat.apk via 'make samples' from an Android source code tree.
  2. Install BluetoothChat.apk on the known-good device.
  3. Install BluetoothChat.apk on the candidate device.

  Test Bluetooth Control by Apps

  1. Launch BluetoothChat on the candidate device, while Bluetooth is disabled.
  2. Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth.

  Test Pairing and Communication

  1. Launch the Bluetooth Chat app on both devices.
  2. Make the known-good device discoverable from within BluetoothChat (using the Menu).
  3. On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device.
  4. Send 10 or more messages from each device, and verify that the other device receives them correctly.
  5. Close the BluetoothChat app on both devices by pressing Home .
  6. Unpair each device from the other, using the device Settings app.

  Test Pairing and Communication in the Reverse Direction

  1. Launch the Bluetooth Chat app on both devices.
  2. Make the candidate device discoverable from within BluetoothChat (using the Menu).
  3. On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.
  4. Send 10 or messages from each device, and verify that the other device receives them correctly.
  5. Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.

  Test Re-Launches

  1. Re-launch the Bluetooth Chat app on both devices.
  2. Send 10 or messages from each device, and verify that the other device receives them correctly.

  Note: the above tests have some cases which end a test section by using Home, and some using Back. These tests are not redundant and are not optional: the objective is to verify that the Bluetooth API and stack works correctly both when Activities are explicitly terminated (via the user pressing Back, which calls finish()), and implicitly sent to background (via the user pressing Home.) Each test sequence MUST be performed as described.