Android 4.1 互換性定義
リビジョン 3
最終更新日: 2013 年 6 月 24 日
Copyright © 2012, Google Inc. Al rights reserved.
compatibility@android.com
目次
1.はじめに
2.リソース
3.ソフトウェア
3.1.マネージド API の互換性
3.2。ソフト API の互換性
3.2.1.権限
3.2.2.ビルド パラメータ
3.2.3.インテントの互換性
3.2.3.1.コアアプリ インテント
3.2.3.2.インテントのオーバーライド
3.2.3.3.インテントの名前空間
3.2.3.4.ブロードキャスト インテント
3.3.ネイティブ API の互換性
3.3.1 アプリケーション バイナリ インターフェース
3.4.ウェブの互換性
3.4.1.WebView の互換性
3.4.2.ブラウザの互換性
3.5.API 動作の互換性
3.6.API 名前空間
3.7.仮想マシンの互換性
3.8.ユーザー インターフェースの互換性
3.8.1.ウィジェット
3.8.2.通知
3.8.3.検索
3.8.4.トースト
3.8.5.テーマ
3.8.6.ライブ壁紙
3.8.7. 最近使用したアプリの表示
3.8.8.入力管理 設定
3.8.9.ロック画面のリモコン
3.9 デバイス管理
3.10 ユーザー補助
3.11 テキスト読み上げ
4.アプリ パッケージの互換性
5.マルチメディアの互換性
5.1.メディア コーデック
5.2.動画のエンコード
5.3.音声録音
5.4.オーディオ レイテンシ
5.5.ネットワーク プロトコル
6.デベロッパー ツールの互換性
7.ハードウェアの互換性
7.1.ディスプレイとグラフィック
7.1.1.画面構成
7.1.2.ディスプレイの指標
7.1.3.画面の向き
7.1.4.2D と 3D のグラフィック アクセラレーション
7.1.5.レガシーアプリの互換モード
7.1.6.画面のタイプ
7.1.7.画面技術
7.2.[デバイス] に入力
7.2.1。キーボード
7.2.2.タップ以外のナビゲーション
7.2.3.ナビゲーション キー
7.2.4.タッチスクリーン入力
7.2.5.疑似タップ入力
7.2.6.マイク
7.3.センサー
7.3.1.加速度計
7.3.1.加速度計
7.3.2.磁力計
7.3.3. GPS
7.3.4.ジャイロスコープ
7.3.5.気圧計
7.3.6.温度計
7.3.7.光度計
7.3.8.近接センサー
7.4.データ接続
7.4.1.電話
7.4.2. IEEE 802.11 （Wi-Fi）
7.4.2.1.Wi-Fi Direct
7.4.3.Bluetooth
7.4.4.近距離無線通信
7.4.5.最低限のネットワーク機能
7.5. Cameras
7.5.1.背面カメラ
7.5.2.前面カメラ
7.5.3.カメラ API の動作
7.5.4.カメラの向き
7.6.メモリとストレージ
7.6.1.最小メモリとストレージ
7.6.2.アプリ共有ストレージ
7.7. USB
8.パフォーマンスの互換性
9.セキュリティ モデルの互換性
9.1.権限
9.2.UID とプロセスの分離
9.3.ファイルシステムの権限
9.4.代替実行環境
10.ソフトウェア互換性テスト
10.1.互換性テストスイート
10.2。CTS 検証ツール
10.3。リファレンス アプリ
11.アップデート可能なソフトウェア
12.お問い合わせ
付録 A - Bluetooth のテスト手順
1.概要
このドキュメントでは、デバイスが Android 4.1 との互換性を維持するために満たさなければならない要件を列挙しています。
「must」、「must not」、「required」、「shall」、「shall not」、「should」、「should not」、「recommended」、「may」、「optional」の使用は、RFC2119
[参考資料、1] で定義されている IETF 標準に従います。
このドキュメントで使用する「デバイス実装者」および「実装者」という用語は、Android 4.1 を実行するハードウェア/ソフトウェア ソリューションを開発する人または組織を指します。
「デバイス実装」または「実装」とは、そのように開発されたハードウェア/ソフトウェア ソリューションを指します。
Android 4.1 と互換性があるとみなされるには、デバイス実装で、この互換性定義に示された要件（参照により盛り込まれたドキュメントを含む）を満たさなければなりません。
この定義またはセクション 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.1 で許可されているバージョン文字列:
http://source.android.com/compatibility/4.1/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/webdatabase/
16。 HTML5/W3C の IndexedDB API: http://www.w3.org/TR/IndexedDB/
17。Dalvik 仮想マシンの仕様: Android ソースコードの
/dalvik/docs
で入手可能。 AppWidgets:
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-
wal papers.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 テストツール:
https://developer.android.com/studio/test/other-testing-tools/monkey
37. Android android.content.pm.PackageManager クラスとハードウェア Features
リスト:
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 Push Protocol: 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. Android 向けアプリ: 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 Draft Protocol: 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. Wifi マルチキャスト 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 Charging Specification:
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 Audio:
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/media/RemoteControlClient.html
70. モーション イベント API:
http://developer.android.com/reference/android/view/MotionEvent.html
71. タッチ入力の構成: http://source.android.com/tech/input/touch-
devices.html
上記の参考資料の多くは、Android 4.1 SDK から直接的または間接的に派生したものであり、
その SDK のドキュメントに記載されている情報と機能的にまったく同じです。
この互換性定義または互換性テストスイートと SDK ドキュメントの間に相違がある場合、SDK ドキュメントが正式なものであるとみなされます。
上記の参考資料に記載されている技術的な詳細情報はすべて、この互換性定義の一部とみなされます。
3.ソフトウェア
3.1.マネージド API の互換性
マネージド（Dalvik ベース）実行環境は、Android アプリを実行するための主要な手段です。
Android アプリケーション プログラミング インターフェース（API）は、マネージド VM 環境で実行されるアプリに公開される Android プラットフォーム インターフェースのセットです。
デバイス実装は、Android 4.1 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.2.ビルド パラメータ
Android API には、現在のデバイスを記述するための android.os.Build クラス
[参考資料、6] の定数がいくつか含まれています。デバイス実装間で一貫した意味のある値を提供するために、デバイス実装が従わなければならない、これらの値の形式に関する追加の制限を下表に示します。
パラメータ
コメント
現在実行中の Android システムのバージョン（人が読める形式）。このフィールドには、[参考資料、7] で定義されている文字列値のいずれかを指定しなければなりません。
android.os.Build.VERSION.RELEASE
現在実行している Android システムのバージョン（サードパーティ アプリコードからアクセスできる形式）。
android.os.Build.VERSION.SDK
Android 4.1 の場合、このフィールドには整数値 16 を指定しなければなりません。
現在実行している Android システムのバージョン（サードパーティ アプリコードからアクセスできる形式）。
android.os.Build.VERSION.SDK_INT
Android 4.1 の場合、このフィールドには整数値 16 を指定しなければなりません。
現在実行している Android システムの特定のビルドを指定する、デバイス実装者が選択した値（人が読める形式）。
この値は、
android.os.Build.VERSION.INCREMENTAL
エンドユーザーが利用できる別のビルドに再利用してはなりません。このフィールドは主に、ビルドの生成に使用されたビルド番号またはソース管理変更 ID を示すために使用します。
このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。
デバイスの実装者が選択した値で、デバイスで使用される特定の内部ハードウェアを識別します。
人間が判読できる形式で指定します。
このフィールドは、デバイスに電力を供給するボードの特定のリビジョンを示すために使用できます。
android.os.Build.BOARD
このフィールドの値は、7 ビット ASCI としてエンコード可能であって、正規表現「^[a-zA-Z0-9.,_-]+$」に一致しなければなりません。
デバイスの実装者が選択した値で、デバイスを製造した会社、組織、個人などの名前を人間が判読できる形式で識別します。
このフィールドは、デバイスを販売した OEM
android.os.Build.BRAND
または携帯通信会社を示すために使用します。このフィールドの値は、7 ビット ASCI としてエンコード可能であって、
正規表現「^[a-zA-Z0-9.,_-]+$」に一致しなければなりません。
ネイティブ コードのインストラクション セットの名前（CPU タイプ + ABI 規則）。セクション 3.3: ネイティブ API
android.os.Build.CPU_ABI
の互換性をご覧ください。
ネイティブ コードの 2 番目の命令セットの名前（CPU タイプ + ABI 規則）。セクション 3.3: ネイティブ
android.os.Build.CPU_ABI2
API の互換性をご覧ください。
デバイスの筐体の具体的な構成またはリビジョン（「工業デザイン」と呼ばれることもあります）を識別する、デバイス実装者が選択した値
android.os.Build.DEVICE
（デバイスの「工業デザイン」）。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9.,_-]+$」に一致しなければなりません。
このビルドを一意に識別する文字列。
人が読める程度の形式にすべきです。
テンプレート:
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
例:
android.os.Build.FINGERPRINT
acme/mydevice/generic:4.1/JRN53/3359:userdebug/test-keys
フィンガープリントには空白文字を含めてはなりません。上記のテンプレートに含まれる他のフィールドに
空白文字がある場合、ビルドのフィンガープリントではアンダースコア（_）などの別の文字に置き換えなければなりません。
このフィールドの値は 7 ビット ASCI としてエンコード可能でなければなりません。
ハードウェアの名前（カーネル コマンドラインまたは /proc から）。人が読める程度の形式にすべきです。
android.os.Build.HARDWARE
このフィールドの値は、7 ビット ASCI としてエンコード可能であって、正規表現「^[a-
zA-Z0-9.,_-]+$」に一致しなければなりません。
ビルドがビルドされたホストを一意に識別する文字列（人間が判読できる形式）。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。
デバイスの実装者が特定のリリースを参照するために選択した識別子（人間が判読できる形式）。
このフィールドは android.os.Build.VERSION.INCREMENTAL と同じ内容にできますが、エンドユーザーがソフトウェア ビルドを区別できるような意味のある値にすべきです。
このフィールドの値は、7 ビット ASCI としてエンコード可能で、正規表現「^[a-zA-Z0-9.,_-]+$」に一致しなければなりません。
製品の元の機器メーカー（OEM）の商号。
android.os.Build.MANUFACTURER
このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。
デバイスの実装者が選択した値。エンドユーザーに知られているデバイスの名前が含まれます。この
android.os.Build.MODEL
は、デバイスが市販され、エンドユーザーに販売される際の名前と同じにする必要があります。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。
デバイス実装者が選択した値。製品の開発名またはコードネーム
android.os.Build.PRODUCT
（SKU）を含む。
人が読める形式でなければなりませんが、必ずしもエンドユーザーに表示することを意図したものではありません。このフィールドの値は、7 ビット ASCI としてエンコード可能であって、正規表現「^[a-zA-Z0-9.,_-]+$」に一致しなければなりません。
ハードウェアのシリアル番号（利用可能な場合）。
このフィールドの値は、7 ビット ASCI としてエンコード可能であって、
android.os.Build.SERIAL
正規表現「^([a-zA-Z0-9]{0,20})$」に一致しなければなりません。
デバイスの実装者が選択したタグのカンマ区切りリスト。ビルドをさらに区別します。
android.os.Build.TAGS
例: 「unsigned,debug」。このフィールドの値は、7 ビット ASCI としてエンコード可能であって、正規表現「^[a-zA-Z0-9.,_-]+$」に一致しなければなりません。
android.os.Build.TIME
ビルドが発生したときの時刻を表す値。
ビルドのランタイム構成を指定する、デバイス実装者が選択した値。このフィールドには、典型的な 3 つの Android ランタイム構成（user、
android.os.Build.TYPE
userdebug、eng）に対応する値のいずれかを指定すべきです。
このフィールドの値は、7 ビット ASCI としてエンコード可能であって、正規表現「^[a-zA-Z0-9.,_-]+$」に一致しなければなりません。
ビルドを生成したユーザー（または自動化されたユーザー）の名前またはユーザー ID。
android.os.Build.USER
このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。
3.2.3.インテントの互換性
デバイス実装では、以下の各セクションに記載されているように、Android の疎結合インテント システムを尊重しなければなりません。
「尊重する」とは、デバイス実装者が、一致するインテント フィルタを指定し、指定されたインテント パターンごとに正しい動作をバインドして実装する Android のアクティビティまたはサービスを提供しなければならないことを意味します。
3.2.3.1.コアアプリのアプリ インテント
Android のアップストリーム プロジェクトでは、連絡先、カレンダー、フォト ギャラリー、音楽プレーヤーなど、多くのコアアプリを定義しています。
デバイス実装者は、
これらのアプリを代替バージョンに置き換えても構いません。
ただし、そのような代替バージョンは、アップストリーム プロジェクトが提供するものと同じインテント パターンを尊重しなければなりません。
たとえば、デバイスに代替の音楽プレーヤーが含まれている場合でも、サードパーティ アプリによって発行されたインテント パターンを尊重して曲を選択しなくてはなりません。
次のアプリはコア Android システムアプリと見なされます。
デスク クロック
ブラウザ
カレンダー
連絡先
ギャラリー
グローバル検索
ランチャー
音楽
設定
コア Android システムアプリには、「パブリック」とみなされるさまざまな Activity または Service コンポーネントが含まれます。
つまり、属性「android:exported」が存在しないか、値が「true」である可能性があります。
コア Android システムアプリのいずれかで定義され、
android:exported 属性で値「false」を使用して非公開としてマークされていないすべてのアクティビティまたはサービスについて、デバイス実装には、コア Android システムアプリと同じインテント フィルタ パターンを実装する同じタイプのコンポーネントが含まれていなければなりません。
つまり、デバイス実装はコア Android システムアプリを置き換えても構いませんが、その場合は、置き換えられる各コア Android システムアプリで定義されたすべてのインテント パターンをサポートしなければなりません。
3.2.3.2.インテントのオーバーライド
Android は拡張可能なプラットフォームであるため、デバイス実装は、セクション 3.2.3.2 で参照されている各インテント パターンをサードパーティ アプリでオーバーライドできるようにしなければなりません。
アップストリームの Android オープンソース実装では、デフォルトでこれが可能です。デバイス実装者は、システムアプリによるそのようなインテント パターンの使用に特別な権限を付与してはなりません。また、サードパーティ アプリがそのようなパターンをバインドしてはならず、それらを制御することを前提としてはなりません。
これによって禁止される行為には、たとえば、同じインテント パターンを処理する複数のアプリからユーザーが選択することを許可する「選択的」ユーザー インターフェースを無効にすることが含まれますが、これに限定されません。
ただし、デフォルト アクティビティがデータ URI に対してより限定的なフィルタを提供する場合、デバイス実装は限定的な URI パターン（例: http://play.google.com）用のデフォルト アクティビティを提供しても構いません。
たとえば、データ URI「http://www.android.com」を指定するインテント フィルタは、「http://」を指定するブラウザ フィルタよりも限定的です。
デバイス実装は、ユーザーがインテントのデフォルト アクティビティを変更できるユーザー インターフェースを提供する
必要があります。
3.2.3.3.インテント Namespace
デバイス実装は、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.html で多数のアプリケーション バイナリ インターフェース（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（数学ライブラリ）
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.1 用のアップストリームの 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.1
Mobile Safari/534.30
$(VERSION) 文字列の値は、
$(VERSION) 文字列の値は、
android.os.Build.VERSION.RELEASE の値と同じである必要があります
$(LOCALE) 文字列の値は、
国コードと言語の ISO 規則に従い、デバイスで現在構成されている言語 / 地域を参照する必要があります
$(MODEL) 文字列の値は、
android.os.Build.MODEL の値と同じである必要があります
$(BUILD) 文字列の値は、
android.os.Build.ID の値と同じである必要があります
デバイス実装では、ユーザー エージェント文字列の Mobile を省略できます
WebView コンポーネントには、可能な限り多くの HTML5 のサポートを含める必要があります
[リソース、11]。
少なくとも、デバイス実装は WebView の HTML5 に関連する以下の API をそれぞれサポートしなければなりません。
アプリケーション キャッシュ/オフライン オペレーション [リソース、12]
<video> タグ [リソース、13]
位置情報 [リソース、14]
さらに、デバイス実装は HTML5/W3C の webstorage API [リソース、15] をサポートしなければならず、HTML5/W3C の IndexedDB API [リソース、
16] をサポートすべきです。
なお、ウェブ開発標準化団体が webstorage よりも IndexedDB を優先するようになっているため、今後の Android バージョンでは、IndexedDB が必須コンポーネントになると見込まれます。
IndexedDB は、webstorage よりも IndexedDB を優先するようになっているため、今後の Android バージョンでは、IndexedDB が必須コンポーネントになると見込まれます。
すべての JavaScript API と同様に、WebView では HTML5 API をデフォルトで無効にしなければなりません。ただし、デベロッパーが通常の Android API を介して明示的に有効にする場合を除きます。
3.4.2.ブラウザの互換性
デバイス実装には、一般ユーザーのウェブ ブラウジング用のスタンドアロン ブラウザアプリを含まなければなりません。
スタンドアロン ブラウザは、
WebKit 以外のブラウザ テクノロジーに基づくものでも構いません。ただし、代替ブラウザアプリを使用する場合でも、サードパーティ アプリに提供する android.webkit.WebView コンポーネントは、セクション 3.4.1 に記載されているように、WebKit をベースとしなければなりません。
実装は、スタンドアロン ブラウザアプリでカスタムのユーザー エージェント文字列を送信しても構いません。
スタンドアロン ブラウザアプリは（アップストリームの WebKit ブラウザアプリとサードパーティの代替アプリのどちらに基づいているかにかかわらず）、可能な限り HTML5 [参考資料、11] をサポートするべきです。
デバイス実装は、少なくとも HTML5 に関連する次の API をそれぞれサポートしなければなりません。
アプリ キャッシュ/オフライン オペレーション [参考資料、12]
<video> タグ [参考資料、13]
位置情報 [参考資料、14]
さらに、デバイス実装は 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 実行ファイル（DEX）バイトコード仕様
と Dalvik 仮想マシンのセマンティクス [参考資料、17] をサポートしなければなりません。
デバイス実装は、アップストリームの Android プラットフォームに合わせて、以下の表に示すようにメモリが割り当てられるよう Dalvik を構成しなければなりません
（画面サイズと画面密度の定義については、
セクション 7.1.1 をご覧ください）。
なお、下記のメモリ値は最小値とみなされ、デバイス実装はアプリごとにより多くのメモリを割り当てても構いません。
画面サイズ
画面密度
アプリケーション メモリ
smal / normal / large
ldpi / mdpi
16MB
smal / normal / large
tvdpi / hdpi
32MB
smal / normal / large
xhdpi
64MB
xlarge
mdpi
32MB
xlarge
tvdpi / hdpi
64MB
xlarge
xhdpi
128MB
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.1 には、リッチ通知（進行中の通知のインタラクティブなビューなど）のサポートが含まれています。
デバイス実装は、Android API ドキュメントに記載されているように、リッチ通知を適切に表示し、実行しなければなりません。
3.8.3.検索
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.1 ソースコードには、ユーザーが最後にアプリを離れたときのアプリのグラフィック状態のサムネイル画像を使用して、最近使ったアプリを表示するユーザー インターフェースが含まれています。
デバイス実装は、このユーザー インターフェースを変更または削除しても問題ありません。ただし、Android の将来のバージョンでは、この機能をより幅広く使用できるようにする予定です。
デバイス実装では、最近使用したアプリについて、アップストリームの Android 4.1 ユーザー インターフェース（またはそれに類似したサムネイル ベースのインターフェース）を使用することが強く推奨されます。そのようにしないと、将来のバージョンの Android との互換性が失われる可能性があります。
3.8.8.入力管理の設定
Android 4.1 は、入力管理エンジンをサポートしています。Android 4.1 API を使用すると、カスタムアプリの IME で、ユーザーが調整できる設定を指定できます。
デバイス実装は、そのようなユーザー設定を実現する IME が表示される場合に、常に IME 設定にアクセスする方法が用意されている必要があります。
3.8.9.ロック画面のリモコン
Android 4.0 では、メディアアプリがデバイスのロック画面などのリモートビューに表示される再生コントロールと統合できる Remote Control API のサポートが導入されました [参考資料、69]。
デバイス実装は、
デバイスのロック画面にリモコンを埋め込むサポートを含める必要があります。
3.9 デバイス管理
Android 4.1 には、セキュリティ対応アプリが Android Device Administration API [参考資料、27] を介してシステムレベルでデバイス管理機能（パスワード ポリシーの適用やリモートワイプの実施など）を実行できる機能が用意されています。
デバイス実装は、
DevicePolicyManager クラス [参考資料、28] の実装を提供しなければなりません。また、
Android SDK ドキュメント [参考資料、27] で定義されているデバイス管理ポリシーの全範囲をサポートしなければなりません。
注: 上記の要件の一部は、Android 4.1 では「すべき」（原文では「SHOULD」）と記載されていますが、将来のバージョンの互換性定義では「しなければならない」（原文では「MUST」）に変更される予定です。
つまり、これらの要件は Android 4.1 では任意ですが、将来のバージョンでは必須になります
。Android 4.1 を搭載した既存または新規のデバイスは、Android 4.1 ではこれらの要件を満たすことが非常に強く推奨されます
。そうしないと、将来のバージョンにアップグレードしたときに Android の互換性を確保できません。
3.10 ユーザー補助
Android 4.1 には、障がいのあるユーザーがより簡単にデバイスを操作できるようにするためのユーザー補助レイヤが用意されています。
さらに、Android 4.1 は、ユーザー補助サービス実装がユーザー イベントとシステム イベントのコールバックを受信し、代替フィードバック メカニズム（テキスト読み上げ、触覚フィードバック、トラックボール /D-pad ナビゲーションなど）を生成できるプラットフォーム API を提供しています [参考資料、29]。
デバイス実装は、デフォルトの Android 実装と整合する Android ユーザー補助フレームワークの実装を提供しなければならない。
具体的には、デバイス実装は次の要件を満たさなければなりません。
デバイス実装は、android.accessibilityservice API [参考資料、
30] を介してサードパーティのユーザー補助サービス実装をサポートしなければなりません。
デバイス実装は、AccessibilityEvents を生成し、これらのイベントを、デフォルトの Android 実装と整合する方法で、登録済みのすべての AccessibilityService 実装に配信しなければなりません。
デバイス実装は、ユーザーによるアクセスが可能な、ユーザー補助サービスを有効または無効にするメカニズムを提供しなければならず、android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS インテントに応答してこのインターフェースを表示しなければなりません。
さらに、デバイス実装は、デバイスでユーザー補助サービスの実装を提供するべきであり、ユーザーがデバイスのセットアップ中にユーザー補助サービスを有効にするメカニズムを提供するべきです。
ユーザー補助サービスのオープンソース実装は、Eyes Free プロジェクト [参考資料、31] から入手できます。
3.11 テキスト読み上げ
Android 4.1 には、アプリがテキスト読み上げ（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 とオープン ハンドセット アライアンスはいずれも、これらのコーデックがサードパーティの特許の制約を受けないという表明は一切していないため、ご注意ください。
オープンソース ソフトウェアまたはシェアウェアを含め、このソースコードをハードウェアまたはソフトウェア製品で使用する場合は、このコードの実装に関連する特許権者からの特許ライセンスが必要になることがあります。
なお、現在のデバイス ハードウェアは、関連する標準で規定されている必須ビットレートに正確にマッピングされるビットレートを必ずしもサポートしていないため、次の表には、ほとんどの動画コーデックについてビットレートの具体的な要件は記載されていません。
代わりに、デバイス実装は、仕様で定義されている上限までの、ハードウェアで実現できる最も高いビットレートをサポートするべきです。
ファイル形式 /
形式 /
タイプ
エンコーダ
デコーダ
詳細
コンテナ
コーデック
形式
サポート
必須
モノラル/ステレオ/5.0/5.1*
MPEG-4
デバイス実装に必須
AAC プロファイル
マイク ハードウェアを含むコンテンツ
必須
標準サンプリング
（AAC LC）
定義
3GPP
8 ～ 48 のレート
android.hardware.microphone。
（.3gp）
kHz。
MPEG-4
サポート
（.mp4、
MPEG-4
モノラル/ステレオ/5.0/5.1*
.m4a）
HE AAC
コンテンツ
ADTS 未加工
必須
プロファイル
標準サンプリング
AAC（.aac、
（AAC+）
レート 16 ～ 48
kHz でデコード。
Android
3.1 以降、
MPEG-4
のサポート
デバイスの
モノラル/ステレオ/5.0/5.1*
HE AAC v2
実装で
Android
コンテンツ
プロファイル
マイク ハードウェア
4.0 以降、ADIF
標準サンプリング
（拡張
定義
16 ～ 48 のレート
AAC+）
android.hardware.microphone
サポート）
kHz。
MPEG-TS
MPEG-4
（.ts、
オーディオ
デバイスに必須
シーク可能な
オブジェクト タイプ
実装のサポート
モノラル/ステレオ コンテンツを含む
Android
ER AAC
マイク ハードウェア
必須
標準
3.0 以降）
ELD
定義
サンプリング レート
（拡張
android.hardware.microphone
16 ～ 48 kHz）。
低遅延
AAC)
必須
デバイス実装で必須
4.75 ～ 12.2 kbps
AMR-NB
マイク ハードウェアを含む
必須
3GPP（.3gp）
8 kHz でサンプリング
および定義
android.hardware.microphone。
必須
デバイス実装で必須
6.60
AMR-WB
マイク ハードウェアを含む
必須
kbit/s ～ 23.85 kbit/s
3GPP（.3gp）
定義
サンプリング レート 16 kHz
android.hardware.microphone。
モノラル/ステレオ（マルチチャンネルはサポート対象外）。
オーディオ
サンプルレートは最大 48 kHz（ただし、出力が 44.1 kHz のデバイスでは、48 kHz から 44.1 kHz のダウンサンプラーにローパス フィルタが含まれないため、最大 44.1 kHz を推奨）。
FLAC
kHz 出力で 44.1
必須
kHz 出力のデバイスでは、48
FLAC（.flac）のみ
（Android 3.1 以降）
44.1 kHz
ダウンサンプラーにローパス フィルタが含まれないため、最大 44.1 kHz を推奨）。
16 ビットを推奨（24 ビットにはディザが適用されない）。
モノラル/ステレオの 8 ～
320 Kbps 固定ビットレート
MP3
必須
MP3（.mp3）
（CBR）または可変ビットレート（VBR）
タイプ 0 および
MIDI タイプ 0 および 1。
1（.mid、
DLS バージョン 1、
.xmf、.mxmf）
2.XMF とモバイル
RTTTL/RTX
MIDI
必須
XMF。
（.rtttl、.rtx）
着信音形式
OTA（.ota）
RTTTL/RTX、OTA、
iMelody
および iMelody
（.imy）
Ogg（.ogg）
Vorbis
必須
Matroska
（.mkv）
8 ビットおよび 16 ビットの
リニア PCM**（レートは
ハードウェアの制限まで）デバイスは
PCM/WAVE をサポートする必要があります
必須
必須
WAVE（.wav）
8000、16000、44100 Hz の周波数で
未加工の PCM 録音
のサンプリング レート
JPEG
必須
必須
ベース + プログレッシブ
JPEG（.jpg）
GIF
必須
GIF（.gif）
画像
PNG
必須
必須
PNG（.png）
BMP
必須
BMP（.bmp）
WEBP
必須
必須
WebP（.webp）
必須
カメラ ハードウェアを含むデバイス実装に必須
3GPP
（.3gp）
H.263
必須
android.hardware.camera を定義
MPEG-4
または
（.mp4）
android.hardware.camera.front。
3GPP
（.3gp）
必須
MPEG-4
（.mp4）
カメラ ハードウェアとベースライン プロファイルを含むデバイス実装に必須
MPEG-TS
動画
H.264 AVC
必須
（.ts、AAC
android.hardware.camera を定義
（BP）
オーディオのみ、
または
android.hardware.camera.front がシーク可能ではない
（Android
3.0 以降））
MPEG-4
必須
3GPP （.3gp）
SP
WebM （.webm）
必須
および Matroska
VP8
（Android
（.mkv、Android
2.3.3 以降）
4.0 以降）
*注: 5.0/5.1 コンテンツのダウンミックスのみが必要です。2 つを超えるチャンネルの録画またはレンダリングは任意です。
**注: 16 ビットリニア PCM のキャプチャは必須です。8 ビットリニア PCM のキャプチャは必須ではありません。
5.2 動画エンコード
背面カメラを含み、
android.hardware.camera を宣言する Android デバイス実装は、以下の動画エンコード プロファイルをサポートするべきです。
HD （ハードウェアでサポートされている場合）
SD （低画質） SD （高画質）
）
H.264 ベースライン
H.264 ベースライン
動画コーデック
H.264 ベースライン プロファイル
プロファイル
プロファイル
動画
176 x 144 px
480 x 360 px
1280 x 720 px
解像度
動画フレーム 12 fps
30 fps
30 fps
レート
500 Kbps または
動画ビットレート 56 Kbps
2 Mbps 以上
以上
オーディオ コーデック AAC-LC
AAC-LC
AAC-LC
オーディオ
1 （モノラル）
2 （ステレオ）
2 （ステレオ）
チャンネル
オーディオ ビットレート 24 Kbps
128 Kbps
192 Kbps
5.3.音声録音
アプリが android.media.AudioRecord API を使用して音声ストリームの録音を開始したとき、マイク ハードウェアを含み、android.hardware.microphone を宣言するデバイス実装は、以下の各動作で音声をサンプリングして録音しなければなりません。
デバイスは、振幅周波数特性がほぼ平坦である必要があります。具体的には、±3 dB、100 Hz ～ 4, 000 Hz
音声入力感度は、1, 000 Hz で 90 dB の音響パワーレベル（SPL）のソースが 16 ビット サンプルで 2, 500 の RMS になるように設定する必要があります。
PCM 振幅レベルは、少なくとも 30 dB の範囲（-18 dB ～+12 dB、マイクで 90 dB SPL）で入力 SPL の変化をリニアに追跡する必要があります。
合計高調波歪みは、90 dB SPL の入力レベルで 1 kHz で 1% 未満である必要があります。
上記の録音仕様に加えて、アプリが
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION 音源を使用して
音声ストリームの録音を開始したときは、以下の要件が適用されます。
ノイズ リダクション処理（存在する場合）を無効にしなければなりません。
自動ゲイン コントロール（存在する場合）を無効にしなければなりません。
注: 上記の要件の一部は、Android 4.1 では「すべき」（原文では「SHOULD」）と記載されていますが、将来のバージョンの互換性定義では「しなければならない」（原文では「MUST」）に変更される予定です。
つまり、これらの要件は Android 4.1 では任意ですが、将来のバージョンでは必須になります
。Android 4.1 を搭載した既存または新規のデバイスは、Android 4.1 ではこれらの要件を満たすことが非常に強く推奨されます
。そうしないと、将来のバージョンにアップグレードしたときに Android の互換性を確保できません。
5.4. オーディオ レイテンシ
オーディオ レイテンシとは、アプリが音声の再生または録音オペレーションをリクエストしてから、デバイス実装が実際にオペレーションを開始するまでの間隔として広く定義されます。
アプリのクラスの多くで、サウンド エフェクトや VOIP 通信などのリアルタイム エフェクトを実現するには、レイテンシを短くする必要があります。
マイク ハードウェアを含み、android.hardware.microphone を宣言するデバイス実装は、このセクションで概説するオーディオ レイテンシ要件をすべて満たす必要があります。
デバイス実装でマイク ハードウェアを省略できる条件の詳細については、セクション 7 をご覧ください。
このセクションでは、次の用語を使用します。
「コールド出力レイテンシ」とは、アプリケーションがオーディオの再生をリクエストしてから、音声の再生を開始するまでの間隔として定義され、オーディオ システムがアイドル状態で電源がオフになるまでの時間のことを指します。
「ウォーム出力レイテンシ」とは、アプリケーションがオーディオの再生をリクエストしてから、音声の再生を開始するまでの間隔として定義され、オーディオ システムが最近使用されたものの、現在アイドル状態（つまり、無音状態）である時間のことを指します。
「連続出力レイテンシ」とは、デバイスが再生中のサンプルを発行してから、スピーカーが現在音声を再生しているときに、スピーカーが対応する音を物理的に再生する間隔を指します。
「コールド入力レイテンシ」とは、アプリケーションが音声録音をリクエストしてから、コールバックを通じて最初のサンプルがアプリに配信されるまでの間隔（オーディオ システムとマイクがアイドル状態で、リクエストの前に電源がオフになるまでの時間）として定義されます。
「連続入力レイテンシ」とは、周囲の音が発生してから、その音に対応するサンプルがコールバックを通じて録音アプリに配信されるまでの間隔（デバイスが録音モードになっている間）として定義されます。
上記の定義に基づき、デバイスの実装では、次の各プロパティを満たす必要があります。
コールド出力レイテンシが 100 ミリ秒以下
ウォーム出力レイテンシが 10 ミリ秒以下
連続出力レイテンシが 45 ミリ秒以下
コールド入力レイテンシが 100 ミリ秒以下
連続入力レイテンシが 50 ミリ秒以下
注: 上記の要件は Android 4.1 では「SHOULD」と記載されていますが、
今後のバージョンの互換性定義では、これらを「MUST」に変更する予定です。
つまり、これらの要件は Android 4.1 では省略可能ですが、今後のバージョンでは必須となります。
Android 4.1 を搭載した既存または新規のデバイスでは、Android 4.1 ではこれらの要件を満たすことが非常に強く推奨されます
。そのようにしないと、将来のバージョンにアップグレードした場合に 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 のすべての機能をサポートしなければなりません。
ddms は adb を使用するため、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 として実装する必要があります
SDK ドキュメントで許可されている場合、API メソッドは null 値を返さなければなりません
SDK ドキュメントで許可されていない場合、API メソッドはクラスの NoOps 実装を返さなければなりません
SDK ドキュメントでドキュメント化されていない例外を API メソッドがスローしてはなりません
これらの要件が適用されるシナリオの典型的な例は、テレフォニー API です。
スマートフォン以外のデバイスでも、これらの API は合理的な NoOps として実装する必要があります。
デバイス実装は、android.content.pm.PackageManager クラスの getSystemAvailableFeatures() メソッドと hasSystemFeature(String) メソッドを介して、正確なハードウェア構成情報を正確にレポートしなければなりません。
[参考資料、37]
7.1.ディスプレイとグラフィック
Android 4.1 には、さまざまなハードウェア構成でサードパーティ アプリが適切に動作するように、デバイスに合わせてアプリアセットと UI レイアウトを自動的に調整する機能があります [参考資料、38]。
デバイスは、このセクションで詳述するように、
これらの API と動作を適切に実装しなければなりません。
このセクションの要件で参照される単位は、次のように定義されています。
「物理的な対角サイズ」とは、ディスプレイの明るくなっている部分の 2 つの相対する隅の間の距離（インチ単位）です。
「dpi」（1 インチあたりのドット数）とは、長さが 1 インチの水平または垂直の直線で囲まれるピクセルの数です。
dpi 値が記載されている場合は、水平方向と垂直方向の両方の dpi が範囲内に収まらなければなりません。
「アスペクト比」は、画面の長辺と短辺の比率です。
たとえば、480x854 ピクセルのディスプレイは 854 / 480 =
1.779、すなわち約「16:9」となります。
「密度非依存ピクセル」（dp）は、160 dpi の画面に正規化された仮想ピクセル単位です。ピクセル数 = dps * (密度 / 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」であるとレポートするデバイスは、画面サイズが少なくとも 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 ドキュメントに記載されているように、小、標準、大、特大の画面についてアプリが表明しているサポートを正しく尊重しなければなりません。
画面のアスペクト比
アスペクト比は、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」）
480 dpi（「xxhdpi」）
デバイスの実装では、標準の 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 の両方をサポートしなければなりません。
デバイス実装は、Android SDK ドキュメント
[参考資料、8] に詳述されているとおり、Android RenderScript もサポートしなければなりません。
また、デバイス実装は、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.1 では、アプリで特定の OpenGL テクスチャ圧縮形式を必須に指定できます。
これらの形式は通常ベンダー固有です。
Android 4.1 では、デバイス実装が特定のテクスチャ圧縮形式を実装することは必須ではありません。
ただし、
OpenGL API の getString() メソッドを介して、サポートするテクスチャ圧縮形式を正確にレポートするべきです。
Android 4.1 には、マニフェスト タグ android:hardwareAccelerated または直接
API 呼び出しを使用することで、アプリ、アクティビティ、ウィンドウ、
ビューのレベルで 2D グラフィックのハードウェア アクセラレーションを有効にすることを、アプリで宣言するメカニズムがあります [参考資料、9]。
Android 4.1 のデバイス実装は、ハードウェア アクセラレーションをデフォルトで有効にしなければならず、デベロッパーが
android:hardwareAccelerated="false" を設定するか、
Android View API を通じてハードウェア アクセラレーションを直接無効にすることでリクエストした場合は、ハードウェア アクセラレーションを無効にしなければなりません。
また、デバイス実装は、ハードウェア アクセラレーションに関する Android SDK ドキュメント [参考資料、9] に合致する動作を示さなければなりません。
Android 4.1 には、ハードウェア アクセラレーションの OpenGL ES テクスチャを UI 階層のレンダリング ターゲットとしてデベロッパーが直接統合できる TextureView オブジェクトが含まれています。
デバイス実装は TextureView API をサポートし、
アップストリームの Android 実装と一貫した動作を示さなければなりません。
7.1.5.レガシー アプリケーションの互換モード
Android 4.1 は、以前の画面サイズに依存しない Andrdoid の旧バージョン用に開発されていないレガシーアプリを活用するために、フレームワークが「標準」画面サイズ相当（幅 320 dp）のモードで動作する「互換モード」を規定しています。
デバイス実装は、アップストリームの Android オープンソース コードで実装されたレガシーアプリ互換モードのサポートを含まなければなりません。
つまり、デバイス実装は、互換モードが有効になるトリガーまたはしきい値を変更してはなりません。また、互換モード自体の動作を変更してはなりません。
7.1.6.画面の種類
デバイス実装の画面は、次の 2 つのタイプのいずれかに分類されます。
固定ピクセル ディスプレイ実装: 画面は、単一のピクセルの幅と高さのみをサポートする単一パネルです。
通常、画面はデバイスと物理的に統合されています。
たとえば、スマートフォンやタブレットなどです。
可変ピクセル ディスプレイの実装: このデバイス実装は、埋め込み画面がなくディスプレイ用の VGA、HDMI、ワイヤレス ポートなどの動画出力ポートを備えているか、ピクセル寸法を変更できる埋め込み画面を備えています。
例としては、テレビ、セットトップ ボックスなどがあります。
固定ピクセル デバイス実装
固定ピクセル デバイス実装は、この互換性定義で規定されている要件を満たしていれば、任意のピクセル寸法の画面を使用しても構いません。
固定ピクセルの実装は、外部ディスプレイで使用する動画出力ポートを含めても問題ありません。
ただし、そのディスプレイをアプリの実行に使用する場合、デバイスは次の要件を満たさなければなりません。
デバイスは、セクション 7.1.1 および 7.1.2 で詳述するように、固定ピクセル ディスプレイと同じ画面構成とディスプレイ指標をレポートしなければなりません。
デバイスは、固定ピクセル ディスプレイと同じ論理密度をレポートしなければなりません。
デバイスは、固定ピクセル ディスプレイと同じ画面サイズか、非常に近い画面サイズをレポートしなければなりません。
たとえば、対角サイズが 7 インチで、解像度が 1, 024 x 600 ピクセルのタブレットは、固定ピクセルの large mdpi ディスプレイの実装とみなされます。
720p または 1080p で表示される動画出力ポートが含まれる場合、デバイス実装は、固定ピクセル ディスプレイまたは動画出力ポートが使用中であるかどうかにかかわらず、アプリケーションが large mdpi ウィンドウでのみ実行されるように、出力の調整をしなければなりません。
可変ピクセル デバイス実装
可変ピクセル デバイス実装は、1280x720 と 1920x1080（つまり 720p と 1080p）の両方またはいずれかをサポートしなければなりません。
可変ピクセル ディスプレイを備えたデバイス実装は、他のいかなる画面構成またはモードもサポートしてはなりません。
可変ピクセル画面を備えたデバイス実装は、実行時または起動時に画面構成またはモードを変更しても構いません。
たとえば、セットトップ ボックスのユーザーが 720p のディスプレイを 1080p のディスプレイに交換し、それに応じてデバイス実装で調整を行うことが可能です。
さらに、可変ピクセル デバイス実装は、これらのピクセル寸法について以下の構成バケットを報告しなければなりません。
1280x720（720p）: 「large」画面サイズ、tvdpi（213 dpi）密度
1920x1080（1080p）: 「large」画面サイズ、xhdpi（320 dpi）密度
つまり、Android 4.1 では、可変ピクセル寸法のデバイス実装は 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.1 は、両方の実装をサポートしています。
Android 4.1 では、アシスト アクションのサポートが導入されました [参考資料、63]。デバイス実装は、アプリ実行時に常にアシスト アクションをユーザーが利用できるようにしなければなりません。
この機能は、ハードウェア キーまたはソフトウェア キーを使用して実装しても構いません。
デバイス実装は、ナビゲーション キーを表示するために画面の区分けされた部分を使用しても構いませんが、その場合は以下の要件を満たさなければなりません。
デバイス実装のナビゲーション キーは、アプリが利用できない画面内の区分けされた部分を使用しなければならず、アプリが利用できる画面内の部分を隠したり、その他の方法で利用を妨げたりしてはなりません。
デバイス実装は、セクション 7.1.1 で定義されている要件を満たすアプリがディスプレイの一部を利用できるようにしなければなりません。
デバイス実装は、アプリがシステム UI モードを指定していない場合、または SYSTEM_UI_FLAG_VISIBLE を指定した場合に、ナビゲーション キーを表示しなければなりません。
デバイス実装は、アプリが SYSTEM_UI_FLAG_LOW_PROFILE を指定した場合に、ナビゲーション キーを目立たない「低プロファイル」（たとえば、暗くする）モードで表示しなければなりません。
デバイス実装は、アプリが SYSTEM_UI_FLAG_HIDE_NAVIGATION を指定している場合、ナビゲーション キーを非表示にしなければなりません。
デバイス実装は、targetSdkVersion が 10 以下の場合はアプリにメニューキーを表示しなければならず、targetSdkVersion が 10 を超える場合はメニューキーを表示するべきではありません。
デバイス実装は、セクション 7.1.1 で定義されている要件を満たすアプリに対して、ディスプレイの一部を公開しなければなりません。
7.2.4.タッチスクリーン入力
デバイス実装は、なんらかの種類のポインタ入力システム（マウスのような入力またはタップ入力）を含むべきです。
ただし、デバイス実装がポインタ入力システムをサポートしていない場合は、android.hardware.touchscreen または android.hardware.faketouch 機能定数を報告してはなりません。
ポインタ入力システムを含むデバイス実装:
デバイス入力システムが複数のポインタをサポートする場合は、完全に独立してトラッキングされるポインタをサポートするべきです
デバイス上の特定のタッチスクリーンのタイプに対応する android.content.res.Configuration.touchscreen
[参考資料、40] の値を報告しなければなりません
Android 4.0 は、さまざまなタッチスクリーン、タッチパッド、疑似タップ入力デバイスをサポートしています。
タッチスクリーン ベースのデバイス実装は、画面上のアイテムを直接操作しているような印象をユーザーに与えるディスプレイ [参考資料、71] に関連付けられます。
ユーザーが画面に直接触れているため、操作中のオブジェクトを示すアフォーダンスを追加する必要はありません。
これに対して、疑似タップ インターフェースは、タッチスクリーン機能のサブセットに似たユーザー入力システムを提供します。
たとえば、画面上のカーソルを操作するマウスまたはリモコンはタップに近いですが、ユーザーは最初にポイントまたはフォーカスしてからクリックする必要があります。
マウス、トラックパッド、ジャイロベースのエアマウス、
ジャイロポインタ、ジョイスティック、マルチタッチ トラックパッドなど、多くの入力デバイスが擬似タップ インターフェースをサポートできます。
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 画面位置をレポートし、
画面にビジュアル ポインタを表示しなければなりません [参考資料、70]
ポインタが画面上で下または上 に移動するときに発生する状態変化を指定するアクション コードで、タッチイベントをレポートしなければなりません [参考資料、70]
画面上のオブジェクトに対するポインタのダウンとアップをサポートしなければなりません。これにより、ユーザーは画面上のオブジェクトに対するタップ操作をエミュレートできます
時間しきい値内に、画面上のオブジェクトの同じ場所でポインタのダウン、ポインタのアップ、ポインタのダウン、ポインタのアップをサポートしなければなりません。これにより、ユーザーは画面上のオブジェクトに対するダブルタップ操作をエミュレートできます [参考資料、70]
画面上の任意の点でポインタのダウン、ポインタの移動、任意の他の点でのポインタのダウン、ポインタのアップをサポートしなければなりません。これにより、ユーザーはタップ ドラッグ操作をエミュレートできます
ポインタのダウンをサポートし、ユーザーがオブジェクトを画面上の別の位置に素早く移動してからポインタのアップを実行できるようにしなければなりません。これにより、ユーザーは画面上のオブジェクトをスワイプできます
android.hardware.faketouch.multitouch.distinct のサポートを宣言するデバイス
は、上記のフェイクタッチの要件を満たすとともに、2 つ以上の独立したポインタ入力の明確なトラッキングもサポートしなければなりません。
7.2.6.マイク
デバイス実装はマイクを省略しても構いません。ただし、デバイス実装でマイクを省略する場合、デバイス実装は、android.hardware.microphone 機能定数をレポートしてはならず、セクション 7 に記載されているように、音声録音 API を NoOps として実装しなければなりません。
逆に、マイクを備えたデバイス実装は、
android.hardware.microphone 機能定数をレポートし、
セクション 5.4 の音声品質要件を満たし、
セクション 5.5 の音声レイテンシ要件を満たさなければなりません。
センサー
Android 4.1 には、さまざまなセンサータイプにアクセスするための API が含まれています。デバイス実装は、以降のサブセクションに示すとおり、通常、これらのセンサーを省略しても問題ありません。
サードパーティ デベロッパー向けの対応する API を持つ特定のセンサータイプがデバイスに含まれる場合、デバイス実装は、Android SDK ドキュメントに記載されているとおり、その API を実装しなければなりません。
たとえば、デバイス実装は、
android.content.pm.PackageManager クラスに基づいて、センサーの有無を正確にレポートしなければなりません。
[リソース、37]
SensorManager.getSensorList() や同様のメソッドを介してサポート対象のセンサーの正確なリストを返さなければなりません
他のすべてのセンサー API について合理的に動作しなければなりません（たとえば、アプリがリスナーの登録を試みたときは適切に true または false を返す、対応するセンサーが存在しないときはセンサー リスナーを呼び出さないなど）。
Android SDK ドキュメント [リソース、41]で定義されているとおり、センサータイプごとに関連する国際単位系（メートル法）の値を使用して、すべてのセンサー測定値をレポートしなければなりません
上記のリストは包括的なものではありません。Android SDK のドキュメントに記載されている動作が正式なものとみなされます。
一部のセンサータイプは統合型です。つまり、1 つ以上の他のセンサーが提供するデータから導出できます
。（そうしたセンサーには、方向センサーや直線加速度センサーがあります）。
デバイス実装では、必須の物理センサーが含まれる場合に、これらのセンサータイプを実装するべきです。
Android 4.1 API では、「ストリーミング」センサーの概念が導入されています。これは、データが変更されたときだけでなく、継続的にデータを返すセンサーです。
デバイス実装は、Android 4.1 SDK ドキュメントでストリーミング センサーであると示されている API について、定期的なデータサンプルを継続的に提供しなければなりません。
7.3.1.加速度計
デバイス実装は、3 軸加速度計を含む必要があります。3 軸加速度計が含まれる場合、デバイス実装は:
120 Hz 以上でイベントを配信できるべきです。
なお、
Android 4.1 では、上記の加速度計の周波数が「するべき」と記載されていますが、
今後のバージョンの互換性定義では「しなければならない」に変更される予定です。
つまり、これらの標準は Android 4.1 では任意ですが、今後のバージョンでは必須になります
。Android 4.1 を搭載した既存および新規のデバイスは、将来のプラットフォーム リリースにアップグレードできるように、Android 4.1 でこれらの要件を満たすことが非常に強く推奨されます 。
Android API（[参考資料、41] を参照）で詳しく説明されているように、Android センサー座標システムに準拠している必要があります
任意の 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.1 では、上記のジャイロスコープの周波数が「するべき」と記載されていますが、
今後のバージョンの互換性定義では「しなければならない」に変更される予定です。
つまり、これらの標準は Android 4.1 では任意ですが、今後のバージョンでは必須になります
。Android 4.1 を搭載した既存または新規のデバイスは、将来のプラットフォーム リリースにアップグレードできるように、Android 4.1 のこれらの要件を満たすことが非常に強く推奨されます 。
12 ビットの精度以上である必要があります
1 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.1 API で非推奨になりました）。
7.3.7.光度計
デバイス実装は、光度計（周囲光センサー）を含んでも構いません。
7.3.8.近接センサー
デバイス実装は、近接センサーを含んでも構いません。近接センサーを含む場合、デバイス実装は画面と同じ方向にある物体の近さを測定しなければなりません。
つまり近接センサーは、画面の近くにある物体を検出するような向きでなければなりません。これは、スマートフォンをユーザーが使用中であることの検出が、この種のセンサーの主な目的であるためです。
他の向きの近接センサーを含む場合、デバイス実装は、この API を通じてアクセス可能であってはなりません。
デバイス実装が近接センサーを含む場合、その正確度は 1 ビット以上でなければなりません。
7.4.データ接続
7.4.1.電話
Android 4.1 API とこのドキュメントで使用する「電話」は、特に、GSM または CDMA ネットワークを介して行う音声通話と SMS メッセージの送信に関連するハードウェアのことを指します。
こうした音声通話は、パケット交換であってもそうでなくても構いませんが、Android 4.1 では、同じネットワークを使用して実装されるデータ接続からは独立しているとみなされます。
つまり、Android の「電話」機能と API は、特に音声通話と SMS のことを指します。たとえば、通話の発信または SMS メッセージの送受信ができないデバイス実装は、データ接続にモバイル ネットワークを使用するかどうかにかかわらず、android.hardware.telephony 機能またはサブ機能をレポートしてはなりません。
Android 4.1 は、電話ハードウェアを含まないデバイスで使用しても構いません。つまり、
Android 4.1 はスマートフォン以外のデバイスに対応しています。ただし、デバイス実装に GSM または CDMA の電話が含まれる場合、その技術の API の完全なサポートを実装しなければなりません。
電話ハードウェアを含まないデバイス実装は、完全な API を NoOps として実装しなければなりません。
7.4.2. IEEE 802.11 （WiFi）
Android 4.1 デバイス実装は、1 つ以上の形式の 802.11（b/g/a/n など）のサポートを含むべきです
802.11 のサポートが含まれる場合、デバイス実装は、対応する Android API を実装しなければなりません。
デバイス実装は、SDK
ドキュメント [参考資料、62] に記載されているとおり、マルチキャスト API を実装しなければなりません。Wi-Fi サポートを含むデバイス実装は、
マルチキャスト DNS（mDNS）をサポートしなければなりません。デバイス実装は、画面がアクティブ状態にないときに、mDNS パケット（224.0.0.251）をフィルタしてはなりません。
7.4.2.1. WiFi 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.3Bluetooth
デバイス実装は 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.1 では「するべき」と記載されていますが、今後のバージョンの互換性定義では「しなければならない」に変更される予定です。
つまり、これらの標準は
Android 4.1 では任意ですが、今後のバージョンでは必須になります。Android 4.1 を搭載した既存または新規のデバイスは、今後のプラットフォーム リリースにアップグレードできるよう、Android 4.1 のこれらの要件を満たすことが非常に強く推奨されます。
NfcV（ISO 15693）
次のピアツーピア標準とプロトコルを使用してデータを送受信できなければなりません。
ISO 18092
LLCP 1.0（NFC フォーラムで定義）
SDP 1.0（NFC フォーラムで定義）
NDEF プッシュ プロトコル [リソース、43]
SNEP 1.0（NFC フォーラムで定義）
Android Beam のサポートを含める必要があります [リソース、65]
SNEP デフォルト サーバーを実装する必要があります。
デフォルトの SNEP サーバーで受信した有効な NDEF メッセージは、android.nfc.ACTION_NDEF_DISCOVERED インテントを使用してアプリにディスパッチしなければなりません。
設定で Android Beam を無効にすることにより、受信 NDEF メッセージのディスパッチを無効にしてはなりません。デバイス実装は、android.settings.NFCSHARING_SETTINGS インテントを尊重して、NFC 共有設定を表示しなければなりません。
[参考資料、67]。
NPP サーバーを実装しなければなりません。
NPP サーバーが受信するメッセージは、SNEP デフォルト サーバーと同じ方法で処理しなければなりません。SNEP クライアントを実装し、Android ビームが有効になっているときはデフォルト SNEP サーバーへのアウトバウンド P2P NDEF の送信を試みなければなりません。
デフォルトの
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 を使用する場合、
NFC フォーラムの「Connection Handover バージョン 1.2」[リソース、60] と「Bluetooth Secure Simple Pairing Using NFC バージョン 1.0」 [リソース、61] の仕様を実装して、Bluetooth への接続ハンドオーバーをサポートしなければなりません。
このような実装では、NFC を介してハンドオーバー リクエスト / 選択レコードを交換するために SNEP GET リクエストを使用すべきであり、実際の Bluetooth データ転送で Bluetooth オブジェクト プッシュ プロファイルを使用しなければなりません。
NFC 検出モードのときは、サポートされているすべての技術をポーリングしなければなりません。
画面がアクティブでロック画面がロック解除された状態でデバイスが起動しているときは、NFC 検出モードになっているべきです。
（なお、上記の JIS、ISO、NFC フォーラムの仕様について、一般公開されているリンクはありません）。
さらに、デバイス実装は、次の MIFARE 技術のリーダー/ライターをサポートしても構いません。
MIFARE Classic （NXP MF1S503x [参考資料、44]、MF1S703x [参考資料、44]）
MIFARE Ultralight （NXP MF0ICU1 [参考資料、46]、MF0ICU2 [参考資料、46]）
MIFARE Classic の NDEF（NXP AN130511 [Resources, 48]、AN130411
[参考資料、49]）
注: Android 4.1 には、これらの MIFARE タイプの API が含まれています。デバイス実装がリーダー/ライターのロールで MIFARE をサポートする場合は、以下の要件が適用されます。
Android SDK に記載されているように、対応する Android API を実装しなければなりません。
android.content.pm.PackageManager.hasSystemFeature() メソッドから com.nxp.mifare 機能を報告しなければなりません。
[参考資料、37] これは Android の標準機能ではないため、
PackageManager クラスの定数としては表示されません。
対応する Android API を実装したり、
com.nxp.mifare 機能を報告したりしてはなりません。ただし、
このセクションで説明するように一般的な NFC サポートも実装する場合は例外です。
デバイス実装に NFC ハードウェアが含まれていない場合、
android.content.pm.PackageManager.hasSystemFeature() メソッド [参考資料、37] から android.hardware.nfc 機能を宣言してはなりません。
また、Android 4.1 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、イーサネットなどがあります。
物理ネットワーク標準（イーサネットなど）がプライマリ データ接続であるデバイス実装は、802.11（Wi-Fi）などの一般的なワイヤレス データ標準も少なくとも 1 つサポートするべきです。
デバイスは、複数の形式のデータ接続を実装しても構いません。
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 4.1 の Camera API のサポート対象は前面カメラに特定されており、デバイス実装では、前面カメラをデフォルトの背面カメラとして扱うように API を構成してはなりません（アプリが特定の背面カメラである場合も同様）。カメラはデバイス上の唯一のカメラです。
第 7 章 5.1 で説明されているように、背面カメラで利用可能な機能（オートフォーカス、フラッシュなど）を含めることができます。
次のように、アプリが CameraPreview に表示するストリームを水平方向に反射（ミラーリング）する必要があります。
デバイス実装がユーザーによる回転に対応している場合（加速度計による自動回転やユーザー入力による手動回転など）、カメラ
プレビューはデバイスの現在の
向きに応じて水平方向にミラーリングする必要があります。
現在のアプリが、
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.1 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 マスストレージを使用しても構いませんが、メディア転送プロトコルを使用するべきです。
デバイス実装がメディア転送プロトコルをサポートする場合:
デバイス実装は、リファレンス Android
MTP ホストである Android File Transfer [参考資料、57] と互換性を持つべきです。
デバイス実装は、USB デバイスクラス 0x00 を報告するべきです。
デバイス実装は、USB インターフェース名「MTP」を報告するべきです。
USB ポートを含まないデバイス実装は、ホスト コンピュータがネットワーク ファイル システムなどの他の手段で共有ストレージの内容にアクセスできるようにしなければなりません。
説明のために 2 つの一般的な例を示します。デバイス実装に共有ストレージ要件を満たす SD カード スロットが含まれる場合、FAT でフォーマットされた 1 GB 以上の SD カードがユーザーに販売されるデバイスに付属し、デフォルトでマウントされなければなりません。
または、デバイス実装がこの要件を満たすために内部固定ストレージを使用する場合、そのストレージは 1 GB 以上で、/sdcard にマウントされなければなりません（
別の場所にマウントされる場合、/sdcard は物理的な場所へのシンボリック リンクでなければなりません）。
複数の共有ストレージパス（SD カードスロットと共有内部ストレージの両方など）を含むデバイス実装については、メディア スキャナや ContentProvider などのコアアプリを変更して、両方の場所に配置されたファイルを透過的にサポートするべきです。
7.7. USB
デバイス実装は USB クライアント ポートを含むべきです。また、USB ホストポートを含むべきです。
デバイス実装に USB クライアント ポートが含まれる場合:
ポートは標準の USB-A ポートで USB ホストに接続できなければなりません
ポートはデバイス側のマイクロ USB フォーム ファクタを使用するべきです。Android 4.1 を搭載した既存または新規のデバイスは、今後の
プラットフォーム リリースにアップグレードできるように、Android 4.1 のこれらの要件を満たすことが非常に強く推奨されます
ポートはエッジの中央に配置する必要があります。
デバイス実装は、（自然な向きに応じた）デバイスの底面にポートを配置するか、すべてのアプリ（ホーム画面を含む）でソフトウェア画面回転を可能にして、ポートが底面に来るようにデバイスの向きが設定された場合にディスプレイが正しく描画されるようにすべきです。
Android 4.1 を搭載した既存または新規のデバイスは、将来のプラットフォーム リリースにアップグレードできるように、Android 4.1 のこれらの要件を満たすことが非常に強く推奨されます。
デバイスに他のポート（USB 以外の充電ポートなど）がある場合は、
micro-USB ポートと同じエッジに配置する必要があります
デバイスに接続されたホストが、USB 大容量ストレージまたはメディア転送プロトコルを使用して共有ストレージ ボリュームのコンテンツにアクセスできるようにする必要があります
Android Open Accessory API と仕様を、Android SDK のドキュメントに記載されているように実装する必要があります
ハードウェア機能 android.hardware.usb.accessory のサポートを宣言する必要があります [リソース、52]
Android SDK のドキュメントに記載されているように USB 音声クラスを実装する必要があります [リソース、66]
USB バッテリー充電仕様のサポートを実装する必要があります [リソース、64] Android 4.1 を搭載した既存または新規のデバイスは、将来のプラットフォーム リリースにアップグレードできるように、Android 4.1 のこれらの要件を満たすことが非常に強く推奨されます
デバイスの実装に USB ホストポートが含まれている場合:
標準以外のポート フォーム ファクタを使用できますが、その場合は、ポートを標準 USB-A に適合させるケーブルまたはケーブルを付属する必要があります
Android SDK に記載されているように Android USB ホスト API を実装する必要があります
ハードウェア機能 android.hardware.usb.host のサポートを宣言する必要があります [リソース、53]
デバイスの実装に Android Debug Bridge を実装する必要があります。
デバイス実装で USB クライアント ポートが省略されている場合は、ローカルエリア ネットワーク（イーサネット、802.11 など）を介して Android Debug Bridge を実装しなければなりません。
8
パフォーマンスの互換性
デバイス実装は、下記の表で定義されている Android 4.1
対応デバイスの主要なパフォーマンス指標を満たさなければなりません。
指標
パフォーマンスのしきい値
コメント
次のアプリは、指定された時間内に起動する必要があります。
起動時間は、
ブラウザの読み込みを完了するのにかかる合計時間として測定されます。
アプリのデフォルト アクティビティ、
アプリ
1,300 ms
起動時間
連絡先:
Linux プロセスを開始し、Android パッケージを Dalvik VM に読み込んで、onCreate を呼び出すのに要する時間を含む
設定:
700 ミリ秒
複数のアプリケーション
立ち上げられ、再
すでに
同時
その後アプリケーションを実行する
アプリケーション
開始されている必要があります
元より少なく取る
打ち上げ時間。
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.1 のリファレンス実装と優先実装に対して行う変更を可能な限り最小限に抑えることを強くおすすめします。
これにより、互換性の問題をもたらすバグが導入され、再作業やデバイスのアップデートが必要となるリスクを最小限に抑えることができます。
10.1.互換性テストスイート
デバイス実装は、デバイス上の最終出荷ソフトウェアを使用して、Android オープンソース プロジェクトから入手できる Android 互換性テストスイート（CTS）
[参考資料、2] に合格しなければなりません。
さらに、デバイス実装者は可能な限り Android オープンソース ツリーのリファレンス実装を使用するべきであり、CTS で不明確な点があった場合やリファレンス ソースコードの一部を再実装する場合に互換性を確保しなければなりません。
CTS は、実際のデバイスで動作するように設計されています。他のソフトウェアと同様に、CTS 自体にもバグが含まれている可能性があります。
CTS はこの互換性定義とは別にバージョニングされ、Android 4.1 用に CTS の複数のリビジョンがリリースされる可能性があります。
デバイス実装は、デバイス ソフトウェアが完成した時点で利用可能な最新バージョンの CTS に合格しなければなりません。
10.2.CTS 検証ツール
デバイス実装は、CTS 検証ツールで該当するすべてのケースを正しく実行しなければなりません。
CTS 検証ツールは互換性テストスイートに含まれており、カメラやセンサーの正常な機能など、自動システムではテストできない機能をテストするために、人間のオペレーターが実行するためのものです。
CTS 検証ツールには、オプションのハードウェアを含め、さまざまな種類のハードウェア用のテストがあります。
デバイス実装は、搭載しているハードウェア用のすべてのテストに合格しなければなりません。たとえば、デバイスに加速度計が搭載されている場合は、CTS 検証ツールで加速度計のテストケースを正しく実行しなければなりません。
この互換性定義ドキュメントで任意とされている機能のテストケースは、スキップまたは省略しても構いません。
上記のとおり、すべてのデバイスとすべてのビルドで、CTS 検証ツールが正しく実行されなければなりません。
ただし、ビルドの多くはよく似ているため、デバイス実装者は、わずかな違いしかないビルドで CTS 検証ツールを明示的に実行することは求められていません。
具体的には、
CTS 検証ツールに合格した実装との違いが、含まれるロケール、ブランディングなどのセットのみであるデバイス実装は、CTS 検証ツール
テストを省略しても構いません。
10.3.リファレンス アプリ
デバイス実装者は、次のオープンソース アプリを使用して実装の互換性をテストしなければなりません。
「Android 用アプリ」アプリ [リソース、55]
レプリカ アイランド（Android Market で入手可能）
上記の各アプリは、実装が互換性を持つとみなされるように、実装で正しく起動して動作しなければなりません。
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 を無効にした状態で、候補のデバイスで BluetoothChat を起動します
2.候補デバイスが Bluetooth をオンにするか、Bluetooth をオンにするよう促すダイアログを表示することを確認します
ペア設定と通信をテストする
1.両方のデバイスで Bluetooth チャットアプリを起動します
2.メニューを使用して BluetoothChat 内で既知の正常なデバイスを検出可能にします。
3.候補デバイスで、メニューを使用して BluetoothChat 内から Bluetooth デバイスをスキャンし、既知の正常なデバイスとペア設定します
4.
各デバイスから 10 件以上のメッセージを送信し、別のデバイスで正しく受信されていることを確認します
5.両方のデバイスの Bluetooth チャットアプリをホーム
6 を押して閉じます。デバイスの設定アプリを使用して、各デバイスとのペア設定を解除します
逆方向のペア設定と通信をテストする
1.両方のデバイスで Bluetooth チャット アプリを起動します。
2.
メニューを使用して、BluetoothChat から候補デバイスを検出可能にします。
3.既知の正常なデバイスで、メニューを使用して BluetoothChat
内から Bluetooth デバイスをスキャンし、候補デバイスとペア設定します。
4.各デバイスから 10 件以上のメッセージを送信し、別のデバイスで正しく受信されていることを確認します。
5.[戻る] を繰り返し押してランチャーに移動し、両方のデバイスの Bluetooth チャットアプリを閉じます。
テストの再リリース
1.両方のデバイスで Bluetooth チャットアプリを再起動します。
2.各デバイスから 10 件以上のメッセージを送信し、別のデバイスで正しく受信されていることを確認します。
注: 上記のテストでは、ホームを使用してテスト セクションを終了するケースと、
戻るセクションを使用するケースがあります。これらのテストは冗長ではなく、また任意ではありません。その目的は、アクティビティを明示的に終了した場合に（ユーザーが「戻る」を押して、finish() を呼び出すことで）Bluetooth API とスタックが正しく機能することを確認し、暗黙的にバックグラウンドに送信される（ユーザーがホームを押すことによって）ようにすることです。
各テスト シーケンスは、説明のとおりに実行しなければなりません。
