Android 2.3 互換性定義

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

目次

1.はじめに
2. リソース
3. ソフトウェア
4. アプリケーション パッケージの互換性
5. マルチメディア対応
6. 開発者ツールの互換性
7. ハードウェアの互換性
7.1.ディスプレイとグラフィック
7.2.入力デバイス
7.3.センサー
7.4.データ接続
7.5.カメラ
7.6.メモリとストレージ
7.7. USB
8. 性能の互換性
9. セキュリティ モデルの互換性
10. ソフトウェア互換性テスト
11. 更新可能なソフトウェア
12. お問い合わせ
付録 A - Bluetooth テスト手順

1.はじめに

このドキュメントでは、携帯電話が Android 2.3 と互換性を持つために満たす必要がある要件を列挙します。

"must"、"must not"、"required"、"shall"、"shall not"、"should"、"should not"、"recommended"、"may"、および "optional" の使用は、IETF 標準に従っています。 RFC2119 [リソース、1 ] で定義されています。

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

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

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

この互換性定義は、API レベル 10 である Android の 2.3.3 アップデートに対応するために発行されていることに注意してください。この定義は、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/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/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. AppWidgets: 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#statusbarstructure
  20. 検索マネージャー: http://developer.android.com/reference/android/app/SearchManager.html
  21. トースト: http://developer.android.com/reference/android/widget/Toast.html
  22. ライブ壁紙: http://developer.android.com/resources/articles/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. モンキー テスト ツール: http://developer.android.com/guide/developing/tools/monkey.html
  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/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 インターフェイスや署名を変更したり、文書化された動作から逸脱したり、ノーオペレーションを含めたりしてはなりません。

この互換性定義では、Android に API が含まれている一部の種類のハードウェアをデバイス実装で省略できます。そのような場合、API は引き続き存在し、妥当な方法で動作する必要があります。このシナリオの特定の要件については、セクション 7 を参照してください。

3.2.ソフト API の互換性

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

3.2.1.権限

デバイスの実装者は、アクセス許可のリファレンス ページ [参考文献、5 ] に記載されているように、すべてのアクセス許可の定数をサポートおよび適用する必要があります。セクション 10 には、Android セキュリティ モデルに関連する追加の要件がリストされていることに注意してください。

3.2.2.ビルド パラメータ

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

パラメータコメント
android.os.Build.VERSION.RELEASE現在実行中の Android システムのバージョン (人間が判読できる形式)。このフィールドには、[ Resources, 7 ] で定義された文字列値のいずれかが含まれている必要があります。
android.os.Build.VERSION.SDK現在実行中の Android システムのバージョン (サードパーティ アプリケーション コードにアクセス可能な形式)。 Android 2.3 の場合、このフィールドは整数値 9 でなければなりません。
android.os.Build.VERSION.INCREMENTAL現在実行中の Android システムの特定のビルドを人間が判読できる形式で指定する、デバイスの実装者によって選択された値。この値は、エンド ユーザーが利用できるさまざまなビルドに再利用してはなりません。このフィールドの一般的な用途は、ビルドの生成に使用されたビルド番号またはソース管理変更識別子を示すことです。 null または空の文字列 ("") であってはならないことを除いて、このフィールドの特定の形式に関する要件はありません。
android.os.Build.BOARDデバイスによって使用される特定の内部ハードウェアを識別するデバイスの実装者によって選択された値で、人間が判読できる形式です。このフィールドの可能な用途は、デバイスに電力を供給しているボードの特定のリビジョンを示すことです。このフィールドの値は、7 ビット ASCII としてエンコード可能で、正規表現"^[a-zA-Z0-9.,_-]+$"する必要があります。
android.os.Build.BRANDデバイスの実装者が選択した、デバイスを製造した会社、組織、個人などの名前を人間が読み取れる形式で識別する値。このフィールドの可能な用途は、デバイスを販売した OEM や通信事業者を示すことです。このフィールドの値は、7 ビット ASCII としてエンコード可能で、正規表現"^[a-zA-Z0-9.,_-]+$"する必要があります。
android.os.Build.DEVICEデバイスの本体の特定の構成またはリビジョン (「工業デザイン」と呼ばれることもある) を識別する、デバイス実装者によって選択された値。このフィールドの値は、7 ビット ASCII としてエンコード可能で、正規表現"^[a-zA-Z0-9.,_-]+$"する必要があります。
android.os.Build.FINGERPRINTこのビルドを一意に識別する文字列。それは合理的に人間が判読できるものであるべきです。このテンプレートに従わなければなりません:
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
例えば:
acme/mydevice/generic/generic:2.3/ERC77/3359:userdebug/test-keys
フィンガープリントには空白文字を含めてはなりません。上記のテンプレートに含まれる他のフィールドに空白文字が含まれている場合、ビルド フィンガープリント内でそれらをアンダースコア ("_") 文字などの別の文字に置き換える必要があります。このフィールドの値は、7 ビット ASCII としてエンコード可能でなければなりません。
android.os.Build.HOSTビルドが構築されたホストを一意に識別する文字列 (人間が読める形式)。 null または空の文字列 ("") であってはならないことを除いて、このフィールドの特定の形式に関する要件はありません。
android.os.Build.ID人間が読める形式で、特定のリリースを参照するためにデバイス実装者によって選択された識別子。このフィールドは android.os.Build.VERSION.INCREMENTAL と同じにすることができますが、エンド ユーザーがソフトウェア ビルドを区別するのに十分意味のある値にする必要があります。このフィールドの値は、7 ビット ASCII としてエンコード可能で、正規表現"^[a-zA-Z0-9.,_-]+$"する必要があります。
android.os.Build.MODELエンド ユーザーに知られているデバイスの名前を含む、デバイスの実装者によって選択された値。これは、デバイスが販売され、エンド ユーザーに販売されるのと同じ名前にする必要があります。 null または空の文字列 ("") であってはならないことを除いて、このフィールドの特定の形式に関する要件はありません。
android.os.Build.PRODUCTデバイスの実装者が選択した値で、デバイスの開発名またはコード名が含まれています。人間が判読できる必要がありますが、必ずしもエンド ユーザーによる表示を意図したものではありません。このフィールドの値は、7 ビット ASCII としてエンコード可能で、正規表現"^[a-zA-Z0-9.,_-]+$"する必要があります。
android.os.Build.TAGSビルドをさらに区別するためにデバイス実装者によって選択されたタグのコンマ区切りリスト。たとえば、「署名なし、デバッグ」などです。このフィールドの値は、7 ビット ASCII としてエンコード可能で、正規表現"^[a-zA-Z0-9.,_-]+$"する必要があります。
android.os.Build.TIMEビルドが発生したときのタイムスタンプを表す値。
android.os.Build.TYPEビルドのランタイム構成を指定するデバイス実装者によって選択された値。このフィールドには、「user」、「userdebug」、または「eng」という 3 つの典型的な Android ランタイム構成に対応する値のいずれかが必要です。このフィールドの値は、7 ビット ASCII としてエンコード可能で、正規表現"^[a-zA-Z0-9.,_-]+$"する必要があります。
android.os.Build.USERビルドを生成したユーザー (または自動化されたユーザー) の名前またはユーザー ID。 null または空の文字列 ("") であってはならないことを除いて、このフィールドの特定の形式に関する要件はありません。

3.2.3.インテントの互換性

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

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

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

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

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

  • 卓上時計
  • ブラウザ
  • カレンダー
  • 電卓
  • 連絡先
  • Eメール
  • ギャラリー
  • グローバルサーチ
  • ランチャー
  • 音楽
  • 設定

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

値が「false」の android:exported 属性を介して非公開としてマークされていないコア Android システム アプリのいずれかで定義されたすべてのアクティビティまたはサービスについて、デバイス実装は、同じインテント フィルターを実装する同じタイプのコンポーネントを含める必要があります。パターンをコア Android システム アプリとして使用します。

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

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

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

3.2.3.3.インテント名前空間

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

この禁止事項は、セクション 3.6 で Java 言語クラスに指定されているものと類似しています。

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

サードパーティ アプリケーションは、プラットフォームに依存して特定のインテントをブロードキャストし、ハードウェアまたはソフトウェア環境の変更を通知します。 Android 互換デバイスは、適切なシステム イベントに応答して、パブリック ブロードキャスト インテントをブロードキャストする必要があります。ブロードキャスト インテントについては、SDK ドキュメントで説明されています。

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

Dalvik で実行されるマネージ コードは、アプリケーションの .apk ファイルで提供されるネイティブ コードを、適切なデバイス ハードウェア アーキテクチャ用にコンパイルされた ELF .so ファイルとして呼び出すことができます。ネイティブ コードは基盤となるプロセッサ テクノロジに大きく依存するため、Android は Android NDK のファイルdocs/CPU-ARCH-ABIS.txtで多数のアプリケーション バイナリ インターフェース (ABI) を定義します。デバイス実装が 1 つ以上の定義済み ABI と互換性がある場合、以下のように Android NDK との互換性を実装する必要があります。

デバイス実装に Android ABI のサポートが含まれている場合、デバイス実装は:

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

次のネイティブ コード 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 のサポートをまったく報告してはなりません。

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

3.4。ウェブ互換性

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

3.4.1. WebView の互換性

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

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

WebView コンポーネントは、可能な限り多くの HTML5 [ Resources, 9 ] をサポートする必要があります。最低限、デバイス実装は、WebView で HTML5 に関連付けられたこれらの API のそれぞれをサポートする必要があります。

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

HTML5 API は、すべての JavaScript API と同様に、開発者が通常の Android API を介して明示的に有効にしない限り、WebView でデフォルトで無効にする必要があります。

3.4.2.ブラウザの互換性

デバイス実装には、一般ユーザーの Web ブラウジング用のスタンドアロン ブラウザー アプリケーションを含める必要があります。スタンドアロンのブラウザは、WebKit 以外のブラウザ技術に基づいている場合があります。ただし、別のブラウザ アプリケーションが使用されている場合でも、セクション 3.4.1 で説明されているように、サードパーティ アプリケーションに提供されるandroid.webkit.WebViewコンポーネントは WebKit に基づいている必要があります。

実装は、スタンドアロンのブラウザ アプリケーションでカスタム ユーザー エージェント文字列を出荷する場合があります。

スタンドアロンのブラウザ アプリケーション (アップストリームの WebKit ブラウザ アプリケーションに基づいているか、サードパーティの代替アプリケーションに基づいているかに関係なく) は、可能な限り多くの HTML5 [参考文献、9 ] のサポートを含めるべきです。最低限、デバイス実装は、HTML5 に関連付けられたこれらの API のそれぞれをサポートしなければなりません:

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

3.5。 API 動作の互換性

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

  • デバイスは、標準のインテントの動作またはセマンティクスを変更してはなりません (MUST NOT)。
  • デバイスは、特定のタイプのシステム コンポーネント (Service、Activity、ContentProvider など) のライフサイクルまたはライフサイクル セマンティクスを変更してはなりません。
  • デバイスは、標準パーミッションのセマンティクスを変更してはなりません (MUST NOT)

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

3.6. API 名前空間

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

  • java.*
  • javax.*
  • 太陽。*
  • アンドロイド。*
  • com.android.*

禁止されている変更には以下が含まれます。

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

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

デバイスの実装者はカスタム API を追加することができますが、そのような API は、別の組織が所有する、または別の組織を参照する名前空間にあってはなりません。たとえば、デバイスの実装者は、API を com.google.* または同様の名前空間に追加してはなりません。 Google のみがこれを行うことができます。同様に、Google は他社の名前空間に API を追加してはなりません。さらに、デバイスの実装に標準の Android 名前空間以外のカスタム API が含まれている場合、それらの API を Android 共有ライブラリにパッケージ化して、( <uses-library>メカニズムを介して) API を明示的に使用するアプリのみがメモリ使用量の増加の影響を受けるようにする必要があります。そのような API の。

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

上記の制限は、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 オープン ソース リファレンス リリースには、ユーザーがホーム画面から AppWidgets を追加、表示、および削除できるユーザー インターフェイス要素を含むランチャー アプリケーションが含まれています。

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

3.8.2.通知

Android には、開発者が重要なイベントをユーザーに通知できるようにする API が含まれています [参考文献、17 ]。デバイスの実装者は、そのように定義された通知の各クラスのサポートを提供する必要があります。具体的には、サウンド、バイブレーション、ライト、ステータス バーです。

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

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

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

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

3.8.4.トースト

アプリケーションは、"Toast" API ([ Resources, 21 ] で定義) を使用して、短い非モーダル文字列をエンド ユーザーに表示し、短時間で消えるようにすることができます。デバイス実装は、アプリケーションからエンド ユーザーへのトーストを視認性の高い方法で表示する必要があります。

3.8.5.ライブ壁紙

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

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

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

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

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

デバイスの実装は、.apk [参考文献、24 ]、Android マニフェスト [参考文献、25 ]、または Dalvik バイトコード [参考文献、15 ] のいずれかの形式を、それらのファイルが他の互換性のあるデバイスに正しくインストールおよび実行されるのを妨げるような方法で拡張してはなりません (MUST NOT)。 .デバイスの実装者は、Dalvik のリファレンス アップストリーム実装と、リファレンス実装のパッケージ管理システムを使用する必要があります。

5. マルチメディア対応

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

5.1.メディアコーデック

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

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

以下の表には、ほとんどのビデオ コーデックの特定のビットレート要件は記載されていません。これは、実際には、現在のデバイス ハードウェアが、関連する規格で指定された必要なビットレートに正確に対応するビットレートをサポートしているとは限らないためです。代わりに、デバイス実装は、仕様で定義された制限まで、ハードウェアで実用的な最高のビットレートをサポートする必要があります。

5.1.1.メディア デコーダー

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

オーディオ
名前詳細ファイル/コンテナ形式
AAC LC/LTP最大 160 kbps の標準ビット レートと 8 ~ 48 kHz のサンプリング レートの任意の組み合わせによるモノラル/ステレオ コンテンツ3GPP (.3gp) および MPEG-4 (.mp4、.m4a)。生の AAC (.aac) はサポートされていません
HE-AACv1 (AAC+)
HE-AACv2 (拡張 AAC+)
AMR-NB 4.75 ~ 12.2 kbps サンプリング @ 8kHz 3GPP (.3gp)
AMR-WB 6.60 kbit/s から 23.85 kbit/s までの 9 レート @ 16kHz でサンプリング3GPP (.3gp)
MP3モノラル/ステレオ 8 ~ 320Kbps 固定 (CBR) または可変ビットレート (VBR) MP3 (.mp3)
ミディMIDI タイプ 0 および 1。DLS バージョン 1 および 2。XMF およびモバイル XMF。着信音フォーマット RTTTL/RTX、OTA、iMelody のサポート0 と 1 を入力します (.mid、.xmf、.mxmf)。また、RTTTL/RTX (.rtttl、.rtx)、OTA (.ota)、iMelody (.imy)
オッグ・ヴォービスOgg (.ogg)
PCM 8 ビットおよび 16 ビットのリニア PCM (ハードウェアの限界までの速度)ウェーブ (.wav)
画像
JPEGベース+プログレッシブ
GIF
PNG
BMP
ビデオ
H.263 3GPP (.3gp) ファイル
H.264 3GPP (.3gp) および MPEG-4 (.mp4) ファイル
MPEG4 シンプル プロファイル3GPP (.3gp) ファイル

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

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

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

オーディオ
名前詳細ファイル/コンテナ形式条件
AMR-NB 4.75 ~ 12.2 kbps サンプリング @ 8kHz 3GPP (.3gp)マイク ハードウェアを含み、 android.hardware.microphoneを定義するデバイス実装には、これらのオーディオ形式のエンコーダを含める必要があります。
AMR-WB 6.60 kbit/s から 23.85 kbit/s までの 9 レート @ 16kHz でサンプリング3GPP (.3gp)
AAC LC/LTP最大 160 kbps の標準ビット レートと 8 ~ 48 kHz のサンプリング レートの任意の組み合わせによるモノラル/ステレオ コンテンツ3GPP (.3gp) および MPEG-4 (.mp4、.m4a)。
画像JPEGベース+プログレッシブAndroid 2.3 には、アプリケーションがこれらのタイプのファイルをプログラムで生成するために使用できる API が含まれているため、すべてのデバイス実装にこれらの画像形式のエンコーダを含める必要があります。
PNG
ビデオH.263 3GPP (.3gp) ファイルカメラ ハードウェアを含み、 android.hardware.cameraまたはandroid.hardware.camera.frontのいずれかを定義するデバイス実装には、これらのビデオ形式のエンコーダを含める必要があります。

上記のエンコーダーに加えて、デバイス実装には H.264 エンコーダーを含める必要があります。将来のバージョンの互換性定義では、この要件を「MUST」に変更する予定であることに注意してください。つまり、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 振幅レベルは、マイクロフォンで 90 dB SPL に対して -18 dB から +12 dB までの少なくとも 30 dB の範囲で、入力 SPL の変化を直線的に追跡する必要があります。
  • 全高調波歪みは、90 dB SPL 入力レベルで 100 Hz から 4000 Hz まで 1% 未満であるべきです。

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

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

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

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

  • Android Debug Bridge (adb として知られる) [リソース、23 ]
    デバイス実装は、Android SDK に記載されているすべてのadb関数をサポートする必要があります。デバイス側のadbデーモンはデフォルトで非アクティブにする必要がありますが、Android Debug Bridge をオンにするためのユーザー アクセス可能なメカニズムが必要です。
  • Dalvik Debug Monitor Service (ddms として知られる) [リソース、23 ]
    デバイス実装は、Android SDK に記載されているすべてのddms機能をサポートする必要があります。 ddmsadbを使用するため、 ddmsのサポートはデフォルトで非アクティブにする必要がありますが、上記のように、ユーザーが Android Debug Bridge をアクティブにした場合は常にサポートする必要があります。
  • サル[ Resources, 26 ]
    デバイスの実装には、Monkey フレームワークを含め、アプリケーションで使用できるようにする必要があります。

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

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

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

デバイスに、サードパーティ デベロッパー向けの対応する API を持つ特定のハードウェア コンポーネントが含まれている場合、デバイスの実装は、Android SDK ドキュメントで説明されているように、その API を実装する必要があります。 SDK の API が、オプションであると述べられているハードウェア コンポーネントと対話し、デバイス実装がそのコンポーネントを所有していない場合:

  • コンポーネントの API の完全なクラス定義 (SDK で文書化されている) がまだ存在している必要があります。
  • API の動作は、合理的な方法でノーオペレーションとして実装する必要があります。
  • API メソッドは、SDK ドキュメントで許可されている場合、null 値を返す必要があります
  • API メソッドは、SDK ドキュメントで null 値が許可されていないクラスの no-op 実装を返さなければなりません (MUST)。
  • 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" ("dots per inch" を意味する) は、1 インチの直線的な水平または垂直スパンに含まれるピクセル数です。
  • 「アスペクト比」とは、画面の長辺と短辺の比率です。たとえば、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.画面の向き

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

デバイスは、android.content.res.Configuration.orientation、android.view.Display.getOrientation()、またはその他の API を介して照会されるたびに、デバイスの現在の向きの正しい値を報告する必要があります。

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

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

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

  • マネージ API ( GLES10.getString()メソッド経由など) は、OpenGL ES 2.0 のサポートを報告してはなりません (MUST NOT)。
  • ネイティブ 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 [ Resources, 30 ] (つまり、QWERTY または 12 キー) で指定された形式のいずれとも一致しないハードウェア キーボードを含めてはなりません。

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

デバイスの実装:

  • 非タッチ ナビゲーション オプションを省略してもよい (つまり、トラックボール、方向パッド、またはホイールを省略してもよい)。
  • android.content.res.Configuration.navigationの正しい値を報告しなければなりません [参考文献、30 ]
  • 入力管理エンジンと互換性のある、テキストの選択と編集のための合理的な代替ユーザー インターフェイス メカニズムを提供しなければなりません。アップストリームの Android オープンソース コードには、非タッチ ナビゲーション入力がないデバイスでの使用に適した選択メカニズムが含まれています。

7.2.3.ナビゲーションキー

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

デバイスの実装者は、専用の検索キーも提供する必要があります。デバイスの実装者は、通話の送信キーと終了キーも提供する場合があります。

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

デバイスの実装:

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

7.3.センサー

Android 2.3 には、さまざまな種類のセンサーにアクセスするための API が含まれています。以下のサブセクションで規定されているように、デバイスの実装は通常、これらのセンサーを省略してもよい (MAY)。デバイスに、サードパーティ デベロッパー向けの対応する API を持つ特定のセンサー タイプが含まれている場合、デバイスの実装は、Android SDK ドキュメントで説明されているように、その API を実装する必要があります。たとえば、デバイスの実装は次のとおりです。

  • android.content.pm.PackageManagerクラスごとにセンサーの有無を正確に報告しなければなりません。 [リソース、27 ]
  • SensorManager.getSensorList()および同様のメソッドを介して、サポートされているセンサーの正確なリストを返さなければなりません (MUST)。
  • 他のすべてのセンサー API に対して合理的に動作しなければなりません (たとえば、アプリケーションがリスナーを登録しようとしたときに true または 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) 以上まで測定できなければなりません (MUST)。
  • 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 のロックオン時間を最小限に抑えるために、何らかの形式の「アシスト GPS」技術を含める必要があります。

7.3.4.ジャイロスコープ

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

  • 最大 5.5*Pi ラジアン/秒 (つまり、約 1,000 度/秒) の向きの変化を測定できなければなりません (MUST)。
  • 100 Hz 以上でイベントを配信できなければなりません
  • 8 ビット以上の精度が必要です

7.3.5.バロメーター

デバイス実装には、気圧計 (つまり、周囲気圧センサー) が含まれる場合があります。デバイス実装に気圧計が含まれる場合、次のようになります。

  • 5 Hz 以上でイベントを配信できなければならない (MUST)
  • 高度の推定を可能にするために十分な精度を持たなければなりません

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 の 1 つ以上の形式 (b/g/a/n など) のサポートを含める必要があります (SHOULD)。デバイスの実装に 802.11 のサポートを含める場合は、対応する Android API を実装する必要があります。

7.4.3.ブルートゥース

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

Compatibility Test Suite には、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フォーラムのリーダー/ライター(NFCフォーラムの技術仕様NFCForum-TS-DigitalProtocol-1.0で定義)として機能できなければなりません:
      • NfcA (ISO14443-3A)
      • NfcB (ISO14443-3B)
      • NfcF(JIS 6319-4)
      • NfcV (ISO 15693)
      • 等深線 (ISO 14443-4)
      • NFC フォーラム タグ タイプ 1、2、3、4 (NFC フォーラムによって定義)
    • 次のピアツーピア標準およびプロトコルを介してデータを送受信できなければなりません:
      • ISO18092
      • LLCP 1.0 (NFC フォーラムが定義)
      • SDP 1.0 (NFC フォーラムが定義)
      • NDEF プッシュ プロトコル [リソース、33 ]
    • NFC 検出モードのときに、サポートされているすべてのテクノロジーをスキャンする必要があります。
    • 画面がアクティブな状態でデバイスが起動している間は、NFC 検出モードにする必要があります。

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

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

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

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

    デバイス実装に NFC ハードウェアが含まれていない場合、 android.content.pm.PackageManager.hasSystemFeature()メソッド [ Resources, 27 ] から android.hardware.nfc 機能を宣言してはならず、Android 2.3 NFC API を次のように実装しなければなりません。ノーオペレーション。

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

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

    デバイスの実装には、1 つまたは複数の形式のデータ ネットワーキングのサポートが含まれている必要があります。具体的には、デバイス実装には、200Kbit/秒以上のデータ標準を少なくとも 1 つサポートする必要があります。この要件を満たすテクノロジーの例には、EDGE、HSPA、EV-DO、802.11g、イーサネットなどがあります。

    物理ネットワーク標準 (イーサネットなど) が主要なデータ接続であるデバイス実装には、802.11 (WiFi) などの一般的なワイヤレス データ標準を少なくとも 1 つサポートする必要があります。

    デバイスは、複数の形式のデータ接続を実装する場合があります。

    7.5.カメラ

    デバイスの実装には、背面カメラを含める必要があり (SHOULD)、前面カメラを含めることができます (MAY)。背面カメラは、ディスプレイの反対側のデバイスの側面にあるカメラです。つまり、従来のカメラのように、デバイスの反対側のシーンを撮影します。前面カメラは、デバイスのディスプレイと同じ側にあるカメラです。つまり、通常、ビデオ会議や同様のアプリケーションなどでユーザーの画像を撮影するために使用されるカメラです。

    7.5.1.背面カメラ

    デバイスの実装には、背面カメラを含める必要があります。デバイス実装に背面カメラが含まれる場合、それは:

    • 少なくとも 2 メガピクセルの解像度が必要です
    • ハードウェア オート フォーカスまたはソフトウェア オート フォーカスのいずれかをカメラ ドライバーに実装する必要があります (アプリケーション ソフトウェアに対して透過的)。
    • 固定焦点または EDOF (拡張被写界深度) ハードウェアを持っている可能性があります
    • フラッシュを含めることができます。カメラにフラッシュが含まれている場合、 FLASH_MODE_AUTOインスタンスがカメラ プレビュー サーフェスに登録されている間、フラッシュ ランプを点灯してはなりませんFLASH_MODE_ON Camera.Parametersオブジェクト。この制約は、デバイスの組み込みシステム カメラ アプリケーションには適用されず、 Camera.PreviewCallbackを使用するサードパーティ アプリケーションにのみ適用されることに注意してください。

    7.5.2.前面カメラ

    デバイスの実装には、前面カメラが含まれる場合があります。デバイス実装に前面カメラが含まれる場合、それは:

    • 少なくとも VGA (つまり、640x480 ピクセル) の解像度が必要です。
    • Camera API のデフォルトとして前面カメラを使用してはなりません。つまり、Android 2.3 のカメラ API は前面カメラに固有のサポートを備えており、デバイス実装は、前面カメラをデフォルトの背面カメラとして扱うように API を構成してはなりません。デバイス。
    • セクション 7.5.1 で説明されているように、背面カメラで使用できる機能 (オート フォーカス、フラッシュなど) を含めることができます。
    • 次のように、CameraPreview でアプリによって表示されるストリームを水平方向に反映 (ミラーリング) する必要があります。
      • デバイスの実装がユーザーによって回転できる場合 (加速度計を介して自動的に、またはユーザー入力を介して手動で)、カメラのプレビューは、デバイスの現在の向きに対して水平にミラーリングされなければなりません。
      • 現在のアプリケーションがandroid.hardware.Camera.setDisplayOrientation() [ Resources, 40 ] メソッドの呼び出しを介してカメラ ディスプレイの回転を明示的に要求している場合、カメラ プレビューは、アプリケーションで指定された向きに対して水平方向にミラーリングする必要があります。
      • それ以外の場合、プレビューはデバイスのデフォルトの水平軸に沿ってミラーリングする必要があります。
    • カメラ プレビュー画像ストリームと同じ方法で、「ポストビュー」カメラ コールバック ハンドラに返された画像データをミラーリングしなければなりません。 (デバイス実装がポストビュー コールバックをサポートしていない場合、この要件は明らかに適用されません。)
    • アプリケーション コールバックに返された、またはメディア ストレージにコミットされた、最終的にキャプチャされた静止画像またはビデオ ストリームをミラーリングしてはなりません。

    7.5.3.カメラ API の動作

    デバイス実装は、前面カメラと背面カメラの両方について、カメラ関連の 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 エンコード形式である必要があります。つまり、NV21 がデフォルトでなければなりません。
    3. デバイス実装は、前面カメラと背面カメラの両方のカメラ プレビュー用に YV12 形式( android.graphics.ImageFormat.YV12定数で示される)をサポートする必要があります(SHOULD)。将来のバージョンの互換性定義では、この要件を「MUST」に変更する予定であることに注意してください。つまり、YV12 のサポートは Android 2.3 ではオプションですが、将来のバージョンでは必須になります。 Android 2.3 を実行する既存および新規のデバイスは、Android 2.3 でこの要件を満たすことが強く推奨されます。そうしないと、将来のバージョンにアップグレードしたときに Android との互換性を実現できなくなります。

    デバイス実装は、デバイスにハードウェア オートフォーカスやその他の機能が含まれているかどうかに関係なく、Android 2.3 SDK ドキュメント [参考文献、41 ] に含まれている完全な Camera API を実装する必要があります。たとえば、オートフォーカスがないカメラは、登録されているandroid.hardware.Camera.AutoFocusCallbackインスタンスを引き続き呼び出さなければなりません (ただし、これは非オートフォーカス カメラとは関係ありません)。これは前面カメラに適用されることに注意してください。たとえば、ほとんどの前面カメラはオートフォーカスをサポートしていませんが、API コールバックは前述のように「偽装」する必要があります。

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

    7.5.4.カメラの向き

    前面カメラと背面カメラの両方が存在する場合は、カメラの長さが画面の長さと一致するように配置する必要があります。つまり、デバイスが横向きに保持されている場合、カメラは横向きで画像をキャプチャする必要があります。これは、デバイスの自然な向きに関係なく適用されます。つまり、横向きのプライマリ デバイスと縦向きのプライマリ デバイスに適用されます。

    7.6.メモリとストレージ

    Android 2.3 の基本的な機能は、アプリケーションを実行することです。デバイス実装は、アプリケーションが適切に実行されるために十分なストレージとメモリを確保するために、このセクションの要件を満たさなければなりません。

    7.6.1.最小メモリとストレージ

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

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

    上記の要件を超えて、デバイス実装には、ユーザー データ用に少なくとも 1 GB の不揮発性ストレージを使用する必要があります。このより高い要件は、Android の将来のバージョンでハード ミニマムになる予定であることに注意してください。デバイスの実装は、これらの要件を満たすことが強く推奨されます。そうしないと、Android の将来のバージョンとの互換性が得られない可能性があります。

    Android API には、アプリケーションがデータ ファイルをダウンロードするために使用できるダウンロード マネージャーが含まれています。 Download Manager の実装は、サイズが 55MB 以上の個々のファイルをダウンロードできる必要があります。 Download Manager の実装は、サイズが 100MB 以上のファイルをダウンロードできる必要があります。

    7.6.2.アプリケーション共有ストレージ

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

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

    デバイス実装は、文書化されているように、この共有ストレージに対するandroid.permission.WRITE_EXTERNAL_STORAGE権限を強制する必要があります。それ以外の場合、共有ストレージは、その許可を取得するアプリケーションによって書き込み可能でなければなりません。

    デバイス実装には、Secure Digital カードなど、ユーザーがアクセスできるリムーバブル ストレージ用のハードウェアが含まれる場合があります。あるいは、デバイス実装は、アプリの共有ストレージとして内部 (取り外し不可能な) ストレージを割り当てることができます。

    使用される共有ストレージの形式に関係なく、デバイス実装は、USB 大容量ストレージやメディア転送プロトコルなど、ホスト コンピューターから共有ストレージのコンテンツにアクセスするための何らかのメカニズムを提供する必要があります。

    よくある例を 2 つ考えてみましょう。デバイスの実装に共有ストレージの要件を満たす SD カード スロットが含まれている場合、サイズが 1GB 以上の FAT フォーマットの SD カードをユーザーに販売するときにデバイスに含める必要があり、デフォルトでマウントする必要があります。あるいは、デバイス実装がこの要件を満たすために内部固定ストレージを使用する場合、そのストレージはサイズが 1GB 以上であり、 /sdcardにマウントされている必要があります (または、 /sdcardが他の場所にマウントされている場合は、物理的な場所へのシンボリック リンクである必要があります)。

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

    7.7. USB

    デバイスの実装:

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

    8. 性能の互換性

    互換性のある実装では、アプリケーションがデバイス上で単に正しく実行されるだけでなく、適切なパフォーマンスと全体的に優れたユーザー エクスペリエンスで実行されるようにする必要があります。デバイス実装は、以下の表で定義されている Android 2.3 互換デバイスの主要なパフォーマンス メトリックを満たさなければなりません。

    メトリックパフォーマンスのしきい値コメント
    アプリケーションの起動時間次のアプリケーションは、指定された時間内に起動する必要があります。
    • ブラウザ: 1300 ミリ秒未満
    • MMS/SMS: 700 ミリ秒未満
    • AlarmClock: 650ms 未満
    起動時間は、アプリケーションのデフォルト アクティビティの読み込みを完了するまでの合計時間として測定されます。これには、Linux プロセスの開始、Android パッケージの Dalvik VM への読み込み、および onCreate の呼び出しにかかる時間が含まれます。
    同時申込複数のアプリケーションが起動された場合、既に実行されているアプリケーションを起動した後に再起動するには、元の起動時間よりも短くする必要があります。

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

    デバイス実装は、Android 開発者向けドキュメントの API の [参考文献、42 ] のセキュリティとパーミッションの参照ドキュメントで定義されているように、Android プラットフォームのセキュリティ モデルと一致するセキュリティ モデルを実装しなければなりません。デバイス実装は、第三者/当局からの追加の許可/証明書を必要とせずに、自己署名アプリケーションのインストールをサポートする必要があります。具体的には、互換性のあるデバイスは、次のサブセクションで説明されているセキュリティ メカニズムをサポートする必要があります。

    9.1.権限

    デバイス実装は、Android 開発者向けドキュメント [ Resources, 42 ] で定義されているように、Android パーミッション モデルをサポートしなければなりません (MUST)。具体的には、実装は、SDK ドキュメントで説明されているように定義された各アクセス許可を適用する必要があります。権限を省略、変更、または無視することはできません。新しいパーミッション ID 文字列が android.* 名前空間にない場合、実装は追加のパーミッションを追加できます。

    9.2. UID とプロセスの分離

    デバイス実装は、各アプリケーションが一意の Unix スタイルの UID として個別のプロセスで実行される Android アプリケーション サンドボックス モデルをサポートする必要があります。 Security and Permissions リファレンス [ Resources, 42 ] で定義されているように、アプリケーションが適切に署名され、構築されている場合、デバイス実装は、複数のアプリケーションを同じ Linux ユーザー ID として実行することをサポートしなければなりません (MUST)。

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

    デバイス実装は、Security and Permissions リファレンス [ Resources, 42 ] で定義されている Android ファイル アクセス パーミッション モデルをサポートしなければなりません。

    9.4.代替実行環境

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

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

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

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

    代替ランタイムは、Android サンドボックス モデルに従わなければなりません。具体的には:

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

    代替ランタイムは、スーパーユーザー (root) または他のユーザー ID の権限を使用して起動したり、付与したり、他のアプリケーションに付与したりしてはなりません。

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

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

    10. ソフトウェア互換性テスト

    Android オープンソース プロジェクトには、デバイスの実装に互換性があることを確認するためのさまざまなテスト ツールが含まれています。デバイス実装は、このセクションで説明されているすべてのテストに合格する必要があります。

    ただし、完全に包括的なソフトウェア テスト パッケージはないことに注意してください。このため、デバイスの実装者は、Android オープンソース プロジェクトから入手できる Android 2.3 の参照および推奨される実装に対して、可能な限り最小限の変更を加えることが強く推奨されます。これにより、やり直しや潜在的なデバイスの更新を必要とする互換性の問題を引き起こすバグが発生するリスクが最小限に抑えられます。

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

    デバイス実装は、デバイス上の最終出荷ソフトウェアを使用して、Android オープン ソース プロジェクトから入手できる Android 互換性テスト スイート (CTS) [リソース、2 ] に合格する必要があります。さらに、デバイスの実装者は、可能な限り Android オープン ソース ツリーの参照実装を使用する必要があり、CTS のあいまいな場合や参照ソース コードの一部の再実装について互換性を確保する必要があります。

    CTS は、実際のデバイスで実行するように設計されています。他のソフトウェアと同様に、CTS 自体にバグが含まれている場合があります。 CTS は、この互換性定義とは別にバージョン管理され、CTS の複数のリビジョンが Android 2.3 用にリリースされる可能性があります。デバイス実装は、デバイス ソフトウェアが完成した時点で利用可能な最新の CTS バージョンを渡す必要があります。

    デバイス実装のソフトウェアが完成した時点で利用可能な Android 互換性テスト スイート (CTS) の最新バージョンに合格しなければなりません。 (CTS は、Android オープン ソース プロジェクト [参考文献、2 ] の一部として入手できます。) CTS は、このドキュメントで説明されているコンポーネントのすべてではありませんが、多くのコンポーネントをテストします。

    10.2. CTS 検証者

    デバイス実装は、CTS Verifier で該当するすべてのケースを正しく実行する必要があります。 CTS Verifier は Compatibility Test Suite に含まれており、カメラやセンサーの正常な機能など、自動化されたシステムではテストできない機能をテストするために人間のオペレーターが実行することを目的としています。

    CTS Verifier には、オプションのハードウェアを含む、さまざまな種類のハードウェアに対するテストがあります。デバイス実装は、所有するハードウェアのすべてのテストに合格する必要があります。たとえば、デバイスが加速度計を備えている場合、CTS 検証ツールで加速度計テスト ケースを正しく実行する必要があります。この互換性定義ドキュメントでオプションとして示されている機能のテスト ケースは、スキップまたは省略される場合があります。

    上記のように、すべてのデバイスとすべてのビルドで CTS Verifier を正しく実行する必要があります。ただし、多くのビルドは非常に似ているため、デバイスの実装者は、わずかな違いしかないビルドで CTS Verifier を明示的に実行することは想定されていません。具体的には、含まれるロケールのセット、ブランディングなどのみが CTS Verfier に合格した実装と異なるデバイス実装は、CTS Verifier テストを省略できます。

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

    デバイスの実装者は、次のオープンソース アプリケーションを使用して実装の互換性をテストする必要があります。

    • 「Android 用アプリ」アプリケーション [リソース、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.

    Setup and Installation

    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.