Android 4.0 互換性定義ドキュメント

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

リビジョン 4
最終更新日: 2013 年 4 月 21 日

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

目次

1. はじめに
2. 参考資料
3. ソフトウェア
3.1. マネージド API の互換性
3.2. ソフト API の互換性
3.3. ネイティブ API の互換性
3.4. ウェブの互換性
3.5. API 動作の互換性
3.6. API の名前空間
3.7. 仮想マシンの互換性
3.8. ユーザー インターフェースの互換性
3.9. デバイス管理
3.10. ユーザー補助
3.11. テキスト読み上げ
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 4.0 との互換性を維持するために満たす必要がある要件を列挙しています。

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

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

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

この定義、またはセクション 10 に記載されているソフトウェア テストが、言及されていない、曖昧である、または不完全である場合、既存の実装との互換性を確保することはデバイス実装者の責任です。

この理由により、Android オープンソース プロジェクト [参考資料、3] は Android のリファレンス実装であり、なおかつ優先実装です。デバイス実装者は、可能な限り、Android オープンソース プロジェクトから入手できる「アップストリーム」のソースコードに基づいて実装することを強くおすすめします。一部のコンポーネントは暫定的に代替実装に置き換えることができますが、ソフトウェア テストに合格することが非常に困難になるため、この方法を実施することは回避するよう強くおすすめします。互換性テストスイートなどを含む標準的な Android 実装との完全な動作互換性を確保することは、実装者の責任です。なお、このドキュメントでは特定のコンポーネントの置き換えと変更が明示的に禁止されています。

2. 参考資料

  1. IETF RFC2119 要件レベル: http://www.ietf.org/rfc/rfc2119.txt
  2. Android 互換性プログラムの概要: http://source.android.com/compatibility/index.html
  3. Android オープンソース プロジェクト: http://source.android.com/
  4. API の定義とドキュメント: http://developer.android.com/reference/packages.html
  5. Android 権限リファレンス: http://developer.android.com/reference/android/Manifest.permission.html
  6. android.os.Build リファレンス: http://developer.android.com/reference/android/os/Build.html
  7. Android 4.0 で許可されているバージョン文字列: http://source.android.com/compatibility/4.0/versions.html
  8. Renderscript: http://developer.android.com/guide/topics/graphics/renderscript.html
  9. ハードウェア アクセラレーション: http://developer.android.com/guide/topics/graphics/hardware-accel.html
  10. android.webkit.WebView クラス: http://developer.android.com/reference/android/webkit/WebView.html
  11. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
  12. HTML5 のオフライン機能: http://dev.w3.org/html5/spec/Overview.html#offline
  13. HTML5 の video タグ: http://dev.w3.org/html5/spec/Overview.html#video
  14. HTML5/W3C の位置情報 API: http://www.w3.org/TR/geolocation-API/
  15. HTML5/W3C の webdatabase API: http://www.w3.org/TR/webdatabase/
  16. HTML5/W3C の IndexedDB API: http://www.w3.org/TR/IndexedDB/
  17. Dalvik 仮想マシンの仕様: Android ソースコード(dalvik/docs)で入手可能
  18. アプリ ウィジェット: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  19. 通知: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
  20. アプリケーション リソース: http://code.google.com/android/reference/available-resources.html
  21. ステータスバー アイコンのスタイルガイド: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
  22. 検索マネージャー: http://developer.android.com/reference/android/app/SearchManager.html
  23. トースト: http://developer.android.com/reference/android/widget/Toast.html
  24. テーマ: http://developer.android.com/guide/topics/ui/themes.html
  25. R.style クラス: http://developer.android.com/reference/android/R.style.html
  26. ライブ壁紙: http://developer.android.com/resources/articles/live-wallpapers.html
  27. Android デバイス管理: http://developer.android.com/guide/topics/admin/device-admin.html
  28. android.app.admin.DevicePolicyManager クラス: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
  29. Android のユーザー補助サービス API: http://developer.android.com/reference/android/accessibilityservice/package-summary.html
  30. Android のユーザー補助 API: http://developer.android.com/reference/android/view/accessibility/package-summary.html
  31. Eyes Free プロジェクト: http://code.google.com/p/eyes-free
  32. テキスト読み上げ API: http://developer.android.com/reference/android/speech/tts/package-summary.html
  33. リファレンス ツールのドキュメント(adb、aapt、ddms): http://developer.android.com/guide/developing/tools/index.html
  34. Android apk ファイルの説明: http://developer.android.com/guide/topics/fundamentals.html
  35. マニフェスト ファイル: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  36. Monkey テストツール: http://developer.android.com/guide/developing/tools/monkey.html
  37. Android の android.content.pm.PackageManager クラスとハードウェア機能のリスト: http://developer.android.com/reference/android/content/pm/PackageManager.html
  38. 複数画面のサポート: http://developer.android.com/guide/practices/screens_support.html
  39. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  40. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  41. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html
  42. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html
  43. NDEF プッシュ プロトコル: http://source.android.com/compatibility/ndef-push-protocol.pdf
  44. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
  45. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
  46. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
  47. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
  48. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
  49. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
  50. カメラの向きに関する API: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
  51. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
  52. Android のオープン アクセサリ: http://developer.android.com/guide/topics/usb/accessory.html
  53. USB ホスト API: http://developer.android.com/guide/topics/usb/host.html
  54. Android のセキュリティと権限に関するリファレンス: http://developer.android.com/guide/topics/security/security.html
  55. Apps 用アプリ: http://code.google.com/p/apps-for-android
  56. android.app.DownloadManager クラス: http://developer.android.com/reference/android/app/DownloadManager.html
  57. Android File Transfer: http://www.android.com/filetransfer
  58. Android のメディア形式: http://developer.android.com/guide/appendix/media-formats.html
  59. HTTP Live Streaming のドラフト プロトコル: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03
  60. モーション イベント API: http://developer.android.com/reference/android/view/MotionEvent.html
  61. タップ入力の構成: http://source.android.com/tech/input/touch-devices.html

上記のリソースの多くは、Android 4.0 SDK に直接的または間接的に由来するものであり、対象の SDK ドキュメントに記載されている情報と機能的に同等です。この互換性定義または互換性テストスイートと SDK ドキュメントの間に相違がある場合、SDK ドキュメントが正式なものであるとみなされます。上記の資料に記載されているすべての技術的な詳細は、この互換性定義の一部とみなされます。

3. ソフトウェア

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

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

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

この互換性定義では、Android に API が含まれている一部のタイプのハードウェアについては、デバイス実装で省略することを許可します。そのような場合は、API が存在し、かつ妥当な動作を示さなければなりません。このシナリオに固有の要件については、セクション 7 をご覧ください。

3.2. ソフト API の互換性

セクション 3.1 のマネージド API に加えて、Android には、アプリのコンパイル時には適用できない、Android アプリのインテントや権限などの形式で、重要なランタイム専用の「ソフト」API も含まれています。

3.2.1. 権限

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

3.2.3. ビルド パラメータ

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

パラメータ コメント
android.os.Build.VERSION.RELEASE 現在実行している Android システムのバージョン(人が読める形式)。このフィールドには、[参考資料、7] で定義されている文字列値のいずれかを指定しなければなりません。
android.os.Build.VERSION.SDK 現在実行している Android システムのバージョン(サードパーティ アプリのコードからアクセスできる形式)。Android 4.0.1~4.0.2 の場合、このフィールドには整数値 14 を指定しなければなりません。Android 4.0.3 以降の場合、このフィールドには整数値 15 を指定しなければなりません。
android.os.Build.VERSION.SDK_INT 現在実行している Android システムのバージョン(サードパーティ アプリのコードからアクセスできる形式)。Android 4.0.1~4.0.2 の場合、このフィールドには整数値 14 を指定しなければなりません。Android 4.0.3 以降の場合、このフィールドには整数値 15 を指定しなければなりません。
android.os.Build.VERSION.INCREMENTAL 現在実行している Android システムの特定のビルドを指定する、デバイス実装者が選択した値(人が読める形式)。この値については、エンドユーザーが利用できる別のビルドに再利用することは回避しなければなりません。このフィールドは主に、ビルドの生成に使用されたビルド番号またはソース管理変更 ID を示すために使用します。このフィールドの具体的な形式についての要件はありませんが、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.CPU_ABI ネイティブ コードの命令セット(CPU タイプ + ABI 規則)の名前。セクション 3.3. ネイティブ API の互換性をご覧ください。
android.os.Build.CPU_ABI2 ネイティブ コードの 2 番目の命令セット(CPU タイプ + ABI 規則)の名前。セクション 3.3. ネイティブ API の互換性をご覧ください。
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:4.0/IRK77/3359:userdebug/test-keys
フィンガープリントには、空白文字を追加してはなりません。上記のテンプレートに含まれる他のフィールドに空白文字がある場合は、ビルドのフィンガープリントでアンダースコア(_)などの別の文字に置き換えなければなりません。このフィールドの値は 7 ビット ASCII としてエンコード可能でなければなりません。
android.os.Build.HARDWARE ハードウェアの名前(カーネル コマンドラインまたは /proc から)。合理的な程度に人が読める形式にするべきです。このフィールドの値は、7 ビット ASCII としてエンコード可能でなければならず、かつ正規表現 "^[a-zA-Z0-9.,_-]+$" と一致しなければなりません。
android.os.Build.HOST ビルドが構築されたホストを一意に識別する文字列(人が読める形式)。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列("")であってはなりません。
android.os.Build.ID 特定のリリースを参照するためにデバイス実装者が選択する識別子(人が読める形式)。このフィールドは android.os.Build.VERSION.INCREMENTAL と同じにすることができますが、エンドユーザーがソフトウェア ビルドを区別できるよう十分な程度に意味のある値にするべきです。このフィールドの値は、7 ビット ASCII としてエンコード可能でなければならず、かつ正規表現 "^[a-zA-Z0-9.,_-]+$" と一致しなければなりません。
android.os.Build.MANUFACTURER 製品の相手先ブランド製品製造企業(OEM)の商号。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列("")であってはなりません。
android.os.Build.MODEL エンドユーザーが把握しているデバイスの名前を含む、デバイス実装者が選択した値。これは、デバイスが市販されエンドユーザーに販売される際の名前と同じにするべきです。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列("")であってはなりません。
android.os.Build.PRODUCT 製品(SKU)の開発名またはコードネームを含む、デバイス実装者が選択した値。人が読める形式であることが必要ですが、必ずしもエンドユーザーに表示することを意図したものではありません。このフィールドの値は、7 ビット ASCII としてエンコード可能でなければならず、かつ正規表現 "^[a-zA-Z0-9.,_-]+$" と一致しなければなりません。
android.os.Build.SERIAL ハードウェアのシリアル番号(利用可能な場合)。このフィールドの値は、7 ビット ASCII としてエンコード可能でなければならず、かつ正規表現 "^([a-zA-Z0-9]{0,20})$" と一致しなければなりません。
android.os.Build.TAGS ビルドを詳細に区別する、デバイス実装者が選択したタグのカンマ区切りのリスト。例: 「unsigned,debug」。このフィールドの値は、7 ビット ASCII としてエンコード可能でなければならず、かつ正規表現 "^[a-zA-Z0-9.,_-]+$" と一致しなければなりません。
android.os.Build.TIME ビルドが作成されたときのタイムスタンプを表す値。
android.os.Build.TYPE ビルドのランタイム構成を指定する、デバイス実装者が選択した値。このフィールドには、典型的な 3 つの Android ランタイム構成(「user」「userdebug」「eng」)に対応する値のいずれかを指定するべきです。このフィールドの値は、7 ビット ASCII としてエンコード可能でなければならず、かつ正規表現 "^[a-zA-Z0-9.,_-]+$" と一致しなければなりません。
android.os.Build.USER ビルドを生成したユーザー(または自動ユーザー)の名前またはユーザー ID。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列("")であってはなりません。

3.2.3. インテントの互換性

デバイス実装では、以下の各セクションに記載されているように、Android の疎結合インテント システムを尊重しなければなりません。「尊重する」とは、デバイス実装者が、一致するインテント フィルタを指定し、指定されたインテント パターンごとに正しい動作をバインドして実装する Android アクティビティまたはサービスを提供しなければならないことを意味します。

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

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

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

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

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

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

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

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

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

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

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

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

この禁止事項は、セクション 3.6 の Java 言語クラスに規定されているものと同様のものです。

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

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

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

3.3.1 アプリケーション バイナリ インターフェース

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

Android ABI をサポートする場合、デバイス実装には以下の要件が求められます。

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

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

  • libc(C ライブラリ)
  • libm(math ライブラリ)
  • 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(OpenSL ES 1.0.1 オーディオ サポート)
  • libOpenMAXAL.so(OpenMAX AL 1.0.1 サポート)
  • libandroid.so(ネイティブ Android アクティビティ サポート)
  • 以下で説明する OpenGL のサポート

Android NDK の今後のリリースで、追加の ABI のサポートが導入される可能性があります。デバイス実装では、既存の事前定義済み ABI と互換性がない場合、いかなる ABI のサポートについてもレポートすることを回避しなければなりません。

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

3.4. ウェブの互換性

3.4.1. WebView の互換性

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

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

WebView コンポーネントは、可能な限り HTML5 [参考資料、11] をサポートするべきです。デバイス実装は、少なくとも WebView の HTML5 に関連する以下の API をそれぞれサポートするべきです。

さらに、デバイス実装は、HTML5/W3C の webstorage API [参考資料、15] をサポートしなければならず、また HTML5/W3C の IndexedDB API [参考資料、16] をサポートするべきです。なお、ウェブ開発標準化団体が webstorage よりも IndexedDB を優先するようになっているため、今後の Android バージョンでは IndexedDB が必須コンポーネントになると見込まれます。

すべての JavaScript API と同様に、HTML5 API は、デベロッパーが通常の Android API を介して明示的に有効にしない限り、WebView でデフォルトで無効にしなければなりません。

3.4.2. ブラウザの互換性

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

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

スタンドアロン ブラウザアプリは(アップストリームの WebKit ブラウザアプリとサードパーティの代替アプリのどちらをベースとしているかにかかわらず)、可能な限り HTML5 [参考資料、11] をサポートするべきです。デバイス実装は、少なくとも HTML5 に関連する以下の API をそれぞれサポートしなければなりません。

さらに、デバイス実装は、HTML5/W3C の webstorage API [参考資料、15] をサポートしなければならず、また HTML5/W3C の IndexedDB API [参考資料、16] をサポートするべきです。なお、ウェブ開発標準化団体が webstorage よりも IndexedDB を優先するようになっているため、今後の Android バージョンでは IndexedDB が必須コンポーネントになると見込まれます。

3.5. API 動作の互換性

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

  • デバイスによる、標準的なインテントの動作またはセマンティクスの変更を回避しなければなりません。
  • デバイスによる、特定のタイプのシステム コンポーネント(Service、Activity、ContentProvider など)のライフサイクルまたはライフサイクル セマンティクスの変更は回避しなければなりません。
  • デバイスによる標準権限のセマンティクスの変更を回避しなければなりません。

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

3.6. API 名前空間

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

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

次のような変更は禁止されています。

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

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

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

デバイス実装者が上記のパッケージ空間のいずれかの改善(既存の API への有用な新機能の追加や、新しい API の追加など)を提案する場合、実装者は source.android.com にアクセスし、対象のサイトに掲載されている情報に基づいて変更とコードに寄与するプロセスを開始するべきです。

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

3.7. 仮想マシンの互換性

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

デバイス実装では、アップストリームの Android プラットフォームに合わせて以下の表に示すようにメモリが割り当てられるように Dalvik を構成しなければなりません(画面サイズと画面密度の定義については、セクション 7.1.1 をご覧ください)。

なお、以下のメモリ値は最小値とみなされ、デバイス実装はアプリごとにより多くのメモリを割り当てても問題ありません。

画面サイズ 画面密度 アプリケーション メモリ
小 / 標準 / 大 ldpi / mdpi 16MB
小 / 標準 / 大 tvdpi / hdpi 32 MB
小 / 標準 / 大 xhdpi 64 MB
特大 mdpi 32 MB
特大 tvdpi / hdpi 64 MB
特大 xhdpi 128 MB

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

3.8.1. ウィジェット

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

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

デバイス実装は、標準グリッドサイズで 4 x 4 のウィジェットをレンダリングできなければなりません(詳細については、Android SDK ドキュメントのアプリ ウィジェット設計ガイドライン [参考資料、18] をご覧ください)。

3.8.2. 通知

Android には、デベロッパーがデバイスのハードウェア機能とソフトウェア機能を使用して重要なイベントをユーザーに通知 [参考資料、19] するための API が含まれています。

一部の API では、ハードウェア(具体的にはサウンド、バイブレーション、ライト)を使用して、通知を行う、またはユーザーの注意を引くことができます。デバイス実装は、SDK ドキュメントに記載されているように、デバイス実装ハードウェアで可能な範囲で、ハードウェア機能を使用する通知をサポートしなければなりません。たとえば、デバイス実装がバイブレーターを含む場合は、バイブレーション API を正しく実装しなければなりません。デバイス実装にハードウェアが欠落している場合は、対応する API を NoOps として実装しなければなりません。この動作の詳細については、セクション 7 をご覧ください。

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

Android 4.0 には、リッチ通知(進行中の通知のインタラクティブなビューなど)のサポートが含まれています。デバイス実装は、Android API ドキュメントに記載されているように、リッチ通知を適切に表示し、実行しなければなりません。

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

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

3.8.4. トースト

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

3.8.5. テーマ

Android は、アプリがアクティビティまたはアプリ全体にスタイルを適用するためのメカニズムとして、「テーマ」を提供しています。Android 3.0 には、アプリ デベロッパーが Android SDK で定義されている Holo テーマのデザインに合わせる必要がある場合に使用する定義済みスタイルのセットとして、Holo(Holographic)テーマが用意されています [参考資料、24]。デバイス実装では、アプリに対して公開されている Holo テーマ属性を変更してはなりません [参考資料、25]。

Android 4.0 には、アプリ デベロッパーがデバイス実装者によって定義されたデバイステーマのデザインに合わせたい場合に使用する定義済みスタイルのセットとして、新しい DeviceDefault テーマが用意されています。デバイス実装は、アプリに対して公開されている DeviceDefault テーマの属性を変更しても問題ありません [参考資料、25]。

3.8.6. ライブ壁紙

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

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

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

3.8.7. 最近使用したアプリの表示

アップストリームの Android 4.0 ソースコードには、ユーザーが最後にアプリを離れたときのアプリのグラフィック状態のサムネイル画像を使用して、最近使ったアプリを表示するユーザー インターフェースが含まれています。デバイス実装は、このユーザー インターフェースを変更または削除しても問題ありません。ただし、Android の将来のバージョンでは、この機能をより幅広く使用できるようにする予定です。デバイス実装では、最近使用したアプリについて、アップストリームの Android 4.0 ユーザー インターフェース(またはそれと類似したサムネイル ベースのインターフェース)を使用することが強く推奨されます。そのようにしないと、将来のバージョンの Android との互換性が失われる可能性があります。

3.8.8. 入力管理設定

Android 4.0 は、入力管理エンジンをサポートしています。Android 4.0 API を使用すると、カスタムアプリの IME で、ユーザーが調整できる設定を指定できます。デバイス実装では、そのようなユーザー設定を実現する IME が表示される場合に、常に IME 設定にアクセスする方法が用意されている必要があります。

3.9 デバイス管理

Android 4.0 には、セキュリティ対応アプリが Android Device Administration API を介してシステムレベルでデバイス管理機能(パスワード ポリシーの適用やリモートワイプの実施など)を実行できる機能が用意されています [参考資料、27]。デバイス実装では、DevicePolicyManager クラス [参考資料、28] の実装を実現する必要があり、Android SDK ドキュメント [参考資料、27] で定義されているデバイス管理ポリシーの全範囲をサポートしなければなりません。

デバイス管理ポリシーの全範囲をサポートしない場合、デバイス実装では、デバイス管理アプリを有効にすることを許可しないようにする必要があり。具体的には、デバイスがすべてのデバイス管理ポリシーをサポートしていない場合、デバイス実装は android.app.admin.DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN インテントに応答しなければなりません。ただし、デバイスがデバイス管理をサポートしていないことをユーザーに通知するメッセージを表示しなければなりません。

3.10 ユーザー補助

Android 4.0 には、障がいのあるユーザーがより簡単にデバイスを操作できるようにするためのユーザー補助レイヤが用意されています。さらに、Android 4.0 は、ユーザー補助サービスの実装によってユーザーとシステム イベントのコールバックを受信し、テキスト読み上げ、触覚フィードバック、トラックボール / D-pad ナビゲーション [参考資料、29] などの代替フィードバック メカニズムを生成できるプラットフォーム API を備えています。デバイス実装では、デフォルトの Android 実装との一貫性がある Android ユーザー補助フレームワークの実装を実現しなければなりません。具体的には、デバイス実装は次の要件を満たさなければなりません。

  • デバイス実装は、android.accessibilityservice API を介してサードパーティのユーザー補助サービス実装をサポートしなければなりません [参考資料、30]。
  • デバイス実装では、デフォルトの Android 実装との一貫性がある方法で、AccessibilityEvent を生成し、登録されているすべての AccessibilityService 実装に該当イベントを配信する必要があります。
  • デバイス実装は、ユーザーによるアクセスが可能な、ユーザー補助サービスを有効または無効にするメカニズムを提供しなければならず、android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS インテントに応じてこのインターフェースを表示しなければなりません。

さらに、デバイス実装では、デバイス上でユーザー補助サービスの実装を実現する必要があり、デバイスのセットアップ時にユーザーがユーザー補助サービスを有効にするメカニズムを備えている必要があります。ユーザー補助サービスのオープンソース実装は、Eyes Free プロジェクト [参考資料、31] から入手できます。

3.11 テキスト読み上げ

Android 4.0 には、アプリがテキスト読み上げ(TTS)サービスを利用できるようにするとともに、サービス プロバイダが TTS サービスの実装を提供できるようにする API が含まれています [参考資料、32]。デバイス実装は、Android TTS フレームワークに関連する以下の要件を満たさなければなりません。

  • デバイス実装は、Android TTS フレームワーク API をサポートし、デバイスで利用できる言語をサポートする TTS エンジンを備えていることが必要です。アップストリームの Android オープンソース ソフトウェアには、フル機能の TTS エンジン実装が含まれています。
  • デバイス実装は、サードパーティ TTS エンジンのインストールをサポートしなければなりません。
  • デバイス実装には、ユーザーがシステムレベルで使用する TTS エンジンを選択できる、ユーザーがアクセス可能なインターフェースが用意されていなければなりません。

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

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

デバイス実装では、.apk [参考資料、34 ]、Android マニフェスト [参考資料、35 ]、Dalvik バイトコード [参考資料、17 ]、renderscript バイトコードのいずれかの形式を、他の互換デバイスで該当ファイルを正しくインストールすることを阻害する方法で拡張してはなりません。デバイス実装者は、Dalvik のリファレンス アップストリーム実装と、リファレンス実装のパッケージ管理システムを使用する必要があります。

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

デバイス実装には、少なくとも 1 つの形態の音声出力(スピーカー、ヘッドフォン端子、外部スピーカー接続など)が含まれていなければなりません。

5.1. メディア コーデック

デバイス実装は、このドキュメントで明示的に許可されている場合を除き、Android SDK ドキュメント [参考資料、58] で規定されているコアメディア形式をサポートしなければなりません。具体的には、デバイス実装は、以下の表で定義されているメディア形式、エンコーダ、デコーダ、ファイル形式、コンテナ形式をサポートしなければなりません。以下のすべてのコーデックは、Android オープンソース プロジェクトの推奨 Android 実装でソフトウェア実装として提供されています。

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

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

タイプ 形式 / コーデック エンコーダ デコーダ 詳細 ファイル形式 / コンテナの形式
オーディオ AAC LC/LTP 必須
マイク ハードウェアを含み、android.hardware.microphone を定義するデバイス実装では必須。
必須 標準ビットレート 160 kbps とサンプリング レート 8~48 kHz の任意の組み合わせのモノラル / ステレオ コンテンツ
  • 3GPP(.3gp)
  • MPEG-4(.mp4、.m4a)
  • ADTS Raw AAC(.aac、Android 3.1 以降でデコード、Android 4.0 以降でエンコード、ADIF はサポート対象外)
  • MPEG-TS(.ts、シーク不可、Android 3.0 以降)
HE-AACv1(AAC+)   必須
HE-AACv2(Enhanced AAC+)   必須
AMR-NB 必須
マイク ハードウェアを含み、android.hardware.microphone を定義するデバイス実装では必須。
必須 8 kHz でサンプリングされた 4.75~12.2 kbps。 3GPP(.3gp)
AMR-WB 必須
マイク ハードウェアを含み、android.hardware.microphone を定義するデバイス実装では必須。
必須 16 kHz でサンプリングされた、6.60~23.85 kbps の 9 種類のレート。 3GPP(.3gp)
FLAC   必須
(Android 3.1 以降)
モノラル / ステレオ(マルチチャンネルはサポート対象外)。サンプルレートは最大 48 kHz(ただし、出力が 44.1 kHz のデバイスでは、48 kHz から 44.1 kHz へのダウンサンプラーにローパス フィルタが含まれないため、最大 44.1 kHz を推奨)。16 ビットを推奨(24 ビットにはディザが適用されません)。 FLAC(.flac)のみ
MP3   必須 モノラル / ステレオの 8~320 Kbps 固定ビットレート(CBR)または可変ビットレート(VBR)。 MP3(.mp3)
MIDI   必須 MIDI タイプ 0 と 1。DLS バージョン 1 と 2。XMF と Mobile XMF。着信音形式 RTTTL/RTX、OTA、iMelody をサポート。
  • タイプ 0 と 1(.mid、.xmf、.mxmf)
  • RTTTL/RTX(.rtttl、.rtx)
  • OTA(.ota)
  • iMelody(.imy)
Vorbis   必須  
  • Ogg(.ogg)
  • Matroska(.mkv)
PCM(WAVE)   必須 8 ビットと 16 ビットのリニア PCM(最大レートはハードウェアの上限値) WAVE(.wav)
画像 JPEG 必須 必須 ベースラインとプログレッシブ JPEG(.jpg)
GIF   必須   GIF(.gif)
PNG 必須 必須   PNG(.png)
BMP   必須   BMP(.bmp)
WebP 必須 必須   WebP(.webp)
動画 H.263 必須
カメラ ハードウェアを含み、android.hardware.camera または android.hardware.camera.front を定義するデバイス実装では必須。
必須  
  • 3GPP(.3gp)
  • MPEG-4(.mp4)
H.264 AVC 必須
カメラ ハードウェアを含み、android.hardware.camera または android.hardware.camera.front を定義するデバイス実装では必須。
必須 ベースライン プロファイル(BP)
  • 3GPP(.3gp)
  • MPEG-4(.mp4)
  • MPEG-TS(.ts、AAC オーディオのみ、シーク不可、Android 3.0 以降)
MPEG-4 SP   必須   3GPP(.3gp)
VP8   必須
(Android 2.3.3 以降)
  WebM(.webm)と Matroska(.mkv、Android 4.0 以降)

5.2 動画のエンコード

背面カメラを含み、android.hardware.camera を宣言する Android デバイス実装は、以下の動画エンコード プロファイルをサポートする必要があります。

  SD(低画質) SD(高画質) HD(ハードウェアでサポートされている場合)
動画コーデック H.264 ベースライン プロファイル H.264 ベースライン プロファイル H.264 ベースライン プロファイル
動画の解像度 176 x 144 ピクセル 480 x 360 ピクセル 1,280 x 720 ピクセル
動画のフレームレート 12 fps 30 fps 30 fps
動画のビットレート 56 Kbps 500 Kbps 以上 2 Mbps 以上
オーディオ コーデック AAC-LC AAC-LC AAC-LC
オーディオ チャンネル 1(モノラル) 2(ステレオ) 2(ステレオ)
オーディオ ビットレート 24 Kbps 128 Kbps 192 Kbps

5.3. 音声録音

マイク ハードウェアを含み、android.hardware.microphone を宣言するデバイス実装は、アプリが android.media.AudioRecord API を使用して音声ストリームの記録を開始した場合に、以下の各動作で音声をサンプリングして記録しなければなりません。

  • デバイスは、ほぼ平坦な振幅周波数特性(具体的には ±3 dB、100 Hz~4,000 Hz)を示すべきです。
  • オーディオ入力の感度は、1,000 Hz で音圧レベル(SPL)90 dB の音源が 16 ビットサンプルで RMS 2,500 になるように設定するべきです。
  • PCM 振幅レベルは、マイクでの 90 dB SPL から少なくとも 30 dB(-18 dB~+12 dB)の範囲で入力 SPL の変化を線形的にトラッキングするべきです。
  • 高調波ひずみの合計を、90 デシベル / 音圧入力レベルで 100 Hz~4,000 Hz の 1% 未満にする必要があります。

上記の録音仕様に加えて、アプリが android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION 音源を使用して音声ストリームの記録を開始したときは、次のことが求められます。

  • ノイズ リダクション処理が存在する場合は、無効にしなければなりません。
  • 自動ゲイン コントロールが存在する場合は、無効にしなければなりません。

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

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

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

このセクションの目的は次のとおりです。

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

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

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

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

デバイス実装がこのセクションの要件を満たしている場合は、android.content.pm.PackageManager クラスにより機能「android.hardware.audio.low-latency」をレポートすることで、低レイテンシ オーディオのサポートをレポートしても問題ありません。[参考資料、37]。逆に、上記の要件を満たさない場合、デバイス実装は低レイテンシ オーディオのサポートを報告してはなりません。

5.5. ネットワーク プロトコル

デバイスは、Android SDK ドキュメント [参考資料、58] で規定されているとおり、オーディオと動画を再生するためにメディア ネットワーク プロトコルをサポートしなければなりません。具体的には、デバイスは次のメディア ネットワーク プロトコルをサポートしなければなりません。

  • RTSP(RTP、SDP)
  • HTTP(S) プログレッシブ ストリーミング
  • HTTP(S) ライブ ストリーミング ドラフト プロトコル、バージョン 3 [参考資料、59]

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

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

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

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

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

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

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

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

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

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

Android 4.0 には、さまざまなハードウェア構成でサードパーティ アプリが適切に動作するように、デバイスに合わせてアプリアセットと UI レイアウトを自動的に調整する機能があります [参考資料、38]。このセクションで詳述するように、デバイスはこれらの API と動作を適切に実装しなければなりません。

このセクションの要件で言及する単位の定義は次のとおりです。

  • 「物理的な対角サイズ」とは、ディスプレイの点灯部分の、2 つの相対する隅の間の距離(インチ単位)です。
  • 「dpi」(1 インチあたりのドット数)とは、1 インチの水平または垂直の直線スパンで囲まれるピクセル数です。dpi 値が記載されている場合は、水平方向と垂直方向の両方の dpi が範囲内に収まらなければなりません。
  • 「アスペクト比」とは、画面の長辺と短辺の比率です。たとえば 480x854 ピクセルのディスプレイは 854/480 = 1.779、すなわち約「16:9」となります。
  • 「密度非依存ピクセル」(dp)は、160 dpi の画面に正規化された仮想ピクセル単位です。pixels = dps * (density / 160) として計算します。

7.1.1. 画面構成

画面サイズ

Android UI フレームワークはさまざまな画面サイズをサポートしており、アプリは SCREENLAYOUT_SIZE_MASK を使用して android.content.res.Configuration.screenLayout を介してデバイスの画面サイズ(「スクリーン レイアウト」とも呼ばれます)をクエリできます。デバイス実装は、Android SDK ドキュメント [参考資料、38] で定義され、アップストリームの Android プラットフォームで決定される正しい画面サイズをレポートしなければなりません。具体的には、デバイス実装は、次の論理密度非依存ピクセル(dp)画面寸法に従って正しい画面サイズをレポートしなければなりません。

  • デバイスの画面サイズは、426 dp x 320 dp(small)以上でなければなりません。
  • 画面サイズが「normal」であるとレポートするデバイスは、画面サイズが 470 dp x 320 dp 以上でなければなりません。
  • 画面サイズ「large」をレポートするデバイスは、640 dp x 480 dp 以上の画面サイズでなければなりません。
  • 画面サイズ「xlarge」をレポートするデバイスは、960 dp x 720 dp 以上の画面サイズでなければなりません。

さらに、デバイスの画面の物理的な対角サイズは、2.5 インチ以上でなければなりません。

デバイスは、レポートされた画面サイズをいかなるときも変更してはなりません。

アプリは任意で、AndroidManifest.xml ファイルの <supports-screens> 属性を介してサポートする画面サイズを示します。デバイス実装は、Android SDK ドキュメントに記載されているとおり、small、normal、large、xlarge の画面でのアプリの規定のサポートを適切に尊重しなければなりません。

画面のアスペクト比

アスペクト比は 1.3333(4:3)~1.85(16:9)でなければなりません。

画面密度

Android UI フレームワークは、アプリ デベロッパーがアプリリソースをターゲットにできるように、標準的な論理密度のセットを定義しています。デバイス実装は、android.util.DisplayMetrics API を介して次のいずれかの論理 Android フレームワーク密度をレポートしなければならず、この標準密度でアプリを実行しなければなりません。

  • 120 dpi(「ldpi」と呼ばれます)
  • 160 dpi(「mdpi」と呼ばれます)
  • 213 dpi(「tvdpi」と呼ばれます)
  • 240 dpi(「hdpi」と呼ばれます)
  • 320 dpi(「xhdpi」と呼ばれます)
デバイス実装については、画面の物理密度に数値的に最も近い標準の Android フレームワーク密度を定義するべきです。ただし、この論理密度によって、レポートされる画面サイズがサポート対象の最小値未満になる場合を除きます。物理密度に数値的に最も近い標準 Android フレームワーク密度が、サポート対象の最小互換画面サイズ(幅 320 dp)よりも小さい画面サイズとなる場合、デバイス実装は、次に近い標準 Android フレームワーク密度をレポートするべきです。

7.1.2. ディスプレイの指標

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

7.1.3. 画面の向き

デバイスは、縦向きまたは横向きの画面に対するアプリによる動的画面の向きをサポートしなければなりません。つまりデバイスは、特定の画面の向きに関するアプリからのリクエストを尊重しなければなりません。デバイス実装では、縦向きまたは横向きをデフォルトとして選択しても問題ありません。

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

デバイスは、画面の向きを変更するときに、レポート対象の画面サイズまたは密度を変更してはなりません。

デバイスは、サポートする画面の向き(android.hardware.screen.portraitandroid.hardware.screen.landscape)をレポートしなければならず、サポート対象の向きのうち少なくとも 1 つをレポートしなければなりません。たとえば、テレビやノートパソコンなど、固定の横向き画面を備えたデバイスは android.hardware.screen.landscape のみをレポートしなければなりません。

7.1.4. 2D と 3D のグラフィック アクセラレーション

Android SDK ドキュメントで具体化および詳述されているとおり、デバイス実装は OpenGL ES 1.0 と 2.0 の両方をサポートしなければなりません。デバイス実装は、Android SDK ドキュメント [参考資料、8] で詳述されているとおり Android レンダリング スクリプトもサポートしなければなりません。

デバイス実装は、OpenGL ES 1.0 および 2.0 をサポートすることを正しく識別しなければなりません。具体的には、次のことが求められます。

  • マネージド API(GLES10.getString() メソッド経由など)は、OpenGL ES 1.0 および 2.0 をサポートしなければなりません。
  • ネイティブ C/C++ OpenGL API(つまり、libGLES_v1CM.so、libGLES_v2.so、または libEGL.so を介してアプリで使用できる API)は、OpenGL ES 1.0 と 2.0 のサポートをレポートしなければなりません。

デバイス実装では、任意の OpenGL ES 拡張機能を実装しても問題ありません。ただしデバイス実装は、OpenGL ES マネージド API とネイティブ API を介して、サポートする拡張機能の文字列をすべてレポートしなければならず、また逆に、サポートしない拡張機能の文字列をレポートしてはなりません。

なお、Android 4.0 では、アプリで特定の OpenGL テクスチャ圧縮形式を必須に指定できます。これらの形式は通常ベンダー固有です。Android 4.0 では、特定のテクスチャ圧縮形式を実装するためにデバイス実装は必要ありません。ただし、OpenGL API の getString() メソッドを介して、サポート対象のテクスチャ圧縮形式を正確にレポートするべきです。

Android 3.0 には、マニフェスト タグ android:hardwareAccelerated または直接 API 呼び出しを使用することで、アプリ、アクティビティ、ウィンドウ、ビューのレベルで 2D グラフィックのハードウェア アクセラレーションを有効にすることを、アプリで宣言するメカニズムが導入されています [参考資料、9]。

Android 4.0 のデバイス実装では、ハードウェア アクセラレーションをデフォルトで有効にしなければならず、デベロッパーが android:hardwareAccelerated="false" を設定するか、Android View API を通じてハードウェア アクセラレーションを直接無効にすることでリクエストした場合は、ハードウェア アクセラレーションを無効にしなければなりません。

また、デバイス実装は、ハードウェア アクセラレーションに関する Android SDK ドキュメントに合致する動作を示さなければなりません [参考資料、9]。

Android 4.0 には、ハードウェア アクセラレーションの OpenGL ES テクスチャを UI 階層のレンダリング ターゲットとしてデベロッパーが直接統合できる、TextureView オブジェクトが含まれています。デバイス実装は、TextureView API をサポートしなければならず、アップストリームの Android 実装と合致する動作を示さなければなりません。

7.1.5. レガシーアプリの互換モード

Android 4.0 は、以前の画面サイズに依存しない Andrdoid の旧バージョン用に開発されていないレガシーアプリを活用するために、フレームワークが「標準」画面サイズ相当(幅 320 dp)のモードで動作する「互換モード」を指定します。デバイス実装は、アップストリームの Android オープンソース コードで実装されたレガシーアプリ互換モードのサポートを含まなければなりません。つまり、デバイス実装は、互換モードが有効になるトリガーまたはしきい値を変更してはなりません。また、互換モード自体の動作を変更してはなりません。

7.1.6. 画面のタイプ

デバイス実装画面は、次の 2 種類のいずれかに分類されます。

  • 固定ピクセル ディスプレイの実装: この画面はピクセルの幅と高さを 1 種類だけサポートする 1 枚のパネルです。一般的に、この画面はデバイスと物理的に統合されています。例としては、スマートフォン、タブレットなどがあります。
  • 可変ピクセル ディスプレイの実装: このデバイス実装には、埋め込みの画面がなく、ディスプレイ用の VGA、HDMI などの動画出力ポートを備えているものと、ピクセル寸法を変更可能な埋め込みスクリーンを備えているものがあります。例としては、テレビ、セットトップ ボックスなどがあります。

固定ピクセル デバイスの実装

固定ピクセル デバイスの実装では、この互換性定義で定義されている要件を満たしていれば、任意のピクセル寸法の画面を使用しても問題ありません。

固定ピクセルの実装は、外部ディスプレイで使用する動画出力ポートを含んでいても問題ありません。ただし、そのディスプレイをアプリの実行に使用する場合、デバイスは次の要件を満たさなければなりません。

  • デバイスは、セクション 7.1.1 および 7.1.2 で詳述するように、固定ピクセル ディスプレイと同じ画面構成およびディスプレイ指標をレポートしなければなりません。
  • デバイスは、固定ピクセル ディスプレイと同じ論理密度をレポートしなければなりません。
  • デバイスは、固定ピクセル ディスプレイと同じ画面サイズか、それに非常に近い画面サイズをレポートしなければなりません。

たとえば、対角サイズが 7 インチで、解像度が 1024x600 ピクセルのタブレットは、固定ピクセルの大画面 MDPI ディスプレイの実装とみなされます。720p または 1080p で表示される動画出力ポートが含まれるデバイス実装の場合は、固定ピクセル ディスプレイまたはビデオ出力ポートが使用中であるかどうかにかかわらず、アプリケーションが大画面の MDPI ウィンドウでのみ実行されるように、出力を拡大または縮小しなければなりません。

可変ピクセル デバイスの実装

可変ピクセル デバイス実装は、1280x720、1920x1080(720p、1080p)のうち少なくとも 1 つをサポートしなければなりません。可変ピクセル ディスプレイを備えたデバイス実装は、他のいかなる画面構成またはモードもサポートしてはなりません。可変ピクセル画面を備えたデバイス実装は、実行時または起動時に画面構成またはモードを変更しても問題ありません。たとえば、セットトップ ボックスのユーザーは 720p のディスプレイを 1080p のディスプレイに交換し、デバイス実装はそれに合わせて調整できます。

さらに、可変ピクセル デバイスの実装は、これらのピクセル寸法について、次の構成バケットをレポートしなければなりません。

  • 1280x720(720p): 「large」画面サイズ、「tvdpi」(213 dpi)密度
  • 1920x1080(1080p): 「large」画面サイズ、「xhdpi」(320 dpi)密度

つまり、Android 4.0 では、可変ピクセル寸法のデバイス実装は 720p または 1080p に制限され、前述のとおりの画面サイズと密度のバケットをレポートするように構成しなければなりません。

7.1.7. 画面技術

Android プラットフォームには、アプリがリッチ グラフィックをディスプレイにレンダリングできるようにする API があります。このドキュメントで特に許可されていない限り、デバイスは、Android SDK で定義されているこれらの API をすべてサポートしなければなりません。具体的には次のとおりです。

  • デバイスは、16 ビットカラー グラフィックをレンダリングできるディスプレイをサポートしなければならず、24 ビットカラー グラフィックに対応したディスプレイをサポートするべきです。
  • デバイスは、アニメーションをレンダリングできるディスプレイをサポートしなければなりません。
  • 使用するディスプレイ技術は、ピクセル アスペクト比(PAR)が 0.9 から 1.1 の間でなければなりません。つまり、ピクセル アスペクト比は、許容差 10% でほぼ正方形(1.0)でなければなりません。

7.2. 入力デバイス

7.2.1. キーボード

デバイス実装は:

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

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

デバイス実装は:

  • タップ以外のナビゲーション オプションを省略しても問題ありません(つまり、トラックボール、D-pad、ホイールを省略できます)。
  • android.content.res.Configuration.navigation に正しい値をレポートしなければなりません [参考資料、40]。
  • 入力管理エンジンと互換性のある、テキストの選択と編集のための妥当な代替ユーザー インターフェース メカニズムを提供しなければなりません。アップストリームの Android オープンソース ソフトウェアには、タップ以外のナビゲーション入力がないデバイスでの使用に適した選択メカニズムがあります。

7.2.3. ナビゲーション キー

ホーム機能、メニュー機能、戻る機能は、Android のナビゲーション パラダイムに不可欠です。デバイス実装では、アプリの実行時に常にこうした機能をユーザーが利用できるようにしなければなりません。これらの機能は、専用の物理ボタン(機械式または静電容量方式のタッチボタンなど)を介して実装しても問題ありません。または、専用のソフトウェア キー、ジェスチャー、タッチパネルなどを使用して実装しても問題ありません。Android 4.0 は、両方の実装をサポートしています。

デバイス実装は、ナビゲーション キーを表示するために画面の区分けされた部分を使用しても問題ありませんが、その場合は、以下の要件を満たさなければなりません。

  • デバイス実装のナビゲーション キーは、アプリでは利用できない、画面の区分けされた部分を使用しなければならず、アプリで利用できる画面部分を隠す、または利用を妨げることは回避しなければなりません。
  • デバイス実装では、ディスプレイの一部を、セクション 7.1.1 で規定する要件を満たすアプリで利用できるようにしなければなりません。
  • デバイス実装では、アプリがシステム UI モードを指定していない場合、または SYSTEM_UI_FLAG_VISIBLE を指定している場合に、ナビゲーション キーを表示しなければなりません。
  • デバイス実装では、アプリが SYSTEM_UI_FLAG_LOW_PROFILE を指定している場合に、ナビゲーション キーを目立たない「ロー プロファイル」(例: 淡色)モードで表示しなければなりません。
  • デバイス実装では、アプリが SYSTEM_UI_FLAG_HIDE_NAVIGATION を指定している場合に、ナビゲーション キーを非表示にしなければなりません。
  • デバイス実装では、targetSdkVersion が 10 以下の場合に、メニューキーをアプリに表示しなければなりません。また、targetSdkVersion が 10 を超える場合は、メニューキーを表示するべきではありません。

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

デバイス実装は:

  • なんらかのポインタ入力システム(マウスのようなもの、またはタップ)がなければなりません。
  • 任意のモダリティ(静電容量や抵抗など)のタッチスクリーンがあっても問題ありません。
  • タッチスクリーンが複数のポインタをサポートしている場合に、完全に独立してトラックされるポインタをサポートするべきです。
  • デバイス上の具体的なタッチスクリーンの種類に対応する android.content.res.Configuration.touchscreen の値 [参考資料、40] をレポートしなければなりません。

Android 4.0 は、さまざまなタッチ スクリーン、タッチパッド、疑似タップ入力デバイスをサポートしています。タッチスクリーン ベースのデバイス実装は、画面上のアイテムを直接操作しているような印象をユーザーに与えるディスプレイ [参考資料、61] に関連付けられます。ユーザーが画面に直接触れているため、操作中のオブジェクトを示すアフォーダンスを追加する必要はありません。それに対して、疑似タップ インターフェースは、タッチスクリーン機能のサブセットに近いユーザー入力システムを提供します。たとえば、画面上のカーソルを操作するマウスまたはリモコンはタップに近いですが、ユーザーは最初にポイントまたはフォーカスしてからクリックする必要があります。マウス、トラックパッド、ジャイロベースのエアマウス、ジャイロポインタ、ジョイスティック、マルチタッチ トラックパッドなど、多くの入力デバイスが疑似タップ インターフェースをサポートできます。Android 4.0 には機能定数 android.hardware.faketouch が含まれています。これは、タップベースの入力を適切にエミュレートできるマウスやトラックパッドなどの忠実度の高い非タッチの(つまりポインタベースの)入力デバイスに対応します(基本的なジェスチャー サポートを含む)。そして、デバイスがタッチスクリーン機能のサブセットをエミュレートできることを示します。疑似タップ機能を宣言するデバイス実装は、セクション 7.2.5 の疑似タップの要件を満たさなければなりません。

デバイス実装は、使用されている入力の種類に対応する正しい機能をレポートしなければなりません。タッチスクリーン(シングルタッチ以上)を含むデバイス実装は、プラットフォーム機能定数 android.hardware.faketouch をレポートしなければなりません。タッチスクリーンを含まず(ポインタデバイスのみに依存する)デバイス実装は、タッチスクリーン機能をレポートしてはならず、セクション 7.2.5 の疑似タップの要件を満たす場合は android.hardware.faketouch のみをレポートしなければなりません。

7.2.5. 疑似タップ入力

android.hardware.faketouch のサポートを宣言するデバイス実装

  • ポインタ位置の絶対 X 画面位置と絶対 Y 画面位置をレポートし、画面にビジュアル ポインタを表示しなければなりません [参考資料、60]。
  • ポインタが画面上を down または up するときに発生する状態変化を指定するアクション コード [参考資料、60] で、タッチイベントをレポートしなければなりません [参考資料、60]。
  • ユーザーが画面上のオブジェクトのタップをエミュレートできるように、画面上のオブジェクトでのポインタの downup をサポートしなければなりません。
  • ユーザーが画面上のオブジェクトのダブルタップをエミュレートできるように、時間しきい値内で、画面上のオブジェクトの同じ場所におけるポインタの down、ポインタの up、ポインタの down からの up をサポートしなければなりません [参考資料、60]。
  • ユーザーがタップドラッグをエミュレートできるように、画面上の任意の点におけるポインタの down、画面上の他の任意の点へのポインタ移動、その後のポインタの up をサポートしなければなりません。
  • ユーザーが画面上のオブジェクトをフリングできるように、ポインタの down をサポートし、ユーザーが画面上の別の位置にオブジェクトをすばやく移動してから画面上でポインタを up できるようにしなければなりません。

android.hardware.faketouch.multitouch.distinct のサポートを宣言するデバイスは、上記の疑似タップの要件を満たさなければならず、2 つ以上の独立したポインタ入力の個別のトラッキングもサポートしなければなりません。

7.2.6. マイク

デバイス実装は、マイクを省略しても問題ありません。ただし、デバイス実装でマイクを省略する場合、デバイス実装は、android.hardware.microphone 機能定数をレポートし、セクション 7 のとおり、音声記録 API を無処理として実装しなければなりません。それとは逆に、マイクを備えたデバイス実装は:

  • android.hardware.microphone 機能定数をレポートしなければなりません。
  • セクション 5.3 の音質要件を満たすべきです。
  • セクション 5.4 のオーディオ レイテンシの要件を満たすべきです。

7.3. センサー

Android 4.0 には、さまざまな種類のセンサーにアクセスするための API があります。デバイス実装は、以降のサブセクションに示すとおり、通常、これらのセンサーを省略しても問題ありません。デバイスが、サードパーティ デベロッパー向けの対応する API を持つ特定のタイプのセンサーを含んでいる場合、デバイス実装は、Android SDK ドキュメントに記載されているとおり、その API を実装しなければなりません。たとえば、デバイス実装は:

  • android.content.pm.PackageManager クラスに従って、センサーの有無を正確にレポートしなければなりません。[参考資料、37]
  • SensorManager.getSensorList() や同様のメソッドを介してサポート対象のセンサーの正確なリストを返さなければなりません。
  • 他のセンサー API すべてについて合理的に動作しなければなりません(たとえば、アプリがリスナーの登録を試行したとき true または false のうち該当する方を返す、対応するセンサーが存在しないときはセンサー リスナーを呼び出さない、など)。
  • Android SDK ドキュメントで定義されているとおり、センサータイプごとに関連する国際単位系(メートル法)の値を使用して、すべてのセンサー測定値をレポートしなければなりません [参考資料、41]。

上記のリストは包括的なものではありません。Android SDK ドキュメントに記載されている動作を、信頼できるものとみなします。

一部のセンサータイプは統合型です。つまり、1 つ以上の他のセンサーによって提供されるデータから得られる場合があります(方向センサーや直線加速度センサーなど)。デバイス実装では、必須の物理センサーが含まれる場合に、これらのセンサータイプを実装するべきです。

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

7.3.1. 加速度計

デバイス実装は、3 軸加速度計を含むべきです。3 軸加速度計が含まれる場合、デバイス実装は:

  • 50 Hz 以上でイベントを配信できなければなりません。
  • Android API で詳述されているとおり、Android センサー座標系を遵守しなければなりません([参考資料、41] を参照)。
  • 任意の 3 次元ベクトルについて、自由落下から重力の 2 倍(2g)以上まで測定できなければなりません。
  • 正確度が 8 ビット以上でなければなりません。
  • 標準偏差が 0.05 m/s^2 以下でなければなりません。

7.3.2. 磁力計

デバイス実装は、3 軸磁力計(コンパス)を含むべきです。3 軸磁力計が含まれる場合、デバイスは:

  • 10 Hz 以上でイベントを配信できなければなりません。
  • Android API で詳述されているとおり、Android センサー座標系を遵守しなければなりません([参考資料、41] を参照)。
  • 地磁気をカバーするのに十分な磁場強度の範囲をサンプリングできなければなりません。
  • 正確度が 8 ビット以上でなければなりません。
  • 標準偏差が 0.5 μT 以下でなければなりません。

7.3.3. GPS

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

7.3.4. ジャイロスコープ

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

  • 温度補正しなければなりません。
  • 最大で 5.5*Pi ラジアン/秒(つまり、毎秒約 1,000 度)の方向変化を測定できなければなりません。
  • 100 Hz 以上でイベントを配信できなければなりません。
  • 正確度が 12 ビット以上でなければなりません。
  • 分散が Hz あたり 1e-7 rad^2 / s^2(Hz あたりの分散または rad^2 / s)以下でなければなりません。分散はサンプリング レートによって異なることが許容されますが、この値の制約を受けなければなりません。つまり、サンプリング レート 1 Hz でジャイロの分散を測定した場合、1e-7 rad^2/s^2 以下であるべきです。
  • タイムスタンプは、ハードウェア イベントが発生した時間にできるだけ近いものでなければなりません。固定のレイテンシを削除する必要があります。

7.3.5. 気圧計

デバイス実装には、気圧計(周囲気圧センサー)が含まれていても問題ありません。気圧計が含まれる場合、デバイス実装は:

  • 5 Hz 以上でイベントを配信できなければなりません。
  • 標高を推定するのに十分な精度がなければなりません。

7.3.7. 温度計

デバイス実装は、温度計(温度センサーなど)を含んでいても問題ありませんが、含むべきではありません。温度計が含まれる場合、デバイス実装はデバイスの CPU の温度を測定しなければなりません。他の温度を測定してはなりません(このセンサータイプは Android 4.0 API で非推奨になりました)。

7.3.7. 光度計

デバイス実装には、光度計(周囲光センサー)が含まれていても問題ありません。

7.3.8. 近接センサー

デバイス実装には、近接センサーが含まれていても問題ありません。近接センサーが含まれる場合、デバイス実装は、画面と同じ方向にある物体の近接性を測定しなければなりません。つまり近接センサーは、画面の近くにある物体を検出するような向きでなければなりません。これは、スマートフォンをユーザーが使用中であることの検出が、この種のセンサーの主な目的であるためです。他の向きの近接センサーを含む場合、デバイス実装は、この API を通じてアクセス可能であってはなりません。デバイス実装に近接センサーがある場合、その正確度は 1 ビット以上でなければなりません。

7.4. データ接続

7.4.1. 電話

Android 4.0 API とこのドキュメントで使用する「電話」は、特に、GSM または CDMA ネットワークを介して行う音声通話と SMS メッセージの送信に関連するハードウェアのことを指します。こうした音声通話は、パケット交換であっても、またはなくても問題ありませんが、Android 4.0 では、同じネットワークを使用して実装される可能性があるデータ接続からは独立しているとみなされます。つまり、Android の「電話」機能と API は、特に音声通話と SMS のことを指します。たとえば、発信や SMS メッセージの送受信ができないデバイス実装は、データ接続にモバイル ネットワークを使用するかどうかにかかわらず、「android.hardware.telephony」機能またはサブ機能をレポートしてはなりません。

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

7.4.2. IEEE 802.11(Wi-Fi)

Android 4.0 デバイス実装は、1 つ以上の形式の 802.11(b/g/a/n など)をサポートするべきです。802.11 のサポートが含まれる場合、デバイス実装は、対応する Android API を実装しなければなりません。

7.4.3. Bluetooth

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

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

7.4.4. 近距離無線通信

デバイス実装には、近距離無線通信(NFC)用のトランシーバーと関連ハードウェアが含まれているべきです。NFC ハードウェアが含まれる場合、デバイス実装は:

  • android.content.pm.PackageManager.hasSystemFeature() メソッドから android.hardware.nfc 機能をレポートしなければなりません。[参考資料、37]
  • 次の NFC 規格を介して NDEF メッセージの読み取りと書き込みができなければなりません。
    • 次の NFC 規格を介して、NFC フォーラムのリーダー / ライター(NFC フォーラムの技術仕様 NFCForum-TS-DigitalProtocol-1.0 で定義)として動作できなければなりません。
      • NfcA(ISO14443-3A)
      • NfcB(ISO14443-3B)
      • NfcF(JIS 6319-4)
      • IsoDep(ISO 14443-4)
      • NFC フォーラムのタグタイプ 1、2、3、4(NFC フォーラムにより定義)
  • 次の NFC 規格を介して NDEF メッセージの読み取りと書き込みを行えるべきです。以下の NFC 規格については、Android 4.0 に関しては「するべき」と記載されていますが、今後のバージョンの互換性定義では「しなければならない」に変更される予定です。つまり、これらのスタンダードは Android 4.0 では任意ですが、今後のバージョンでは必須になります。Android を搭載した既存または新規のデバイスは現在、今後のプラットフォーム リリースにアップグレードできるよう、Android 4.0 のこれらの要件を満たすことが極めて強く奨励されています
    • NfcV(ISO 15693)
  • 次のピアツーピア標準とプロトコルを介してデータを送受信できなければなりません。
    • ISO 18092
    • LLCP 1.0(NFC フォーラムにより定義)
    • SDP 1.0(NFC フォーラムにより定義)
    • NDEF プッシュ プロトコル [参考資料、43]
    • SNEP 1.0(NFC フォーラムにより定義)
  • Android ビームのサポートを含まなければなりません。
    • SNEP デフォルト サーバーを実装しなければなりません。デフォルトの SNEP サーバーで受信した有効な NDEF メッセージは、android.nfc.ACTION_NDEF_DISCOVERED インテントを使用してアプリにディスパッチしなければなりません。設定で Android Beam を無効にしたときは、受信した NDEF メッセージのディスパッチを無効にしてはなりません。
    • NPP サーバーを実装しなければなりません。NPP サーバーが受信するメッセージは、SNEP のデフォルト サーバーと同じ方法で処理しなければなりません。
    • Android ビームが有効になっているときは、SNEP クライアントを実装し、送信 P2P NDEF をデフォルトの SNEP サーバーに送信しようとしなければなりません。デフォルトの SNEP サーバーが見つからない場合、クライアントは NPP サーバーへの送信を試行しなければなりません。
    • フォアグラウンド アクティビティが、android.nfc.NfcAdapter.setNdefPushMessage、android.nfc.NfcAdapter.setNdefPushMessageCallback、android.nfc.NfcAdapter.enableForegroundNdefPush を使用して送信 P2P NDEF メッセージを設定できるようにしなければなりません。
    • 送信 P2P NDEF メッセージを送信する前に、「タップしてビーム」などのジェスチャーまたは画面上の確認を使用するべきです。
    • Android ビームをデフォルトで有効にするべきです。
  • NFC 検出モードにあるとき、サポートされているすべての技術をポーリングしなければなりません。
  • 画面がアクティブ、ロック画面がロック解除された状態でデバイスが起動しているときは、NFC 検出モードになっているべきです。

なお、上記の JIS、ISO、NFC フォーラムの仕様について、一般公開されているリンクはありません。

さらに、デバイス実装では、次の MIFARE 技術のリーダー / ライターがサポートされていても問題ありません。

Android 4.0 には、これらの MIFARE タイプの API が含まれています。リーダー / ライターのロールで MIFARE をサポートする場合、デバイス実装は:

  • Android SDK に記載されているとおり、対応する Android API を実装しなければなりません。
  • android.content.pm.PackageManager.hasSystemFeature() メソッドから機能 com.nxp.mifare をレポートしなければなりません。[参考資料、37] これは標準の Android 機能ではないため、PackageManager クラスの定数としては表示されません。
  • このセクションに記載されているように、一般的な NFC サポートも実装しない限り、対応する Android API を実装する、または com.nxp.mifare 機能をレポートすることは回避しなければなりません。

NFC ハードウェアが含まれない場合、デバイス実装では android.content.pm.PackageManager.hasSystemFeature() メソッドから android.hardware.nfc 機能を宣言してはなりません [参考資料、37]。また、Android 4.0 NFC API を NoOps として実装しなければなりません。

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

7.4.5. 最低限のネットワーク機能

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

物理ネットワーク標準(イーサネットなど)がプライマリ データ接続であるデバイス実装は、少なくとも 1 つの一般的なワイヤレス データ標準(802.11(WiFi)など)のサポートを含むべきです。

デバイスは、複数の形式のデータ接続を実装しても問題ありません。

7.5. カメラ

デバイス実装には背面カメラが含まれているべきであり、前面カメラが含まれていても問題ありません。背面カメラとは、デバイスのディスプレイとは反対側に配置されたカメラのことです。つまり、従来のカメラのようにデバイスの向こう側の光景を撮影するものです。前面カメラとは、デバイスのディスプレイと同じ側に配置されたカメラのことです。つまり、通常はビデオ会議や類似のアプリなどでユーザーを撮影するために使用されるカメラです。

7.5.1. 背面カメラ

デバイス実装は背面カメラを含むべきです。背面カメラが含まれる場合、デバイス実装は:

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

7.5.2. 前面カメラ

デバイス実装には、前面カメラが含まれていても問題ありません。前面カメラが含まれる場合、デバイス実装は:

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

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 定数で表されます)をサポートしなければなりません。(ハードウェア動画デコーダとカメラは任意のネイティブ ピクセル形式を使用できますが、デバイス実装は YV12 への変換をサポートしなければなりません)。

デバイス実装では、デバイスにハードウェア オートフォーカスなどの機能があるかどうかにかかわらず、Android 4.0 SDK のドキュメント [参考資料、51] に含まれる Camera API を完全に実装しなければなりません。たとえば、オートフォーカスのないカメラは、(オートフォーカスのないカメラには関係がなくとも)登録された android.hardware.Camera.AutoFocusCallback インスタンスを引き続き呼び出さなければなりません。なお、これは前面カメラに適用されます。たとえば、前面カメラはたいていの場合オートフォーカスをサポートしていませんが、それでも前述のように API コールバックを「偽装」しなければなりません。

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

デバイス実装は、カメラで新しい画像が撮影され、画像のエントリがメディアストアに追加されたときは常に、Camera.ACTION_NEW_PICTURE インテントをブロードキャストしなければなりません。

デバイス実装は、新しい動画がカメラで録画され、画像のエントリがメディアストアに追加されたときは常に、Camera.ACTION_NEW_VIDEO インテントをブロードキャストしなければなりません。

7.5.4. カメラの向き

前面カメラと背面カメラの両方が存在する場合、カメラの長辺が画面の長辺に沿うように向きを合わせる必要があります。つまり、デバイスが横向きで保持されている場合、カメラは横向きで画像をキャプチャしなければなりません。これは、デバイスの自然な向きに関係なく適用されます。つまり、横向き主体のデバイスと、縦向き主体のデバイスに適用されます。

7.6. メモリとストレージ

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

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

デバイス実装には、アプリの個人データに使用できる不揮発性ストレージが少なくとも 350 MB 用意されていなければなりません。つまり、/data パーティションは少なくとも 350 MB でなければなりません。

Android API は、アプリがデータファイルをダウンロードするために使用できるダウンロード マネージャーを備えています [参考資料、56]。ダウンロード マネージャーのデバイス実装は、サイズが 100 MB 以上の個々のファイルをデフォルトの「キャッシュ」場所にダウンロードできなければなりません。

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

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

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

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

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

使用する共有ストレージの形式に関係なく、デバイス実装は、USB マスストレージ(UMS)やメディア転送プロトコル(MTP)など、ホスト コンピュータから共有ストレージの内容にアクセスするためのメカニズムを提供しなければなりません。デバイス実装では USB マスストレージを使用しても問題ありませんが、メディア転送プロトコルを使用するべきです。デバイス実装が Media Transfer Protocol をサポートする場合:

  • デバイス実装は、リファレンス Android MTP ホスト、Android File Transfer と互換性があるべきです [参考資料、57]。
  • デバイス実装は、USB デバイスクラス 0x00 をレポートするべきです。
  • デバイス実装は USB インターフェース名「MTP」をレポートするべきです。

USB ポートがない場合、デバイス実装は、ホスト コンピュータがネットワーク ファイル システムなど、他の手段で共有ストレージの内容にアクセスできるようにしなければなりません。

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

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

7.7. USB

デバイス実装は USB クライアント ポートを含むべきであり、USB ホストポートを含むべきです。

デバイス実装に USB クライアント ポートが含まれる場合:

  • ポートは標準の USB-A ポートで USB ホストに接続できなければなりません。
  • ポートはデバイス側でマイクロ USB フォーム ファクタを使用すべきです。
  • デバイスに接続されているホストが、USB マスストレージまたは Media Transfer Protocol を使用して共有ストレージ ボリュームのコンテンツにアクセスできるようにしなければなりません。
  • Android SDK ドキュメントに記載されているとおり、Android Open Accessory API と仕様を実装しなければならず、ハードウェア機能 android.hardware.usb.accessory [参考資料、51] のサポートを宣言しなければなりません。

デバイス実装に USB ホストポートが含まれる場合:

  • 標準以外のポートのフォーム ファクタを使用しても問題ありませんが、使用する場合は、ポートを標準 USB-A に適合させるケーブルが付属していなければなりません。
  • Android SDK に記載されているとおり Android USB ホスト API を実装しなければならず、ハードウェア機能 android.hardware.usb.host [参考資料、52] のサポートを宣言しなければなりません。

デバイス実装では、Android Debug Bridge を実装しなければなりません。USB クライアント ポートが省略されている場合、デバイス実装はローカルエリア ネットワーク(イーサネット、802.11 など)を介して Android Debug Bridge を実装しなければなりません。

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

デバイス実装は、下表で定義されている Android 4.0 対応デバイスの主要なパフォーマンス指標を満たさなければなりません。

指標 パフォーマンスしきい値 コメント
アプリケーションの起動時間 次のアプリケーションが指定した時間内に起動します。
  • ブラウザ: 1,300 ミリ秒未満
  • 連絡先: 700 ミリ秒未満
  • 設定: 700 ミリ秒未満
起動時間は、アプリケーションのデフォルト アクティビティを読み込むために必要な合計時間として計算され、Linux プロセスを起動し、Android パッケージを Dalvik VM に読み込んで、onCreate を呼び出すのに要する時間も含まれます。
同時アプリケーション 複数のアプリが起動されている場合、起動後に実行中のアプリを再起動するまでにかかる時間は、元の起動時間よりも短くする必要があります。  

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

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

9.1. 権限

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

9.2. UID とプロセスの分離

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

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

デバイス実装は、「セキュリティと権限」のリファレンス [参考資料、54] で規定されているとおり、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 4.0 のリファレンス実装と優先実装に対して行う変更を可能な限り最小限に抑えることを強くおすすめします。これにより、互換性の問題をもたらすバグが導入され、再作業やデバイスのアップデートが必要となるリスクを最小限に抑えることができます。

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

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

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

10.2. CTS 検証ツール

デバイス実装は、CTS 検証ツールで該当するすべてのケースを正しく実行しなければなりません。CTS 検証ツールは互換性テストスイートに含まれています。カメラやセンサーの正常な機能など、自動システムではテストできない機能をテストするために、人間のオペレーターが実行するためのものです。

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

前述のとおり、すべてのデバイスとすべてのビルドで、CTS 検証ツールが正しく実行されなければなりません。ただし、ビルドの多くは非常に類似しているため、デバイス実装者は、わずかな違いのみが存在するビルドで CTS 検証ツールを明示的に実行することは求められていません。具体的には、CTS 検証ツールに合格した実装との違いが、含まれるロケール、ブランディングなどのセットのみであるデバイス実装は、CTS 検証ツールのテストを省略しても問題ありません。

10.3. リファレンス アプリケーション

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

  • 「Android 向けアプリ」アプリ [参考資料、55]。
  • Replica Island(Android マーケットで入手可能)

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

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

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

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

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

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

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

12. お問い合わせ

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

付録 A - Bluetooth のテスト手順

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

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

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

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

設定とインストール

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

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

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

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

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

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

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

テストの再リリース

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

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