Android 2.1 互換性定義

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

1.はじめに

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

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

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

Android 2.1 と互換性があると見なされるには、デバイス実装:

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

この定義または CTS が沈黙、あいまい、または不完全である場合、既存の実装との互換性を確保するのはデバイスの実装者の責任です。このため、Android オープン ソース プロジェクト [ Resources, 3 ] は、Android のリファレンスであり、推奨される実装でもあります。デバイスの実装者は、Android オープン ソース プロジェクトから入手できる「アップストリーム」ソース コードに基づいて実装することを強くお勧めします。一部のコンポーネントは仮想的に別の実装に置き換えることができますが、CTS テストに合格することが大幅に難しくなるため、この方法はお勧めできません。互換性テスト スイートを含め、標準の 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 2.1 で許可されているバージョン文字列: http://source.android.com/compatibility/2.1/versions.html
8. android.webkit.WebView クラス: http://developer.android.com/reference/android/webkit/WebView.html
9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
10. Dalvik 仮想マシンの仕様: dalvik/docs の Android ソース コードで入手可能
11. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
12. 通知: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
13. アプリケーション リソース: http://code.google.com/android/reference/available-resources.html
14. ステータス バー アイコンのスタイル ガイド: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
15. 検索マネージャー: http://developer.android.com/reference/android/app/SearchManager.html
16. トースト: http://developer.android.com/reference/android/widget/Toast.html
17. ライブ壁紙: http://developer.android.com/resources/articles/live-wallpapers.html
18. Android 用アプリ: http://code.google.com/p/apps-for-android
19. 参照ツール ドキュメント (adb、aapt、ddms 用): http://developer.android.com/guide/developing/tools/index.html
20. Android apk ファイルの説明: http://developer.android.com/guide/topics/fundamentals.html
21. マニフェスト ファイル: http://developer.android.com/guide/topics/manifest/manifest-intro.html
22. モンキー テスト ツール: http://developer.android.com/guide/developing/tools/monkey.html
23. 複数の画面のサポート: http://developer.android.com/guide/practices/screens_support.html
24. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
25. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
26. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
27. センサー座標空間: http://developer.android.com/reference/android/hardware/SensorEvent.html
28. Android のセキュリティと権限のリファレンス: http://developer.android.com/guide/topics/security/security.html
29. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

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

3. ソフトウェア

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

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

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

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

3.2.ソフト API の互換性

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

3.2.1.権限

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

3.2.2.ビルド パラメータ

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

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

3.2.3.インテントの互換性

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

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

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

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

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

• 卓上時計
• ブラウザ
• カレンダー
• 電卓
• カメラ
• 連絡先
• Eメール
• ギャラリー
• グローバルサーチ
• ランチャー
• LivePicker (つまり、ライブ壁紙ピッカー アプリケーション。セクション 3.8.5 に従って、デバイスがライブ壁紙をサポートしていない場合は省略できます。)
• メッセージング (AKA "Mms")
• 音楽
• 電話
• 設定
• サウンドレコーダー

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

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

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

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

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

注: このセクションは Erratum EX6580 によって変更されました。

3.2.3.3.インテント名前空間

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

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

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

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

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

Dalvik で実行されるマネージ コードは、アプリケーションの .apk ファイルで提供されるネイティブ コードを、適切なデバイス ハードウェア アーキテクチャ用にコンパイルされた ELF .so ファイルとして呼び出すことができます。デバイスの実装には、標準の Java Native Interface (JNI) セマンティクスを使用して、管理された環境で実行されているコードがネイティブ コードを呼び出すためのサポートが含まれている必要があります。次の API をネイティブ コードで使用できる必要があります。

• libc (C ライブラリ)
• libm (数学ライブラリ)
• JNI インターフェース
• libz (Zlib 圧縮)
• liblog (Android ロギング)
• C++ の最小限のサポート
• 以下で説明する OpenGL のサポート

デバイス実装は、OpenGL ES 1.0 をサポートしなければなりません。ハードウェア アクセラレーションがないデバイスは、ソフトウェア レンダラーを使用して OpenGL ES 1.0 を実装する必要があります。デバイス実装は、デバイス ハードウェアがサポートするのと同じくらい多くの OpenGL ES 1.1 を実装する必要があります。ハードウェアがそれらの API で妥当なパフォーマンスを発揮できる場合、デバイス実装は OpenGL ES 2.0 の実装を提供する必要があります。

これらのライブラリは、Android オープン ソース プロジェクトによって Bionic で提供されるバージョンとソース互換性 (つまり、ヘッダー互換性) およびバイナリ互換性 (特定のプロセッサ アーキテクチャに対して) でなければなりません。 Bionic 実装は GNU C ライブラリなどの他の実装と完全に互換性がないため、デバイス実装者は Android 実装を使用する必要があります。デバイスの実装者がこれらのライブラリの別の実装を使用する場合、ヘッダー、バイナリ、および動作の互換性を確保する必要があります。

デバイス実装は、 android.os.Build.CPU_ABI API を介して、デバイスでサポートされているネイティブ アプリケーション バイナリ インターフェース (ABI) を正確に報告する必要があります。 ABI は、Android NDK の最新バージョンのdocs/CPU-ARCH-ABIS.txtファイルに記載されているエントリの 1 つでなければなりません。 Android NDK の追加リリースでは、追加の ABI のサポートが導入される可能性があることに注意してください。

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

3.4。 Web API の互換性

多くの開発者とアプリケーションは、ユーザー インターフェイスをandroid.webkit.WebViewクラス [参考文献、8 ] の動作に依存しているため、WebView の実装は Android の実装間で互換性がなければなりません。 Android オープン ソースの実装では、WebKit レンダリング エンジンを使用して WebView を実装します。

Web ブラウザー用の包括的なテスト スイートを開発することは現実的ではないため、デバイスの実装者は、WebView 実装で WebKit の特定のアップストリーム ビルドを使用する必要があります。具体的には：

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

実装は、スタンドアロンのブラウザ アプリケーションでカスタム ユーザー エージェント文字列を出荷する場合があります。さらに、スタンドアロンのブラウザは代替ブラウザ技術 (Firefox、Opera など) に基づいている場合があります。ただし、代替ブラウザ アプリケーションが出荷された場合でも、サードパーティ アプリケーションに提供される WebView コンポーネントは WebKit に基づいている必要があります。上記のように。

WebView 構成には、HTML5 データベース、アプリケーション キャッシュ、および地理位置情報 API のサポートが含まれている必要があります [参考文献、9 ]。 WebView には、何らかの形式で HTML5 <video>タグのサポートが含まれている必要があります。スタンドアロンのブラウザ アプリケーション (アップストリームの WebKit ブラウザ アプリケーションに基づいているか、サードパーティの代替アプリケーションに基づいているかに関係なく) は、WebView 用にリストされた同じ HTML5 機能のサポートを含まなければなりません。

3.5。 API 動作の互換性

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

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

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

互換性テスト スイート (CTS) は、プラットフォームのかなりの部分の動作の互換性をテストしますが、すべてではありません。 Android オープンソース プロジェクトとの動作の互換性を確保するのは、実装者の責任です。

3.6. API 名前空間

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

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

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

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

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

デバイスの実装者はカスタム API を追加することができますが、そのような API は、別の組織が所有する、または別の組織を参照する名前空間にあってはなりません。たとえば、デバイスの実装者は、API を com.google.* または同様の名前空間に追加してはなりません。 Google のみがこれを行うことができます。同様に、Google は他社の名前空間に API を追加してはなりません。

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

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

3.7.仮想マシンの互換性

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

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

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

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

3.8.1.ウィジェット

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

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

3.8.2.通知

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

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

3.8.3.探す

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

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

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

3.8.4.トースト

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

3.8.5.ライブ壁紙

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

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

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

4. 参照ソフトウェアの互換性

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

• 電卓 (SDK に含まれています)
• 月着陸船 (SDK に含まれる)
• 「Android 用アプリ」アプリケーション [リソース、18 ]。

上記の各アプリは、実装が互換性があると見なされるために、実装上で正しく起動して動作する必要があります。

さらに、デバイス実装は、これらの各スモーク テスト アプリケーションの各メニュー項目 (すべてのサブメニューを含む) をテストする必要があります。

• ApiDemos (SDK に含まれています)
• ManualSmokeTests (CTS に含まれる)

上記のアプリケーションの各テスト ケースは、デバイス実装で正しく実行する必要があります。

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

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

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

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

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

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

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

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

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

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

• Android Debug Bridge (adb として知られる) [リソース、19 ]
  デバイス実装は、Android SDK に記載されているすべてのadb関数をサポートする必要があります。デバイス側のadbデーモンはデフォルトで非アクティブにする必要がありますが、Android Debug Bridge をオンにするためのユーザー アクセス可能なメカニズムが必要です。
• Dalvik Debug Monitor Service (ddms として知られる) [リソース、19 ]
  Device implementations MUST support all ddms features as documented in the Android SDK. As ddms uses adb , support for ddms SHOULD be inactive by default, but MUST be supported whenever the user has activated the Android Debug Bridge, as above.
• Monkey [ Resources, 22 ]
  Device implementations MUST include the Monkey framework, and make it available for applications to use.

8. Hardware Compatibility

Android is intended to support device implementers creating innovative form factors and configurations. At the same time Android developers expect certain hardware, sensors and APIs across all Android device. This section lists the hardware features that all Android 2.1 compatible devices must support.

If a device includes a particular hardware component that has a corresponding API for third-party developers, the device implementation MUST implement that API as defined in the Android SDK documentation. If an API in the SDK interacts with a hardware component that is stated to be optional and the device implementation does not possess that component:

• class definitions for the component's APIs MUST be present
• the API's behaviors MUST be implemented as no-ops in some reasonable fashion
• API methods MUST return null values where permitted by the SDK documentation
• API methods MUST return no-op implementations of classes where null values are not permitted by the SDK documentation

A typical example of a scenario where these requirements apply is the telephony API: even on non-phone devices, these APIs must be implemented as reasonable no-ops.

Device implementations MUST accurate report accurate hardware configuration information via the getSystemAvailableFeatures() and hasSystemFeature(String) methods on the android.content.pm.PackageManager class.

8.1. Display

Android 2.1 includes facilities that perform certain automatic scaling and transformation operations under some circumstances, to ensure that third-party applications run reasonably well on a variety of hardware configurations [ Resources, 23 ]. Devices MUST properly implement these behaviors, as detailed in this section.

For Android 2.1, this are the most common display configurations:

Screen Type	Width (Pixels)	Height (Pixels)	Diagonal Length Range (inches)	Screen Size Group	Screen Density Group
QVGA	240	320	2.6 - 3.0	Small	Low
WQVGA	240	400	3.2 - 3.5	Normal	Low
FWQVGA	240	432	3.5 - 3.8	Normal	Low
HVGA	320	480	3.0 - 3.5	Normal	Medium
WVGA	480	800	3.3 - 4.0	Normal	High
FWVGA	480	854	3.5 - 4.0	Normal	High
WVGA	480	800	4.8 - 5.5	Large	Medium
FWVGA	480	854	5.0 - 5.8	Large	Medium

Device implementations corresponding to one of the standard configurations above MUST be configured to report the indicated screen size to applications via the android.content.res.Configuration [ Resources, 24 ] class.

Some .apk packages have manifests that do not identify them as supporting a specific density range. When running such applications, the following constraints apply:

• Device implementations MUST interpret resources in a .apk that lack a density qualifier as defaulting to "medium" (known as "mdpi" in the SDK documentation.)
• When operating on a "low" density screen, device implementations MUST scale down medium/mdpi assets by a factor of 0.75.
• When operating on a "high" density screen, device implementations MUST scale up medium/mdpi assets by a factor of 1.5.
• Device implementations MUST NOT scale assets within a density range, and MUST scale assets by exactly these factors between density ranges.

8.1.2. Non-Standard Display Configurations

Display configurations that do not match one of the standard configurations listed in Section 8.1.1 require additional consideration and work to be compatible. Device implementers MUST contact Android Compatibility Team as provided for in Section 12 to obtain classifications for screen-size bucket, density, and scaling factor. When provided with this information, device implementations MUST implement them as specified.

Note that some display configurations (such as very large or very small screens, and some aspect ratios) are fundamentally incompatible with Android 2.1; therefore device implementers are encouraged to contact Android Compatibility Team as early as possible in the development process.

8.1.3.指標の表示

Device implementations MUST report correct valuesfor all display metrics defined in android.util.DisplayMetrics [ Resources, 25 ].

8.2.キーボード

Device implementations:

• MUST include support for the Input Management Framework (which allows third party developers to create Input Management Engines -- ie soft keyboard) as detailed at developer.android.com
• MUST provide at least one soft keyboard implementation (regardless of whether a hard keyboard is present)
• MAY include additional soft keyboard implementations
• MAY include a hardware keyboard
• MUST NOT include a hardware keyboard that does not match one of the formats specified in android.content.res.Configuration.keyboard [ Resources, 24 ] (that is, QWERTY, or 12-key)

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

Device implementations:

• MAY omit a non-touch navigation options (that is, may omit a trackball, d-pad, or wheel)
• MUST report the correct value for android.content.res.Configuration.navigation [ Resources, 24 ]

8.4.画面の向き

Compatible devices MUST support dynamic orientation by applications to either portrait or landscape screen orientation. That is, the device must respect the application's request for a specific screen orientation. Device implementations MAY select either portrait or landscape orientation as the default.

Devices MUST report the correct value for the device's current orientation, whenever queried via the android.content.res.Configuration.orientation, android.view.Display.getOrientation(), or other APIs.

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

Device implementations:

• MUST have a touchscreen
• MAY have either capacative or resistive touchscreen
• MUST report the value of android.content.res.Configuration [ Resources, 24 ] reflecting corresponding to the type of the specific touchscreen on the device

8.6. USB

Device implementations:

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

8.7.ナビゲーション キー

The Home, Menu and Back functions are essential to the Android navigation paradigm. Device implementations MUST make these functions available to the user at all times, regardless of application state. These functions SHOULD be implemented via dedicated buttons. They MAY be implemented using software, gestures, touch panel, etc., but if so they MUST be always accessible and not obscure or interfere with the available application display area.

Device implementers SHOULD also provide a dedicated search key. Device implementers MAY also provide send and end keys for phone calls.

8.8. Wireless Data Networking

Device implementations MUST include support for wireless high-speed data networking. Specifically, device implementations MUST include support for at least one wireless data standard capable of 200Kbit/sec or greater. Examples of technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, etc.

If a device implementation includes a particular modality for which the Android SDK includes an API (that is, WiFi, GSM, or CDMA), the implementation MUST support the API.

Devices MAY implement more than one form of wireless data connectivity. Devices MAY implement wired data connectivity (such as Ethernet), but MUST nonetheless include at least one form of wireless connectivity, as above.

8.9. Camera

Device implementations MUST include a camera. The included camera:

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

Device implementations MUST implement the following behaviors for the camera-related APIs:

1. If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int), then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to application callbacks.
2. If an application registers an android.hardware.Camera.PreviewCallback instance and the system calls the onPreviewFrame() method when the preview format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame() must further be in the NV21 encoding format. (This is the format used natively by the 7k hardware family.) That is, NV21 MUST be the default.

Device implementations MUST implement the full Camera API included in the Android 2.1 SDK documentation [ Resources, 26 ]), regardless of whether the device includes hardware autofocus or other capabilities. For instance, cameras that lack autofocus MUST still call any registered android.hardware.Camera.AutoFocusCallback instances (even though this has no relevance to a non-autofocus camera.)

Device implementations MUST recognize and honor each parameter name defined as a constant on the android.hardware.Camera.Parameters class, if the underlying hardware supports the feature. If the device hardware does not support a feature, the API must behave as documented. Conversely, Device implementations MUST NOT honor or recognize string constants passed to the android.hardware.Camera.setParameters() method other than those documented as constants on the android.hardware.Camera.Parameters , unless the constants are prefixed with a string indicating the name of the device implementer. That is, device implementations MUST support all standard Camera parameters if the hardware allows, and MUST NOT support custom Camera parameter types unless the parameter names are clearly indicated via a string prefix to be non-standard.

8.10.加速度計

Device implementations MUST include a 3-axis accelerometer and MUST be able to deliver events at 50 Hz or greater. The coordinate system used by the accelerometer MUST comply with the Android sensor coordinate system as detailed in the Android APIs (see [ Resources, 27 ]).

8.11. Compass

Device implementations MUST include a 3-axis compass and MUST be able to deliver events 10 Hz or greater. The coordinate system used by the compass MUST comply with the Android sensor coordinate system as defined in the Android API (see [ Resources, 27 ]).

8.12. GPS

Device implementations MUST include a GPS, and SHOULD include some form of "assisted GPS" technique to minimize GPS lock-on time.

8.13.電話

Android 2.1 MAY be used on devices that do not include telephony hardware. That is, Android 2.1 is compatible with devices that are not phones. However, if a device implementation does include GSM or CDMA telephony, it MUST implement the full support for the API for that technology. Device implementations that do not include telephony hardware MUST implement the full APIs as no-ops.

See also Section 8.8, Wireless Data Networking.

8.14.メモリとストレージ

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

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

Note: this section was modified by Erratum EX6580.

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

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

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

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

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

Regardless of the form of shared storage used, the shared storage MUST implement USB mass storage, as described in Section 8.6. As shipped out of the box, the shared storage MUST be mounted with the FAT filesystem.

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

Note: this section was added by Erratum EX6580.

8.16.ブルートゥース

Device implementations MUST include a Bluetooth transceiver. Device implementations MUST enable the RFCOMM-based Bluetooth API as described in the SDK documentation [ Resources, 29 ]. Device implementations SHOULD implement relevant Bluetooth profiles, such as A2DP, AVRCP, OBEX, etc. as appropriate for the device.

Note: this section was added by Erratum EX6580.

9. Performance Compatibility

One of the goals of the Android Compatibility Program is to enable consistent application experience to consumers. Compatible implementations must ensure not only that applications simply run correctly on the device, but that they do so with reasonable performance and overall good user experience. Device implementations MUST meet the key performance metrics of an Android 2.1 compatible device defined in the table below:

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

10. Security Model Compatibility

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

10.1.権限

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

10.2. UID とプロセスの分離

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

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

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

11. Compatibility Test Suite

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

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

12. Updatable Software

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

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

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

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

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

13. Contact Us

You can contact the document authors at [e-mail] for clarifications and to bring up any issues that you think the document does not cover.