Android 4.4 互換性定義

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

リビジョン 1
最終更新日: 2013 年 11 月 27 日

Copyright © 2013, 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. ドキュメントの変更履歴
13. お問い合わせ

1. はじめに

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

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

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

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

この定義、またはセクション 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.4 で許可されているバージョン文字列: http://source.android.com/compatibility/4.4/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 のウェブストレージ API: http://www.w3.org/TR/webstorage/
  16. HTML5/W3C の IndexedDB API: http://www.w3.org/TR/IndexedDB/
  17. Dalvik 仮想マシン仕様: Android ソースコード(dalvik/docs)で入手可能
  18. AppWidget: 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_guidelines/icon_design_status_bar.html
  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. 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、systrace): 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. カメラ: 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/permissions.html
  55. Android 用アプリ: http://code.google.com/p/apps-for-android
  56. Android 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. NFC 接続ハンドオーバー: http://www.nfc-forum.org/specs/spec_list/#conn_handover
  61. NFC を使用する Bluetooth Secure Simple Pairing: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
  62. Wi-Fi マルチキャスト API: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html
  63. アクション アシスト: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
  64. USB 充電仕様: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
  65. Android ビーム: http://developer.android.com/guide/topics/nfc/nfc.html
  66. Android USB オーディオ: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
  67. Android の NFC 共有の設定: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
  68. Wi-Fi Direct(Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
  69. ロックとホーム画面ウィジェット: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html
  70. UserManager のリファレンス: http://developer.android.com/reference/android/os/UserManager.html
  71. 外部ストレージのリファレンス: http://source.android.com/devices/tech/storage
  72. 外部ストレージ API: http://developer.android.com/reference/android/os/Environment.html
  73. SMS ショートコード: http://en.wikipedia.org/wiki/Short_code
  74. メディア リモコン クライアント: http://developer.android.com/reference/android/media/RemoteControlClient.html
  75. ディスプレイ マネージャー: http://developer.android.com/reference/android/hardware/display/DisplayManager.html
  76. Dreams: http://developer.android.com/reference/android/service/dreams/DreamService.html
  77. Android アプリ開発に関連する設定: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS
  78. Camera: http://developer.android.com/reference/android/hardware/Camera.Parameters.html
  79. EGL 拡張機能 - EGL_ANDROID_RECORDABLE: http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt
  80. モーション イベント API: http://developer.android.com/reference/android/view/MotionEvent.html
  81. タップ入力の構成: http://source.android.com/devices/tech/input/touch-devices.html
  82. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/
  83. WebView の互換性: http://www.chromium.org/
  84. Android のデバイス オーナー アプリ: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)
  85. WifiManager API: http://developer.android.com/reference/android/net/wifi/WifiManager.html
  86. RTC ハードウェア コーディングの要件: http://www.webmproject.org/hardware/rtc-coding-requirements/
  87. Settings.Secure の LOCATION_MODE: http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE
  88. コンテンツ リゾルバ: http://developer.android.com/reference/android/content/ContentResolver.html
  89. SettingInjectorService: http://developer.android.com/reference/android/location/SettingInjectorService.html
  90. ホストベースのカード エミュレーション: http://developer.android.com/guide/topics/connectivity/nfc/hce.html
  91. テレフォニー プロバイダ: http://developer.android.com/reference/android/provider/Telephony.html

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

3. ソフトウェア

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

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

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

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

3.2. ソフト API の互換性

セクション 3.1 のマネージド API に加えて、Android には重要なランタイム専用の「ソフト」API も含まれています。これらは、Android アプリのインテント、権限、およびそれらと同様の要素の形式を取り、アプリのコンパイル時に適用できない API です。

3.2.1. 権限

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

3.2.2. ビルド パラメータ

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

パラメータ コメント
VERSION.RELEASE 現在実行している Android システムのバージョン(人が読める形式)。このフィールドには、[参考資料、7] で定義されている文字列値のいずれかを指定しなければなりません。
VERSION.SDK 現在実行している Android システムのバージョン(サードパーティ アプリのコードからアクセスできる形式)。Android 4.4 の場合、このフィールドには整数値 19 を指定しなければなりません。
VERSION.SDK_INT 現在実行している Android システムのバージョン(サードパーティ アプリのコードからアクセスできる形式)。Android 4.4 の場合、このフィールドには整数値 19 を指定しなければなりません。
VERSION.INCREMENTAL 現在実行している Android システムの特定のビルドを指定する、デバイス実装者が選択した値(人が読める形式)。この値については、エンドユーザーが利用できる別のビルドに再利用することは回避しなければなりません。このフィールドの主な使用方法は、ビルドの生成に使用されたビルド番号またはソース管理変更識別子を示すことです。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列("")であってはなりません。
BOARD デバイスで使用される特定の内部ハードウェアを識別する、デバイス実装者が選択した値(人が読める形式)。このフィールドは、デバイスに電力を供給するボードの特定のリビジョンを示すために使用できます。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現 "^[a-zA-Z0-9.,_-]+$" に一致しなければなりません。
BRAND エンドユーザーが知っているデバイスに関連付けられたブランド名を反映する値。人が読める形式でなければならず、デバイスのメーカーまたはデバイスを販売する会社のブランドを表すべきです。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現 "^[a-zA-Z0-9.,_-]+$" に一致しなければなりません。
CPU_ABI ネイティブ コードの命令セット(CPU タイプ + ABI 規則)の名前。 セクション 3.3: ネイティブ API の互換性をご覧ください。
CPU_ABI2 ネイティブ コードの 2 番目の命令セット(CPU タイプ + ABI 規則)の名前。セクション 3.3: ネイティブ API の互換性をご覧ください。
DEVICE ハードウェア機能の構成とデバイスの工業デザインを識別する開発名またはコードネームを含む、デバイス実装者が選択した値。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現 "^[a-zA-Z0-9.,_-]+$" に一致しなければなりません。
FINGERPRINT このビルドを一意に識別する文字列。人が読める程度の形式にするべきです。次のテンプレートに従わなければなりません。
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
例:
acme/myproduct/mydevice:4.4/KRT16/3359:userdebug/test-keys
フィンガープリントは空白文字を含んではなりません。上記のテンプレート内の他のフィールドに空白文字がある場合、ビルドのフィンガープリントではアンダースコア(_)などの別の文字に置き換えなければなりません。このフィールドの値は 7 ビット ASCII としてエンコード可能でなければなりません。
HARDWARE ハードウェアの名前(カーネル コマンドラインまたは /proc から)。人が読める程度の形式にするべきです。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現 "^[a-zA-Z0-9.,_-]+$" に一致しなければなりません。
HOST ビルドが構築されたホストを一意に識別する文字列(人が読める形式)。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列("")であってはなりません。
ID 特定のリリースを参照するためにデバイス実装者が選択する識別子(人が読める形式)。このフィールドは android.os.Build.VERSION.INCREMENTAL と同じ内容にできますが、エンドユーザーがソフトウェア ビルドを区別できるような意味のある値にするべきです。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現 "^[a-zA-Z0-9.,_-]+$" に一致しなければなりません。
MANUFACTURER 製品の相手先ブランド製品製造企業(OEM)の商号。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列("")であってはなりません。
MODEL エンドユーザーが知っているデバイスの名前を含む、デバイス実装者が選択した値。これは、デバイスが販売され、エンドユーザーに購入される際の名前と同じにすべきです。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列("")であってはなりません。
PRODUCT 特定の製品(SKU)の開発名またはコードネームを含む、デバイス実装者が選択した値。同じブランド内で一意にするべきです。人が読める形式でなければなりませんが、必ずしもエンドユーザーに表示することを意図したものではありません。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現 "^[a-zA-Z0-9.,_-]+$" に一致しなければなりません。
SERIAL ハードウェア シリアル番号であり、使用可能なものでなければなりません。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現 "^([a-zA-Z0-9]{6,20})$" に一致しなければなりません。
TAGS ビルドをさらに区別する、デバイス実装者が選択したタグのカンマ区切りのリスト(例: 「unsigned,debug」)。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現 "^[a-zA-Z0-9.,_-]+$" に一致しなければなりません。
TIME ビルドが作成されたときのタイムスタンプを表す値。
TYPE ビルドのランタイム構成を指定する、デバイス実装者が選択した値。このフィールドには、典型的な 3 つの Android ランタイム構成(user、userdebug、eng)に対応する値のいずれかを指定するべきです。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現 "^[a-zA-Z0-9.,_-]+$" に一致しなければなりません。
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.1 で参照されている各インテント パターンをサードパーティ アプリでオーバーライドできるようにしなければなりません。アップストリームの Android オープンソース実装では、デフォルトでこれが許可されています。デバイス実装者は、システムアプリによるこれらのインテント パターンの使用に特別な権限を付与してはなりません。また、サードパーティ アプリがこれらのパターンにバインド、およびそれらを制御することを前提としてはなりません。これによって禁止される行為には、たとえば、同じインテント パターンを処理する複数のアプリの中からユーザーが特定のアプリを選択することを許可する「選択的」ユーザー インターフェースを無効にすることが含まれますが、これに限定されません。

ただし、デフォルト アクティビティがデータ URI に対してより限定的なフィルタを提供する場合、デバイス実装は限定的な URI パターン(例: http://play.google.com)用のデフォルト アクティビティを提供しても構いません。たとえば、データ URI「http://www.android.com」を指定するインテント フィルタは、「http://」を指定するブラウザ フィルタよりも限定的です。デバイス実装では、ユーザーがインテントのデフォルト アクティビティを変更できるユーザー インターフェースを搭載しなければなりません。

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.2.3.5. デフォルト アプリの設定

Android 4.4 では、ユーザーがデフォルトのホームアプリや SMS アプリを選択できる設定が追加されています。デバイス実装では、同様のユーザー設定メニューをそれぞれに提供しなければならず、SDK ドキュメント [参考資料、91] に記載されているインテント フィルタ パターンや API メソッドと互換性がなければなりません。

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

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

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

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

  • 標準の Java Native Interface(JNI)セマンティクスを使用して、ネイティブ コードを呼び出すためにマネージド環境で動作するコードのサポートを含まなければなりません。
  • 以下のリストにある各必須ライブラリと、ソース互換(すなわちヘッダー互換)かつバイナリ互換(ABI 向け)でなければなりません。
  • android.os.Build.CPU_ABI API と android.os.Build.CPU_ABI2 パラメータを介して、デバイスがサポートするネイティブ アプリケーション バイナリ インターフェース(ABI)を正確にレポートしなければなりません。
  • android.os.Build.CPU_ABI2 を介して、最新バージョンの Android NDK のファイル docs/CPU-ARCH-ABIS.html に記載されている ABI のみをレポートしなければなりません。
  • android.os.Build.CPU_ABI を介して、下記の ABI のいずれか 1 つのみをレポートしなければなりません。
    • armeabi-v7a
    • x86
    • mips
  • アップストリームの 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)
  • libGLESv3.so(OpenGL ES 3.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 のサポートについてもレポートしてはなりません。

なお、デバイス実装は、libGLESv3.so を含まなければならず、libGLESv2.so への symlink(シンボリック リンク)を持たなければなりません。OpenGL ES 3.0 のサポートを宣言するデバイス実装では、libGLESv2.so は OpenGL ES 2.0 の関数シンボルに加えて OpenGL ES 3.0 の関数シンボルをエクスポートしなければなりません。

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

3.4. ウェブの互換性

3.4.1. WebView の互換性

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

  • デバイスの android.webkit.WebView の実装は、Android 4.4 用のアップストリームの Android オープンソース プロジェクトの Chromium ビルドをベースとしていなければなりません。このビルドには、WebView の特定の機能セットとセキュリティ修正が含まれています。[参考資料、83]
  • WebView がレポートするユーザー エージェント文字列は、次の形式でなければなりません。
    Mozilla/5.0 (Linux; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
    • $(VERSION) 文字列の値は、android.os.Build.VERSION.RELEASE の値と同じでなければなりません。
    • $(LOCALE) 文字列の値は任意であり、国コードと言語に関する ISO 規則を遵守し、デバイスの現在設定されているロケールを参照するべきです。省略した場合は、末尾のセミコロンも削除しなければなりません。
    • $(MODEL) 文字列の値は、android.os.Build.MODEL の値と同じでなければなりません。
    • $(BUILD) 文字列の値は、android.os.Build.ID の値と同じでなければなりません。
    • $(CHROMIUM_VER) 文字列の値は、アップストリームの Android オープンソース プロジェクトの Chromium バージョンでなければなりません。
    • デバイス実装は、ユーザー エージェント文字列で Mobile を省略しても構いません。

WebView コンポーネントは、可能な限り HTML5 [参考資料、11] をサポートするべきです。

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 をご覧ください)。

なお、下記のメモリ値は最小値とみなされます。デバイス実装は、各アプリにより多くのメモリを割り当てても構いません。

画面サイズ 画面密度 アプリケーション メモリ
small / normal / large ldpi / mdpi 16MB
small / normal / large tvdpi / hdpi 32 MB
small / normal / large xhdpi 64 MB
small / normal / large 400 dpi 96 MB
small / normal / large xxhdpi 128 MB
small / normal / large xxxhdpi 256 MB
xlarge mdpi 32 MB
xlarge tvdpi / hdpi 64 MB
xlarge xhdpi 128 MB
xlarge 400 dpi 192 MB
xlarge xxhdpi 256 MB
xlarge xxxhdpi 512 MB

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

3.8.1. ランチャー(ホーム画面)

Android にはランチャー アプリ(ホーム画面)があり、デバイス ランチャー(ホーム画面)を置き換えるサードパーティ アプリをサポートしています。サードパーティ アプリにデバイスのホーム画面の置き換えを許可するデバイス実装は、プラットフォーム機能 android.software.home_screen を宣言しなければなりません。

3.8.2. ウィジェット

Android では、アプリが「AppWidget」をエンドユーザーに公開するためのコンポーネント タイプと、それに対応する API およびライフサイクルを定義しています [参考資料、18]。ホーム画面へのウィジェットの埋め込みをサポートするデバイス実装は、以下の要件を満たすとともに、プラットフォーム機能 android.software.app_widgets のサポートを宣言しなければなりません。

  • デバイスのランチャーは、AppWidget の組み込みのサポートを含まなければならず、ランチャー内で直接 AppWidget を追加、構成、表示、削除するユーザー インターフェース アフォーダンスを公開しなければなりません。
  • デバイス実装は、標準グリッドサイズで 4 x 4 のウィジェットをレンダリングできなければなりません(詳しくは、Android SDK ドキュメントのアプリ ウィジェット設計ガイドライン [参考資料、18] をご覧ください)。
  • ロック画面のサポートを含むデバイス実装は、ロック画面上のアプリ ウィジェットをサポートしなければなりません。

3.8.3. 通知

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

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

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

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

3.8.4. 検索

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

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

3.8.5. トースト

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

3.8.6. テーマ

Android では、アプリがアクティビティまたはアプリの全体にわたってスタイルを適用するためのメカニズムとして「テーマ」を提供しています。

Android には、アプリ デベロッパーが Android SDK [参考資料、24] で定義された Holo テーマのデザインにマッチさせる場合に使用する定義済みスタイルのセットとして、「Holo」テーマ ファミリーがあります。デバイス実装は、アプリに対して公開されている Holo テーマ属性を一切変更してはなりません [参考資料、25]。

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

バージョン 4.4 以降の Android では、半透明のシステムバーを使用した新しいテーマのバリエーションがサポートされています。これにより、アプリ デベロッパーは、ステータスバーとナビゲーション バーの裏側の部分にアプリ コンテンツを表示することができます。この構成でデベロッパー エクスペリエンスに一貫性を持たせるには、さまざまなデバイス実装でステータスバーのアイコン スタイルを維持することが重要です。そのため、Android デバイスの実装は、アイコンが問題のあるステータスを示している場合を除き、システム ステータス アイコン(信号強度やバッテリー残量など)と、システムが発行する通知には、白色を使用しなければなりません [参考資料、25]。

3.8.7. ライブ壁紙

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

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

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

3.8.8. 最近使ったアプリの表示

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

3.8.9. 入力管理

Android は、入力管理と、サードパーティのインプット メソッド エディタをサポートしています。ユーザーがデバイスでサードパーティの入力方法を使用できるようにするデバイス実装は、Android SDK ドキュメントで定義されているとおり、プラットフォーム機能 android.software.input_methods を宣言し、IME API をサポートしなければなりません。

android.software.input_methods 機能を宣言するデバイス実装は、ユーザーによるアクセスが可能な、サードパーティの入力方法を追加および構成するメカニズムを提供しなければなりません。デバイス実装は、android.settings.INPUT_METHOD_SETTINGS インテントに応じて設定インターフェースを表示しなければなりません。

3.8.10. ロック画面のメディア リモコン

Android には、メディアアプリがデバイスのロック画面などのリモートビューに表示される再生コントロールと統合できるリモコン API のサポートが含まれています [参考資料、74]。デバイスのロック画面をサポートし、ユーザーによるホーム画面へのウィジェットの追加を許可するデバイス実装では、デバイスのロック画面へのリモコンの埋め込みをサポートしなければなりません [参考資料、69]。

3.8.11. Dreams

Android は Dreams [参考資料、76] というインタラクティブなスクリーンセーバーをサポートしています。 Dreams を使用すると、ユーザーは、充電中のデバイスがアイドル状態のときや、卓上ホルダーにドッキングされているときに、アプリを操作できます。デバイス実装では、Dreams をサポートし、ユーザーが Dreams を構成するための設定オプションを提供しなければなりません。

3.8.12. 位置情報

位置情報モードは、[設定] の [位置情報] メニューに表示されなければなりません [参考資料、87]。Android 4.4 で導入された SettingInjectorService を通じて提供される位置情報サービスは、同じ [位置情報] メニュー内に表示する必要があります [参考資料、89]。

3.8.13. Unicode

Android 4.4 はカラー絵文字をサポートしています。Android デバイス実装は、Unicode 6.1 [参考資料、82] で定義された絵文字の入力方法をユーザーに提供しなければならず、これらの絵文字をカラーグリフでレンダリングできなければなりません。

3.9. デバイス管理

Android には、Android Device Administration API [参考資料、27] を通じて、セキュリティ対応アプリがシステムレベルでデバイス管理機能(パスワード ポリシーの適用、リモートワイプの実施など)を実行できる機能があります。デバイス実装は、DevicePolicyManager クラス [参考資料、28] の実装を提供しなければなりません。ロック画面のサポートを含むデバイス実装は、Android SDK ドキュメント [参考資料、27] で規定されているすべてのデバイス管理ポリシーをサポートしなければなりません。

デバイス実装には、デバイス管理機能を実行するプリインストール アプリがあっても構いませんが、このアプリは、デフォルトのデバイス オーナーのアプリ [参考資料、84] として、すぐに使えるように設定されていてはなりません。

3.10. ユーザー補助

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

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

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

3.11. テキスト読み上げ

Android には、アプリがテキスト読み上げ(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 とオープン ハンドセット アライアンスのいずれも、これらのコーデックがサードパーティの特許の制約を受けないとは表明していないことにご注意ください。このソースコードをハードウェアまたはソフトウェア製品で使用しようとする場合は、このコード(オープンソース ソフトウェアまたはシェアウェアを含む)の実装に、該当の特許権者からの特許ライセンスが必要になることがあります。

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

タイプ 形式 / コーデック エンコーダ デコーダ 詳細 ファイル形式 / コンテナの形式
オーディオ MPEG-4 AAC プロファイル(AAC LC) マイク ハードウェアを含み、android.hardware.microphone を定義するデバイス実装では必須 必須 標準サンプリング レート 8~48 kHz のモノラル / ステレオ / 5.0 / 5.1* コンテンツをサポート。
  • 3GPP(.3gp)
  • MPEG-4(.mp4、.m4a)
  • ADTS Raw AAC(.aac、Android 3.1 以降でデコード、Android 4.0 以降でエンコード、ADIF はサポート対象外)
  • MPEG-TS(.ts、シーク不可、Android 3.0 以降)
MPEG-4 HE AAC プロファイル(AAC+) マイク ハードウェアを含み、android.hardware.microphone を定義するデバイス実装では必須 必須 標準サンプリング レート 16~48 kHz のモノラル / ステレオ / 5.0 / 5.1* コンテンツをサポート。
MPEG-4 HE AAC v2 プロファイル(Enhanced AAC+)   必須 標準サンプリング レート 16~48 kHz のモノラル / ステレオ / 5.0 / 5.1* コンテンツをサポート。
MPEG-4 オーディオ オブジェクト タイプ ER AAC ELD(Enhanced Low Delay AAC) マイク ハードウェアを含み、android.hardware.microphone を定義するデバイス実装では必須 必須 標準サンプリング レート 16~48 kHz のモノラル / ステレオ コンテンツをサポート。
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**(最大レートはハードウェアの上限値)。デバイスは、Raw PCM 録音のサンプリング レートとして 8,000 Hz、16,000 Hz、44,100 Hz の周波数をサポートしなければなりません 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 4.3 以降)
必須
(Android 2.3.3 以降)
  WebM(.webm)および Matroska(.mkv、Android 4.0 以降)***
VP9   必須
(Android 4.4 以降)
  WebM(.webm)および Matroska(.mkv、Android 4.0 以降)***
  • *注: 5.0/5.1 コンテンツのダウンミックスのみが必須です。2 チャンネルを超える録画またはレンダリングは任意です。
  • **注: 16 ビット リニア PCM のキャプチャは必須です。8 ビット リニア PCM のキャプチャは必須ではありません。
  • ***注: デバイス実装は、Matroska WebM ファイルの書き込みをサポートするべきです。
  • ****注: ウェブ動画ストリーミング サービスとビデオ会議サービスの品質を許容可能なものにするために、デバイス実装は、[参考資料、86] の要件を満たすハードウェア VP8 コーデックを使用するべきです。

5.2. 動画のエンコード

背面カメラが含まれ、android.hardware.camera を宣言する Android デバイス実装は、次の H.264 動画エンコード プロファイルをサポートするべきです。

  SD(低画質) SD(高画質) HD(ハードウェアでサポートされている場合)
動画の解像度 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

背面カメラを含み、android.hardware.camera を宣言する Android デバイス実装は、次の VP8 動画エンコード プロファイルをサポートするべきです。

  SD(低画質) SD(高画質) HD 720p
(ハードウェアでサポートされている場合)
HD 1080p
(ハードウェアでサポートされている場合)
動画の解像度 320 x 180 ピクセル 640 x 360 ピクセル 1,280 x 720 ピクセル 1,920 x 1,080 px
動画のフレームレート 30 fps 30 fps 30 fps 30 fps
動画のビットレート 800 Kbps 2 Mbps 4 Mbps 10 Mbps

5.3. 動画のデコード

Android デバイス実装は、次の VP8、VP9、H.264 動画デコード プロファイルをサポートするべきです。また、デバイス実装は、VP8、VP9、H.264 コーデックの同じストリーム内での動的な動画解像度の切り替えもサポートするべきです。

  SD(低画質) SD(高画質) HD 720p
(ハードウェアでサポートされている場合)
HD 1080p
(ハードウェアでサポートされている場合)
動画の解像度 320 x 180 ピクセル 640 x 360 ピクセル 1,280 x 720 ピクセル 1,920 x 1,080 px
動画のフレームレート 30 fps 30 fps 30 fps 30 fps
動画のビットレート 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.4. 音声録音

マイク ハードウェアを含み、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 dB SPL の入力レベルで 1 KHz に対して 1% 未満であるべきです。

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

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

Android 4.4 以降、android.media.MediaRecorder.AudioSource クラスに新しい音源 REMOTE_SUBMIX が追加されました。デバイスは、アプリが android.media.AudioRecord API を使用してこの音源から録音するときに、下記を除くすべての音声ストリームのミックスをキャプチャできるように、REMOTE_SUBMIX 音源を適切に実装しなければなりません。

  • STREAM_RING
  • STREAM_ALARM
  • STREAM_NOTIFICATION

注: 上記の要件の一部は Android 4.3 以降では「するべき」(原文では SHOULD)と記載されていますが、今後のバージョンの互換性定義では「しなければならない」(原文では MUST)に変更する予定です。つまり、これらの要件は、Android 4.4 では任意ですが、今後のバージョンでは必須になります。Android を搭載した既存または新規のデバイスには、これらの要件を満たすことが強く推奨されます。そうしなかった場合、今後のバージョンへのアップグレードの際に Android 互換性を達成できなくなります。

プラットフォームが音声認識用に調整されたノイズ キャンセレーション技術をサポートしている場合、その効果は android.media.audiofx.NoiseSuppressor API から制御できなければなりません。さらに、ノイズ キャンセラーの効果記述子の「uuid」フィールドでは、ノイズ キャンセレーション技術の各実装を一意に識別しなければなりません。

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

オーディオ レイテンシとは、オーディオ信号がシステムを通過する際に発生する遅延時間のことです。多くの種類のアプリは、レイテンシを短くすることで、リアルタイムのサウンド エフェクトを実現しています。

このセクションの文脈では、次のように用語を定義しています。

  • 「出力レイテンシ」は、アプリが PCM 符号化データフレームを書き込んでから、対応するサウンドが外部のリスナーに聞こえるかトランスデューサで検知されるまでの間隔として定義されます。
  • 「コールド出力レイテンシ」は、リクエストの前に音声出力システムがアイドル状態になり、電源がオフになっていたときの最初のフレームの出力レイテンシとして定義されます。
  • 「連続出力レイテンシ」は、デバイスが音声を再生しているときの後続フレームの出力レイテンシとして定義されます。
  • 「入力レイテンシ」は、外部のサウンドがデバイスに渡されてから、アプリが対応する PCM 符号化データフレームを読み取るまでの間隔です。
  • 「コールド入力レイテンシ」は、リクエストの前に音声入力システムがアイドル状態になり、電源がオフになっていたときの、失われた入力時間と最初のフレームの入力レイテンシの合計として定義されます。
  • 「連続入力レイテンシ」は、デバイスが音声をキャプチャしているときの後続フレームの入力レイテンシとして定義されます。
  • 「OpenSL ES PCM バッファキュー API」は、Android NDK 内の PCM 関連の OpenSL ES API のセットです。NDK_root/docs/opensles/index.html をご覧ください。

セクション 5 に記載されているように、互換性のあるすべてのデバイス実装は、少なくとも 1 つの形式の音声出力を含まなければなりません。デバイス実装は、以下の出力レイテンシの要件を満たすか、上回るべきです。

  • 100 ミリ秒以下のコールド出力レイテンシ
  • 45 ミリ秒以下の連続出力レイテンシ

デバイス実装は、OpenSL ES PCM バッファキュー API を使用する際の初期キャリブレーションの後でこのセクションの要件を満たす場合、少なくとも 1 つのサポートされている音声出力デバイスの連続出力レイテンシとコールド出力レイテンシについて、android.content.pm.PackageManager クラスにより機能「android.hardware.audio.low-latency」をレポートすることで、低レイテンシ オーディオのサポートをレポートしても構いません[参考資料、37]。逆に、上記の要件を満たさない場合、デバイス実装は低レイテンシ オーディオのサポートを報告してはなりません。

セクション 7.2.5 に記載されているように、デバイス実装はマイク ハードウェアを省略しても構いません。

マイク ハードウェアを含み、android.hardware.microphone を宣言するデバイス実装は、次の入力オーディオ レイテンシの要件を満たすべきです。

  • 100 ミリ秒以下のコールド入力レイテンシ
  • 50 ミリ秒以下の連続入力レイテンシ

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

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

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

6. デベロッパー ツール、開発者向けオプションの互換性

6.1. デベロッパー ツール

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

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

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

6.2. 開発者向けオプション

Android は、デベロッパーがアプリ開発関連の設定を構成することをサポートしています。デバイス実装は、android.settings.APPLICATION_DEVELOPMENT_SETTINGS インテントを尊重して、アプリ開発関連の設定を表示しなければなりません [参考資料、77]。アップストリームの Android 実装では、開発者向けオプション メニューはデフォルトで非表示になっています。ユーザーは、[設定] > [デバイス情報] > [ビルド番号] メニュー アイテムを 7 回タップすると、開発者向けオプションを起動できます。デバイス実装は、開発者向けオプションについて一貫性のあるエクスペリエンスを提供しなければなりません。具体的には、デバイス実装は、デフォルトで開発者向けオプションを非表示にしなければならず、アップストリームの Android 実装との一貫性がある、開発者向けオプションを有効にするメカニズムを提供しなければなりません。

6.2.1. 試験運用版

Android 4.4 では、試験運用版の Android ランタイムである ART が導入されており、プレビューの [開発者向けオプション] メニューからアクセスできます。デバイス実装は、ART(libart.so)を含み、開発者向けオプションからのデュアルブートをサポートするべきですが、Dalvik(libdvm.so)はデフォルトのランタイムのままにしなければなりません。

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 には、さまざまなハードウェア構成でサードパーティ アプリが適切に動作するように、デバイスに合わせてアプリアセットと 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 フレームワークはさまざまな画面サイズをサポートしており、アプリは android.content.res.Configuration.screenLayout を使用して SCREENLAYOUT_SIZE_MASK でデバイスの画面サイズ(または「画面レイアウト」)をクエリできます。デバイス実装は、Android SDK ドキュメント [参考資料、38] で規定されていてアップストリームの Android プラットフォームによって決定される正しい画面サイズを報告しなければなりません。具体的には、デバイス実装は、次の論理密度非依存ピクセル(dp)画面寸法に従って、正しい画面サイズを報告しなければなりません。

  • デバイスの画面サイズは、426 dp x 320 dp(small)以上でなければなりません。
  • 画面サイズが「normal」であると報告するデバイスは、画面サイズが少なくとも 480 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.86(おおよそ 16:9)まででなければなりません。

画面密度

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

  • 120 dpi(「ldpi」)
  • 160 dpi(「mdpi」)
  • 213 dpi(「tvdpi」)
  • 240 dpi(「hdpi」)
  • 320 dpi(「xhdpi」)
  • 400 dpi(「400dpi」)
  • 480 dpi(「xxhdpi」)
  • 640 dpi(「xxxhdpi」)
デバイス実装は、画面の物理密度に数値的に最も近い標準の 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.portrait もしくは android.hardware.screen.landscape、またはその両方)を報告しなければならず、サポートする画面の向きを少なくとも 1 つ報告しなければなりません。たとえば、テレビやノートパソコンなど、画面が横向きに固定されているデバイスは、android.hardware.screen.landscape のみを報告しなければなりません。

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

デバイス実装は、Android SDK ドキュメントに具体的に詳述されているように、OpenGL ES 1.0 と 2.0 の両方をサポートしなければなりません。デバイス実装は、OpenGL ES 3.0 をサポートできるデバイスでは OpenGL ES 3.0 をサポートするべきです。デバイス実装は、Android SDK ドキュメント [参考資料、8] に詳述されているように、Android RenderScript もサポートしなければなりません。

また、デバイス実装は、OpenGL ES 1.0、OpenGL ES 2.0、または OpenGL ES 3.0 のサポートを正しく表明しなければなりません。これは次のことを意味します。

  • マネージド API は(GLES10.getString() メソッドなどにより)OpenGL ES 1.0 と OpenGL ES 2.0 のサポートをレポートしなければなりません。
  • ネイティブ C/C++ OpenGL API(つまり、libGLES_v1CM.so、libGLES_v2.so、または libEGL.so を介してアプリから使用できる API)は、OpenGL ES 1.0 と OpenGL ES 2.0 のサポートを報告しなければなりません。
  • OpenGL ES 3.0 のサポートを宣言するデバイス実装は、OpenGL ES 3.0 マネージド API をサポートし、ネイティブ C/C++ API のサポートを含まなければなりません。OpenGL ES 3.0 のサポートを宣言するデバイス実装では、libGLESv2.so は OpenGL ES 2.0 の関数シンボルに加えて OpenGL ES 3.0 の関数シンボルをエクスポートしなければなりません。

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

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

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

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

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

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

Android には、EGLConfig 属性 EGL_ANDROID_RECORDABLE のサポートが含まれています。この属性は、画像を動画に記録する ANativeWindow へのレンダリングを EGLConfig がサポートするかどうかを示します。デバイス実装は、EGL_ANDROID_RECORDABLE 拡張機能 [参考資料、79] をサポートしなければなりません。

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

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

7.1.6. 画面のタイプ

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

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

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

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

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

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

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

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

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

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

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

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

7.1.7. 画面技術

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

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

7.1.8. 外部ディスプレイ

Android は、セカンダリ ディスプレイをサポートしており、メディア共有機能と、外部ディスプレイにアクセスするためのデベロッパー API が有効になります。有線、無線、または埋め込み式のいずれかの追加のディスプレイ接続を介して外部ディスプレイをサポートする場合、デバイス実装は、Android SDK ドキュメントに記載されているとおり、ディスプレイ マネージャー API を実装しなければなりません [参考資料、75]。セキュア動画出力をサポートし、セキュア サーフェスをサポートできるデバイス実装は、Display.FLAG_SECURE のサポートを宣言しなければなりません。具体的には、Display.FLAG_SECURE のサポートを宣言するデバイス実装は、Miracast ワイヤレス ディスプレイの場合は HDCP 2.x 以降、有線ディスプレイの場合は HDCP 1.2 以降をサポートしなければなりません。アップストリームの Android オープンソース実装には、この要件を満たすワイヤレス(Miracast)ディスプレイと有線(HDMI)ディスプレイのサポートが含まれています。

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 は両方の実装をサポートしています。これらすべての機能は、表示されているとき、1 つのアクション(タップ、ダブルクリック、ジェスチャーなど)でアクセスできなければなりません。

戻る機能と履歴機能は、全画面モードで他のナビゲーション機能とともに非表示になっている場合を除き、ボタンまたはアイコンを表示するべきです。ホーム機能は、全画面モードで他のナビゲーション機能とともに非表示になっている場合を除き、ボタンまたはアイコンを表示しなければなりません。

Android 4.0 以降では、メニュー機能が非推奨になり、アクションバーに置き換えられました。デバイス実装は、メニュー機能専用の物理ボタンを実装するべきではありません。物理的なメニューボタンが実装され、デバイスが targetSdkVersion > 10 のアプリを実行している場合、デバイス実装は:

  • Android 4.4 でリリースするデバイスの場合、アクションバーが表示され、その結果のアクション オーバーフロー メニュー ポップアップが空でないとき、アクションバーにアクション オーバーフロー ボタンを表示しなければなりません。
  • 以前のバージョンでリリースされた既存のデバイスを Android 4.4 にアップグレードする場合、アクションバーが表示されて、その結果のアクション オーバーフロー メニュー ポップアップが空でないとき、アクションバーにアクション オーバーフロー ボタンを表示するべきです。
  • アクションバーのオーバーフロー ボタンを選択することで表示されるアクション オーバーフロー ポップアップの位置を変更してはなりません。
  • 物理的なメニューボタンを選択することで表示されるときは、アクション オーバーフロー ポップアップを画面上の変更された位置にレンダリングしても構いません。

下位互換性を確保するため、デバイス実装は、targetSdkVersion <= 10 の場合に、物理ボタン、ソフトウェア キー、ジェスチャーのいずれかによって、メニュー機能をアプリで使用できるようにしなければなりません。このメニュー機能は、他のナビゲーション機能とともに非表示になっている場合を除き、表示されるべきです。

Android は、アシスト アクションをサポートしています [参考資料、63]。デバイス実装は、アプリ実行時に常にアシスト アクションをユーザーが利用できるようにしなければなりません。アシスト アクションは、ホームボタンの長押しか、ソフトウェア ホームキーで上にスワイプするジェスチャーとして実装するべきです。この機能は、別の物理ボタン、ソフトウェア キー、ジェスチャーで実装しても構いませんが、他のナビゲーション キーが表示されているときは 1 つのアクション(タップ、ダブルクリック、ジェスチャーなど)でアクセスできなければなりません。

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

  • デバイス実装のナビゲーション キーは、画面内のアプリが利用できない区分けされた部分を使用しなければなりません。また、画面内のアプリが利用できる部分を隠したり、その他の方法で利用を妨げたりしてはなりません。
  • デバイス実装は、セクション 7.1.1 で規定されている要件を満たすアプリがディスプレイの一部を利用できるようにしなければなりません。
  • デバイス実装は、アプリがシステム UI モードを指定していない場合、または SYSTEM_UI_FLAG_VISIBLE を指定している場合には、ナビゲーション キーを表示しなければなりません。
  • デバイス実装は、アプリが SYSTEM_UI_FLAG_LOW_PROFILE を指定している場合、ナビゲーション キーを目立たない「ロー プロファイル」(例: グレー表示)モードで表示しなければなりません。
  • デバイス実装は、アプリが SYSTEM_UI_FLAG_HIDE_NAVIGATION を指定している場合、ナビゲーション キーを非表示にしなければなりません。

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

デバイス実装は、なんらかの種類のポインタ入力(マウスのような入力またはタップ入力)システムを含むべきです。ただし、デバイス実装がポインタ入力システムをサポートしていない場合は、android.hardware.touchscreen または android.hardware.faketouch 機能定数を報告してはなりません。ポインタ入力システムを含むデバイス実装には、以下の要件が適用されます。

  • デバイス入力システムが複数のポインタをサポートする場合は、完全に独立してトラッキングされるポインタをサポートするべきです。
  • デバイス上の具体的なタッチスクリーンの種類に対応する android.content.res.Configuration.touchscreen の値 [参考資料、40] をレポートしなければなりません。

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

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

7.2.5. 疑似タップ入力

android.hardware.faketouch のサポートを宣言するデバイス実装には、以下の要件が適用されます。

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

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

7.2.6. マイク

デバイス実装はマイクを省略しても構いません。ただし、デバイス実装がマイクを省略する場合は、android.hardware.microphone 機能定数を報告してなはらず、セクション 7 に記載されているように、音声録音 API を NoOps として実装しなければなりません。これに対して、マイクを備えたデバイス実装には、以下の要件が適用されます。

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

7.3. センサー

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

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

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

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

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

7.3.1. 加速度計

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

  • 120 Hz 以上でイベントを配信できるべきです。なお、Android 4.4 では、上記の加速度計の周波数が「するべき」と記載されていますが、今後のバージョンの互換性定義では「しなければならない」に変更される予定です。つまり、これらの標準は Android では任意ですが、今後のバージョンで必須になります。Android を搭載した既存または新規のデバイスは現在、今後のプラットフォーム リリースにアップグレードできるよう、Android のこれらの要件を満たすことが極めて強く奨励されています
  • 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 度)までの方向変化を測定できなければなりません。
  • 200 Hz 以上でイベントを配信できるべきです。なお、Android 4.4 では、上記のジャイロスコープの周波数が「するべき」と記載されていますが、今後のバージョンの互換性定義では「しなければならない」に変更される予定です。つまり、これらの標準は Android では任意ですが、今後のバージョンで必須になります。Android を搭載した既存または新規のデバイスは現在、今後のプラットフォーム リリースにアップグレードできるよう、これらの要件を満たすことが極めて強く奨励されています
  • 正確度が 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.6. 温度計

デバイス実装は、周囲温度計(温度センサー)を含んでも構いません。存在する場合、SENSOR_TYPE_AMBIENT_TEMPERATURE として定義されなければならず、周囲温度(室温)を摂氏で測定しなければなりません。

デバイス実装は、CPU 温度センサーを含んでも構いませんが、そうするべきではありません。存在する場合、SENSOR_TYPE_TEMPERATURE として定義しなければなりません。また、デバイスの CPU の温度を測定しなければならず、他の温度を測定してはなりません。Android 4.0 で SENSOR_TYPE_TEMPERATURE センサータイプが非推奨になりました。

7.3.7. 光度計

デバイス実装は、光度計(周囲光センサー)を含んでも構いません。

7.3.8. 近接センサー

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

7.4. データ接続

7.4.1. 電話

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

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

7.4.2. IEEE 802.11(Wi-Fi)

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

デバイス実装は、SDK ドキュメントに記載されているとおり、マルチキャスト API を実装しなければなりません [参考資料、62]。Wi-Fi をサポートするデバイス実装は、マルチキャスト DNS(mDNS)をサポートしなければなりません。デバイス実装は、画面がアクティブ状態にないときを含め、オペレーション時に mDNS パケット(224.0.0.251)をフィルタしてはなりません。

7.4.2.1. Wi-Fi Direct

デバイス実装は、Wi-Fi Direct(Wi-Fi ピアツーピア)をサポートするべきです。Wi-Fi Direct をサポートする場合、デバイス実装は、SDK ドキュメント [参考資料、68] に記載されているとおり、対応する Android API を実装しなければなりません。Wi-Fi Direct をサポートする場合、デバイス実装は:

  • 通常の Wi-Fi 運用をサポートしなければなりません。
  • Wi-Fi と Wi-Fi Direct の同時使用をサポートするべきです。

7.4.2.2. Wi-Fi Tunneled Direct Link Setup

デバイス実装は、Android SDK ドキュメントに記載されているとおり、Wi-Fi Tunneled Direct Link Setup(TDLS)のサポートを含むべきです [参考資料、85]。TDLS のサポートが含まれ、WiFiManager API で TDLS が有効になっている場合、デバイス実装は:

  • 可能かつ有効な場合にのみ、TDLS を使用するべきです。
  • TDLS のパフォーマンスが Wi-Fi アクセス ポイントを通過する場合よりも悪くなる可能性がある場合は、TDLS を使用せず、なんらかのヒューリスティックを使用するべきです。

7.4.3. Bluetooth

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

Bluetooth Smart または Smart Ready デバイスとの通信を可能にする Bluetooth GATT(汎用属性プロファイル)のサポートを含むデバイス実装は、SDK ドキュメントに記載されているように GATT ベースの Bluetooth API を有効にするとともに、ハードウェア機能 android.hardware.bluetooth_le を宣言しなければなりません [参考資料、42]。

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 を搭載した既存または新規のデバイスは現在、今後のプラットフォーム リリースにアップグレードできるよう、これらの要件を満たすことが極めて強く奨励されています
    • NfcV(ISO 15693)
  • 以下のピアツーピア標準とプロトコルを使用してデータを送受信できなければなりません。
    • ISO 18092
    • LLCP 1.0(NFC フォーラムにより定義)
    • SDP 1.0(NFC フォーラムにより定義)
    • NDEF プッシュ プロトコル [参考資料、43]
    • SNEP 1.0(NFC フォーラムにより定義)
  • Android ビーム [参考資料、65] のサポートを含まなければなりません。
    • SNEP デフォルト サーバーを実装しなければなりません。デフォルト SNEP サーバーが受信する有効な NDEF メッセージは、android.nfc.ACTION_NDEF_DISCOVERED インテントを使用してアプリにディスパッチされなければなりません。設定で Android ビームを無効にすることにより、受信 NDEF メッセージのディスパッチを無効にしてはなりません。
    • デバイス実装は、android.settings.NFCSHARING_SETTINGS インテントを尊重して、NFC 共有設定 [参考資料、67] を表示しなければなりません。
    • 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 ビームをデフォルトで有効にするべきです。
    • デバイスが Bluetooth オブジェクト プッシュ プロファイルをサポートしている場合は、Bluetooth への NFC 接続ハンドオーバーをサポートしなければなりません。android.nfc.NfcAdapter.setBeamPushUris を使用する場合、デバイス実装は「接続ハンドオーバー バージョン 1.2」[参考資料、60 ]、NFC フォーラムから「NFC を使用した Bluetooth Secure Simple Pairing バージョン 1.0」[参考資料、61] を実装して Bluetooth への接続ハンドオーバーをサポートする必要があります。このような実装では、NFC を介してハンドオーバー リクエスト / 選択レコードを交換するために、サービス名「urn:nfc:sn:handover」を持つハンドオーバー LLCP サービスを実装しなければならず、実際の Bluetooth データ転送には Bluetooth オブジェクト プッシュ プロファイルを使用しなければなりません。従来の理由(Android 4.1 デバイスとの互換性を維持する)のために、実装では NFC を介してハンドオーバー リクエスト / 選択レコードを交換するために SNEP GET リクエストを引き続き受け入れるべきです。ただし、実装自体が、接続の引き渡しを実行するための SNEP GET リクエストを送信するべきではありません。
  • NFC 検出モードにあるとき、サポートされているすべての技術をポーリングしなければなりません。
  • 画面がアクティブでロック画面がロック解除された状態でデバイスが起動しているときは、NFC 検出モードになるべきです

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

Android 4.4 では、NFC ホストカード エミュレーション(HCE)モードのサポートが導入されました。HCE とアプリケーション ID(AID)ルーティングの機能がある NFC コントローラが含まれる場合、デバイス実装は:

  • android.hardware.nfc.hce 機能定数をレポートしなければなりません。
  • Android SDK で定義されているとおり、NFC HCE API をサポートしなければなりません [参考資料、90]。

さらに、デバイス実装は、以下の MIFARE 技術のリーダー / ライターをサポートしても構いません。

Android には、これらの 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 NFC API を NoOps として実装しなければなりません。

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

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

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

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

複数の形式のデータ接続を実装しても構いません。

7.4.6. 同期設定

デバイス実装は、メソッド getMasterSyncAutomatically() が「true」を返すように、マスター自動同期設定をデフォルトでオンにしなければなりません [参考資料、88]。

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(つまり、640x480 ピクセル)でなければなりません。
  • 前面カメラを Camera API のデフォルトとして使用してはなりません。つまり、Android の 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 SDK のドキュメント [参考資料、51] に含まれる Camera API を完全に実装しなければなりません。たとえば、オートフォーカスのないカメラは、(オートフォーカスのないカメラには関係がなくとも)登録された android.hardware.Camera.AutoFocusCallback インスタンスを引き続き呼び出さなければなりません。なお、これは前面カメラに適用されます。たとえば、ほとんどの前面カメラはオートフォーカスをサポートしませんが、それでも前述のように API コールバックを「偽装」しなければなりません。

デバイス実装は、基盤となるハードウェアがこの機能をサポートしている場合、android.hardware.Camera.Parameters クラスの定数として定義された各パラメータ名を認識し、尊重しなければなりません。デバイス ハードウェアが機能をサポートしていない場合、API はドキュメントに記載されているとおりに動作しなければなりません。逆に、デバイス実装は android.hardware.Camera.Parameters で定数として記述されているもの以外は、android.hardware.Camera.setParameters() メソッドに渡される文字列定数を尊重または認識してはなりません。つまり、デバイス実装は、ハードウェアが許すならば標準的なカメラ パラメータをすべてサポートしなければならず、カスタムのカメラ パラメータ タイプをサポートしてはなりません。たとえば、ハイ ダイナミック レンジ(HDR)画像処理手法を使用する画像キャプチャをサポートするデバイス実装は、カメラ パラメータ Camera.SCENE_MODE_HDR をサポートしなければなりません [参考資料、78]。

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

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

7.5.4. カメラの向き

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

7.6. メモリとストレージ

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

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

カーネルとユーザー空間に利用できるメモリが 512 MB 未満のデバイス実装は、ActivityManager.isLowRamDevice() で「true」の値を返さなければなりません。

デバイス実装には、アプリの個人データに使用できる不揮発性ストレージが少なくとも 1 GB 用意されていなければなりません。つまり、/data パーティションは少なくとも 1 GB でなければなりません。Android を搭載するデバイス実装には、今後のプラットフォーム リリースにアップグレードできるよう、アプリの個人データ用に不揮発性ストレージを 2 GB 以上用意すること非常に強く推奨されます

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

7.6.2. 共有外部ストレージ

デバイス実装では、アプリ用の共有ストレージを提供しなければなりません。提供する共有ストレージのサイズは少なくとも 1 GB でなければなりません。

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

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

デバイス実装は、セキュア デジタルカードなど、ユーザーがアクセス可能なリムーバブル ストレージのハードウェアを備えていても構いません。または、デバイス実装は、アプリの共有ストレージとして内部(取り外し不可能)ストレージを割り当てても構いません。アップストリームの Android オープンソース プロジェクトには、共有外部ストレージ API に内部デバイス ストレージを使用する実装が含まれています。デバイス実装では、この構成とソフトウェア実装を使用するべきです。

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

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

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

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

複数の共有ストレージパス(SD カードスロットと共有内部ストレージの両方など)を含むデバイス実装は、パッケージ固有のディレクトリを除き、Android アプリにセカンダリ外部ストレージへの書き込みを許可してはなりません。ただし、Android のメディア スキャナ サービスと android.provider.MediaStore を通じて、両方のストレージパスからコンテンツを透過的に公開するべきです。

7.7. USB

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

デバイス実装が USB クライアント ポートを含む場合は、以下の要件が適用されます。

  • ポートは標準の USB-A ポートで USB ホストに接続できなければなりません。
  • ポートはデバイス側でマイクロ USB フォーム ファクタを使用するべきです。Android を搭載した既存または新規のデバイスは現在、今後のプラットフォーム リリースにアップグレードできるよう、Android のこれらの要件を満たすことが極めて強く奨励されています
  • ポートはエッジの中央に配置するべきです。デバイス実装は、デバイスの下部にある(自然な縦向きに基づく)ポートを探すか、すべてのアプリ(ホーム画面を含む)でソフトウェアの画面回転を可能にし、デバイスの向きが下部のポートで設定された場合にディスプレイが正しく描画されるようにするべきです。Android を搭載した既存または新規のデバイスは現在、今後のプラットフォーム リリースにアップグレードできるよう、Android のこれらの要件を満たすことが極めて強く奨励されています
  • デバイスにその他のポート(USB 以外の充電ポートなど)がある場合、マイクロ USB ポートと同じエッジにあるべきです。
  • デバイスに接続されたホストが、USB マスストレージまたはメディア転送プロトコルを使用して、共有ストレージ ボリュームの内容にアクセスできるようにしなければなりません。
  • Android SDK ドキュメントに記載されているように、Android Open Accessory API と仕様を実装しなければならず、ハードウェア機能 android.hardware.usb.accessory のサポートを宣言しなければなりません [参考資料、52]。
  • Android SDK ドキュメント [参考資料、66] に記載されているとおり USB オーディオ クラスを実装しなければなりません。
  • USB バッテリー充電仕様のサポートを実装するべきです [参考資料、64]。Android を搭載している既存のデバイスと新しいデバイスは、今後のプラットフォーム リリースにアップグレードできるように、これらの要件を満たすことが強く推奨されます
  • USB 標準デバイス記述子の iSerialNumber の値は、android.os.Build.SERIAL の値と等しくなければなりません。

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

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

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

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

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

指標 パフォーマンスしきい値 コメント
アプリ起動時間 次のアプリは、示された時間内に起動すべきです。
  • ブラウザ: 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 とプロセスの分離

デバイス実装は、Android アプリ サンドボックス モデル(各アプリが個別のプロセスで一意の Unix 形式の UID として動作するモデル)をサポートしなければなりません。デバイス実装は、セキュリティと権限に関するリファレンス [参考資料、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 サンドボックスを提供しても構いません。
  • 代替ランタイムと、代替ランタイムを使用するインストール済みアプリは、標準的な Android メカニズム(共有ユーザー ID と署名証明書)を使用する場合を除き、デバイスにインストールされている他のアプリのサンドボックスを再利用してはなりません。
  • 代替ランタイムは、他の Android アプリに対応するサンドボックスで起動されてはならず、そのようなサンドボックスへのアクセス権を付与しても付与されてもなりません。

代替ランタイムは、スーパーユーザー(root)または他のユーザー ID の特権で起動されてはならず、そのような特権を他のアプリに付与しても他のアプリから付与されてもなりません。

代替ランタイムの .apk ファイルは、デバイス実装のシステム イメージに含まれていても構いませんが、デバイス実装に含まれる他のアプリの署名に使用される鍵とは異なる鍵で署名されなければなりません。

代替ランタイムは、アプリのインストール時に、アプリが使用する Android 権限についてユーザーの同意を取得しなければなりません。つまり、対応する Android 権限があるデバイス リソース(カメラや GPS など)をアプリが利用する必要がある場合、代替ランタイムは、アプリがそのリソースにアクセスできることをユーザーに通知しなければなりません。ランタイム環境がこのような方法でアプリの機能を記録しない場合、ランタイム環境は、そのランタイムを使用してアプリがインストールされる際に、ランタイム自体が保有するすべての権限をリストしなければなりません。

9.5. マルチユーザー サポート

Android では複数のユーザーをサポートしており、ユーザーの完全な分離がサポートされています [参考資料、70]。

デバイス実装は、マルチユーザー サポートに関連する次の要件を満たさなければなりません [参考資料、71]。

  • 複数のユーザーが使用するデバイスでのテレフォニー API の動作は現在定義されていないため、android.hardware.telephony を宣言するデバイス実装はマルチユーザー サポートを有効にしてはなりません。
  • デバイス実装では、ユーザーごとに、API のセキュリティと権限に関するリファレンス ドキュメント [参考資料、54] で規定されているとおり、Android プラットフォームのセキュリティ モデルに合致するセキュリティ モデルを実装しなければなりません。
  • Android には、制限付きプロファイル(追加ユーザーと、追加ユーザーがデバイス上でできることをデバイス オーナーが管理できるようにする機能)のサポートが含まれています。制限付きプロファイルにより、デバイス オーナーは、追加のユーザーが使用する個別の環境をすばやく設定でき、その環境で利用できるアプリの制限をきめ細かく管理できます。複数ユーザーのサポートを含むデバイス実装は、制限付きプロファイルのサポートを含まなければなりません。アップストリームの Android オープンソース プロジェクトには、この要件を満たす実装が含まれています。

Android デバイス上のユーザー インスタンスごとに、個別の分離された外部ストレージ ディレクトリが存在しなければなりません。デバイス実装は、複数のユーザーのデータを同じボリュームまたはファイルシステムに保存しても構いません。ただし、デバイス実装は、特定のユーザーが所有し、そのユーザーに代わって実行されるアプリが、他のユーザーが所有するデータを一覧表示 / 読み取り / 書き込みできないようにしなければなりません。SD カードスロットなどのリムーバブル メディアを使用すると、あるユーザーがホストのパソコンを使用して別のユーザーのデータにアクセスできるようになります。したがって、外部ストレージ API 用にリムーバブル メディアを使用するデバイス実装は、システムのみがアクセスできる非リムーバブル メディアにのみ保存されるキーを使用してマルチユーザーを有効にする場合、SD カードの内容を暗号化しなければなりません。これにより、ホスト PC でメディアを読み取れなくなるため、デバイス実装は、ホスト PC から現在のユーザーのデータにアクセスできるようにするため、MTP または同様のシステムに切り替える必要があります。したがって、デバイス実装では、プライマリ外部ストレージにリムーバブル メディア [参考資料、72] を使用する場合に、マルチユーザーを有効にしても構いませんが、そうするべきではありません。

9.6. プレミアム SMS の警告

Android は、プレミアム SMS メッセージの送信についてユーザーに警告することをサポートしています [参考資料、73]。プレミアム SMS メッセージとは、携帯通信会社に登録されたサービスに送信されるテキスト メッセージのことであり、ユーザーに課金される可能性があります。android.hardware.telephony のサポートを宣言するデバイス実装は、デバイスの /data/misc/sms/codes.xml ファイルで定義された正規表現で識別される番号に SMS メッセージを送信する前に、ユーザーに警告しなければなりません。アップストリームの Android オープンソース プロジェクトは、この要件を満たす実装を提供しています。

9.7. カーネル セキュリティ機能

Android サンドボックスには、Linux カーネルの Security-Enhanced Linux(SELinux)の強制アクセス制御(MAC)システムなどのセキュリティ機能を使用する機能があります。SELinux などのセキュリティ機能(Android フレームワークの下に実装されている場合)は:

  • 既存のアプリとの互換性を維持しなければなりません。
  • 違反が検出された場合でも、ユーザー インターフェースを表示してはなりません。
  • ユーザーまたはデベロッパーが設定できるようにするべきではありません。

ポリシーを構成するための API が、別のアプリに影響する可能性のあるアプリ(Device Administration API など)に公開されている場合、API は互換性を破る構成を許可してはなりません。

デバイスは、SELinux を実装し、次の要件を満たさなければなりません(この要件は、アップストリームの Android オープンソース プロジェクトのリファレンス実装によって満たされます)。

  • 次のようなドメインごとの SELinux モードの設定を許可する SELinux ポリシーをサポートしなければなりません。
    • アップストリームの Android オープンソース実装で enforcing モードになっているドメイン(installd、netd、vold など)は、enforcing モードでなければなりません。
    • サードパーティ アプリのドメインは、互換性を維持するために、permissive モードを維持するべきです。
  • デバイス上の /sepolicy ファイルからポリシーをロードするべきです。
  • システム イメージの更新を求めずに SELinux ポリシー ファイルの動的更新を行うことをサポートしなければなりません。
  • アプリの動作を妨げたり、システムの動作に影響を与えたりすることなく、ポリシー違反をログに記録しなければなりません。

デバイス実装は、SELinux ポリシーへの追加を最初に監査するまで、アップストリームの Android オープンソース プロジェクトで提供されるデフォルトの SELinux ポリシーを保持するべきです。デバイス実装は、アップストリームの Android オープンソース プロジェクトと互換性がなければなりません。

9.8. プライバシー

デバイス実装が、画面に表示されたコンテンツをキャプチャする機能や、デバイスで再生されているオーディオ ストリームを録音する機能を含む場合、この機能が有効でアクティブにキャプチャや録画を行っている間は、常にユーザーに通知しなければなりません。

9.9. フルディスク暗号化

ロック画面があるデバイスは、フルディスク暗号化をサポートしなければなりません。

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

デバイス実装は、このセクションに記載されているすべてのテストに合格しなければなりません。

しかし、完全に包括的なソフトウェア テスト パッケージというものはありません。このためデバイス実装者は、Android オープンソース プロジェクトから入手できる Android のリファレンス実装と優先実装に対して行う変更を可能な限り最小限に抑えることが強く推奨されます。これにより、互換性の問題をもたらすバグが導入され、再作業やデバイスのアップデートが必要となるリスクを最小限に抑えることができます。

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

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

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

10.2. CTS 検証ツール

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

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

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

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

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

  • 「Android 向けアプリ」[参考資料、55] のアプリ。
  • Replica Island(Google Play ストアで入手可能)

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

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

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

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

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

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

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

12. ドキュメントの変更履歴

次の表に、このリリースでの互換性定義に対する変更の概要を示します。

セクション 変更の概要
3.2.2. ビルド パラメータ BRAND、DEVICE、PRODUCT の説明を修正。SERIAL が必須になりました。
3.2.3.5. デフォルト アプリの設定 新しいデフォルト アプリケーション設定を遵守するための要件を追加した新しいセクション
3.3.1. アプリケーション バイナリ インターフェース android.os.Build.CPU_ABI パラメータと android.os.Build.CPU_ABI2 パラメータに使用できる値を明確にしました。
3.4.1. WebView の互換性 必要な WebView の実装として Chromium を追加しました。
3.7. 仮想マシンの互換性 xxhdpi と 400dpi の画面密度の要件を追加しました。
3.8.6. テーマ 半透明のシステムバーの使用を反映するよう更新しました。
3.8.12. 位置情報 位置情報の設定を一元的にする要件を追加する新しいセクション。
3.8.13. Unicode 絵文字のサポートに関する要件を追加する新しいセクション。
3.9. デバイス管理 プリインストールされている管理アプリは、デフォルトのデバイス オーナー アプリにはできないことを記載しました。
5.1. メディア コーデック VP9 デコーダの要件を追加しました。ハードウェア VP8 コーデックの推奨仕様を追加しました。
5.3. 動画のデコード VP9 を追加しました。動的解像度の切り替えに関する推奨事項を追加しました。
5.4. 録音 新しい必須音源として REMOTE_SUBMIX を追加しました。android.media.audiofx.NoiseSuppressor API の使用を必須にしました。
6.2.1 試験運用版 ART ランタイムを導入し、Dalvik をデフォルトのランタイムにする新しいセクション。
7.1.1. 画面構成 アスペクト比 1.85 を 1.86 に置き換えました。400 dpi の画面密度を追加しました。
7.1.6. 画面のタイプ 640 dpi(4K)の解像度設定を追加しました。
7.2.3. ナビゲーション キー 履歴機能を必須として追加しました。メニュー機能の優先順位を下げました。
7.3.6. 温度計 推奨温度計として SENSOR_TYPE_AMBIENT_TEMPERATURE を追加しました。
7.4.2.2. Wi-Fi Tunneled Direct Link Setup Wi-Fi Tunneled Direct Link Setup(TDLS)のサポートを追加する新しいセクション。
7.4.4. 近距離無線通信 要件としてホスト カード エミュレーション(HCE)を追加しました。SNEP GET を論理リンク制御プロトコル(LLCP)に置き換え、要件として Bluetooth オブジェクト プッシュ プロファイルを追加しました。
7.4.6. 同期設定 自動同期データをデフォルトで有効にする要件を追加する新しいセクション。
7.6.1. 最小のメモリとストレージ メモリが 512 MB 未満のデバイス向けの ActivityManager.isLowRamDevice() の設定に関する要件を追加しました。ストレージ要件をそれぞれ 512 MB と 1 GB から 1 GB と 2 GB に増やしました。
7.6.2. 共有「外部」ストレージ セクション名の変更や、このセクションに合うテキストをセクション 9.5 から移動するなどの編集上の修正。アプリケーションによるセカンダリ外部ストレージ上のパッケージ固有のディレクトリへの書き込みが可能であることを記載しました。
7.7. USB すべてのデバイスで USB シリアル番号をレポートする必要があるという要件を追加しました。
9.5. マルチユーザー サポート マルチユーザー固有でないテキストをセクション 7.6.2 に移動しました。
9.7. カーネル セキュリティ機能 SELinux の enforcing モードへの切り替えと、ユーザー インターフェースに SELinux の出力をレンダリングしないという要件を明記しました。
9.8. プライバシー 録音と録画の必須要件でユーザーに対する継続的な通知がトリガーされるという要件を追加する新しいセクション。
9.9. フルディスク暗号化 ロック画面があるデバイスでフルディスク暗号化をサポートするという要件を追加する新しいセクション。
12. ドキュメントの変更履歴 CDD の変更をセクションごとにまとめる新しいセクション。

 

13. お問い合わせ

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