このページは Cloud Translation API によって翻訳されました。

Android 4.2 API

API レベル: 17

Android 4.2（JELLY_BEAN_MR1）は、ユーザーとアプリデベロッパー向けの新しい機能を提供する Jelly Bean リリースのアップデートです。このドキュメントでは、デベロッパー向けの新しい API を紹介します。

アプリのデベロッパーの皆様には、お早めに、SDK Manager から Android 4.2 のシステムイメージおよび SDK プラットフォームをダウンロードしていただく必要があります。アプリをテストするにあたり、Android 4.2 が搭載された端末をお持ちでない場合は、Android 4.2 のシステムイメージを使用して Android エミュレータでアプリをテストしてください。その後、Android 4.2 プラットフォームに対してアプリをビルドし、最新の API の使用を開始します。

Android 4.2 を搭載した端末向けにアプリを最適化するには、targetSdkVersion を "17" に設定し、Android 4.2 システムイメージにアプリをインストールした後、この変更を加えたアップデート済みのアプリを公開します。

マイページ Android 4.2 で API を使用できますが、実行前にシステムの API レベルをチェックする条件をコードに追加 minSdkVersion でサポートされていない API。下位互換性の維持について詳しくは、下位互換性のある UI の作成をご覧ください。

API レベルの仕組みについて詳しくは、API とは何かをご覧ください。レベル

重要な動作の変更点

以前に Android 向けアプリを公開したことがある場合は、以下の点にご注意ください。次のような変更を行います。

コンテンツプロバイダはデフォルトでエクスポートされなくなりました。つまり、デフォルト値が android:exported 属性が “false" になりました。他のアプリがコンテンツプロバイダにアクセスできるようにすることが重要である場合は、android:exported="true" を明示的に設定する必要があります。
この変更は、android:targetSdkVersion または android:minSdkVersion を 17 以上に設定した場合にのみ有効になります。それ以外の場合、Android 4.2 以降で実行する場合でも、デフォルト値は “true" です。
以前のバージョンの Android と比較すると、ユーザーの位置情報の結果の精度が低くなる可能性がありますアプリが ACCESS_COARSE_LOCATION 権限をリクエストしても、 ACCESS_FINE_LOCATION 権限をリクエストしない。
アプリがおおよその位置情報（正確な位置情報ではない）の利用許可をリクエストする際に、ユーザーのプライバシーに関する期待に応えるため、システムは 1 街区よりも正確なユーザー位置情報の推定値を提供しません。
Settings.System で定義された一部のデバイスの設定 読み取り専用です。アプリが Settings.System で定義され、Settings.Global に移動された設定に変更を書き込もうとすると、Android 4.2 以降で実行されている場合、書き込みオペレーションはサイレントで失敗します。
android:targetSdkVersion と android:minSdkVersion の値が 17 未満の場合でも、Android 4.2 以降で実行されているアプリは、Settings.Global に移動された設定を変更できません。
アプリで WebView を使用している場合、Android 4.2 ではセキュリティレイヤが追加されるため、JavaScript を Android コードに安全にバインドできます。targetSdkVersion を 17 以上に設定している場合、JavaScript で利用できるようにしたい任意のメソッドに @JavascriptInterface アノテーションを追加する必要があります（メソッドは public にする必要もあります）。アノテーションを設定しない場合、Android 4.2 以降では WebView のウェブページからメソッドにアクセスできません。targetSdkVersion を 16 以下に設定した場合、アノテーションは不要ですが、セキュリティを強化するためにターゲットバージョンを更新してアノテーションを追加することをおすすめします。
バインディングの詳細 JavaScript コードから Android コードへの変換をご覧ください。

Daydream

Daydream は、Android デバイス向けの新しいインタラクティブなスクリーンセーバーモードです。デバイスがホルダーに挿入されたとき、または充電器に接続したままデバイスがアイドル状態になったときに自動的に有効になります（画面をオフにする代わりに）。Daydream では、一度に 1 つのドリームが表示されます。これは、タップすると閉じる純粋に視覚的なパッシブディスプレイの場合もあれば、インタラクティブで、入力イベントの全スイートに応答するディスプレイの場合もあります。アプリのプロセスで夢を実現し、さまざまな機能にビュー、レイアウト、アニメーションなどの Android UI ツールキットを使うことで、ライブ壁紙やアプリウィジェットよりも強力です。

Daydream 用のドリームを作成するには、DreamService のサブクラスを実装します。DreamService API は、Activity の API に似せて設計されています。ドリームの UI を指定するには、onAttachedToWindow() コールバックなど、ウィンドウを取得した後で、レイアウトリソース ID または View を setContentView() に渡します。

DreamService クラスには、ベースの Service API に加えて、onDreamingStarted()、onDreamingStopped()、onDetachedFromWindow() などの重要なライフサイクルコールバックメソッドが用意されています。アプリから DreamService を開始することはできません。DreamService はシステムによって自動的に起動されます。

ドリームがインタラクティブな場合は、ドリームからアクティビティを開始して、ユーザーをアプリの完全な UI に誘導し、詳細やコントロールを可能にできます。finish() を使用してドリームを終了し、ユーザーに作成します。

デイドリームをシステムで使用できるようにするには、<service> 要素で DreamService を宣言します。指定します。次に、アクション "android.service.dreams.DreamService" を指定したインテントフィルタを含める必要があります。例:

<service android:name=".MyDream" android:exported="true"
    android:icon="@drawable/dream_icon" android:label="@string/dream_label" >
    <intent-filter>
        <action android:name="android.service.dreams.DreamService" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</service>

DreamService には、他にも便利なメソッドがあります。次の点に留意してください。

setInteractive(boolean) は、ドリームが入力イベントを受信するか、ユーザー入力時にすぐに終了するかを制御します。もし夢がユーザーは、戻るボタンやホームボタンを使用して夢を見るか、 finish()して夢を止めてください。
没入感のあるディスプレイを実現するには、setFullscreen() を呼び出してステータスバーを非表示にします。
Daydream が開始する前に、ディスプレイが暗くなり、アイドルタイムアウトが近づいていることをユーザーに知らせます。setScreenBright(true) を呼び出すと、ディスプレイを通常の明るさに設定できます。

詳細については、DreamService のドキュメントをご覧ください。

セカンダリディスプレイ

Android では、接続されている他の画面に独自のコンテンツを表示できるようになりましたユーザーのデバイスに安全に接続します。セカンダリディスプレイに固有のコンテンツを作成するには、Presentation クラスを拡張して onCreate() コールバックを実装します。範囲内 onCreate(): セカンダリディスプレイの UI を指定します setContentView() を呼び出します。 Dialog クラスの拡張として、Presentation クラスは、アプリが一意の UI を表示できる領域を提供します。設定されます。

Presentation を表示できるセカンダリディスプレイを検出するには、次の手順を行います。 DisplayManager または MediaRouter を使用する API一方、DisplayManager API を使用すると、複数のディスプレイを一度に接続することもできますが、通常は MediaRouter を使用して、システムのデフォルトのディスプレイにすばやくアクセスできるようにします。説明します。

プレゼンテーションのデフォルトのディスプレイを取得するには、MediaRouter.getSelectedRoute() を呼び出して ROUTE_TYPE_LIVE_VIDEO を渡します。これにより、動画プレゼンテーションに現在選択されているシステムのルートを記述する MediaRouter.RouteInfo オブジェクトが返されます。MediaRouter.RouteInfo が null でない場合は、次の関数を呼び出します。 getPresentationDisplay(): 接続されたディスプレイを表す Display を取得します。

次に、Display オブジェクトを Presentation クラスのコンストラクタに渡して、プレゼンテーションを表示します。プレゼンテーションがセカンダリディスプレイに表示されます。

新しいディスプレイが接続されたときに実行時に検出するには、MediaRouter.SimpleCallback のインスタンスを作成して onRoutePresentationDisplayChanged() コールバックメソッドを実装します。このメソッドは、新しいプレゼンテーションディスプレイが接続されたときにシステムが呼び出します。次に、ROUTE_TYPE_LIVE_VIDEO ルートタイプとともに MediaRouter.addCallback() に渡して、MediaRouter.SimpleCallback を登録します。onRoutePresentationDisplayChanged() への呼び出しを受けたら、上記のように MediaRouter.getSelectedRoute() を呼び出します。

セカンダリスクリーン用に Presentation の UI をさらに最適化するには、アプリまたはアクティビティに適用した <style> で android:presentationTheme 属性を指定して、別のテーマを適用します。

ユーザーのデバイスに接続されている画面は、多くの場合画面サイズが大きく、画面密度が異なる可能性があります。画面の特性は異なる場合があるため、そのような大きなディスプレイ向けに最適化されたリソースを提供します。Presentation から追加のリソースをリクエストする必要がある場合は、getContext().getResources() を呼び出して、ディスプレイに対応する Resources オブジェクトを取得します。これにより、セカンダリディスプレイの画面サイズと画面密度に最適なアプリの適切なリソースが提供されます。

詳細とコードサンプルについては、Presentation をご覧ください。クラスのドキュメントを参照してください。

ロック画面ウィジェット

Android では、ユーザーがアプリウィジェットをロック画面に追加できるようになりました。ロック画面でアプリウィジェットを使用できるようにするには、AppWidgetProviderInfo を指定する XML ファイルに android:widgetCategory 属性を追加します。この属性には次の 2 つの値がサポートされています: home_screen および keyguard。デフォルトでは、この属性は home_screen に設定されているため、ユーザーはアプリウィジェットをホーム画面に追加できます。ロックでもアプリウィジェットを使用したい場合 keyguard の値を追加します。

<appwidget-provider xmlns:android="http://schemas.android.com/apk/res/android"
    ...
    android:widgetCategory="keyguard|home_screen">
</appwidget-provider>

また、ロック画面に表示されるアプリウィジェットの初期レイアウトを android:initialKeyguardLayout 属性で指定する必要があります。これは、次のという点で android:initialLayout と同じように動作します。アプリウィジェットが初期化されてできます。

ロック画面用アプリウィジェットの作成について詳しくは、ロック画面でのアプリウィジェットの適切なサイズ設定など、アプリウィジェットガイドをご覧ください。

複数ユーザー

Android では、タブレットなどの共有可能なデバイスで複数のユーザー空間を使用できるようになりました。1 台のデバイスでデバイスには、固有のアカウント、アプリ、システム設定、ファイルなど、防ぐことができます。

アプリデベロッパーは、アプリが 1 台のデバイスで複数のユーザーが使用しても適切に動作するようにするために、特別な対応を行う必要はありません。1 つのプロジェクトに何人のユーザーがアプリが保存するデータと、アプリが保存するデータと使用できます。システムは、アプリが実行されているユーザープロセスに属するユーザーデータを追跡し、そのユーザーのデータのみにアプリがアクセスできるようにします。他のユーザーのデータにはアクセスできません。

マルチユーザー環境でのデータの保存

アプリがユーザー設定の保存、データベースの作成、ユーザーのファイルへのファイルの書き込みを行うときそのデータにアクセスできるのは、そのユーザーとして実行しているときだけです。

マルチユーザー環境でアプリが適切に動作するようにするには、ハードコードされたパスを使用して内部アプリディレクトリまたは外部ストレージの場所を参照せず、常に適切な API を使用してください。

内部ストレージにアクセスするには、getFilesDir()、getCacheDir()、または openFileOutput() を使用します。
外部ストレージにアクセスするには、getExternalFilesDir() または getExternalStoragePublicDirectory() を使用します。

特定のユーザーのデータを保存するためにどの API を使用しても、別のユーザーとして実行している間はデータにアクセスできません。アプリの視点から見ると、各ユーザーはダウンロードされます。

マルチユーザー環境でのユーザーの識別

アプリでユニークユーザーを識別して分析情報を収集したり、他のアカウントを作成したりする必要がある場合関連付けがある場合は、サービスアカウントを固有のインストール。アプリの初回起動時に新しい UUID を作成すると、1 台のデバイスにアプリをインストールするユーザーの数に関係なく、各ユーザーを追跡するための一意の ID を確実に取得できます。または、取得したローカルトークンを Google Cloud Messaging が提供する登録 ID を使用することもできます。

アプリがハードウェアデバイス ID（Wi-Fi MAC アドレスや SERIAL 番号など）のいずれかをリクエストした場合、これらの ID はユーザーではなくハードウェアに関連付けられているため、ユーザーごとに同じ値が提供されます。もう一つは言うまでもなくアプリのインストールに関するブログ投稿をご覧ください。

新しい全般設定

Settings.Global の追加により、複数のユーザーがサポートできるようにシステム設定が更新されました。これらの設定は読み取り専用のため Settings.Secure の設定と似ていますが、すべての環境にわたってグローバルに適用されます。すべてのユーザースペースに適用されます。

既存の設定のいくつかが、Settings.System または Settings.Secure からここに移動されました。アプリで現在、Settings.System で以前に定義された設定（AIRPLANE_MODE_ON など）を変更している場合、それらの設定が Settings.Global に移動されていると、Android 4.2 以降を搭載したデバイスでは変更できなくなります。以下の設定は引き続き読み取ることができます Settings.Global。ただし、この設定が安全とみなされなくなったため変更しようとすると自動的に失敗し、アプリケーションに対して Android 4.2 以降でアプリを実行する際のシステムログ。

RTL レイアウトのサポート

Android には、スムーズなユーザーインターフェースを構築できる API がいくつか用意されています。レイアウトの向きを変換して、右から左（RTL）の UI と読み上げを使用する言語をサポートするアラビア語やヘブライ語の方向に進むことができます

アプリで RTL レイアウトのサポートを開始するには、マニフェストファイルの <application> 要素に android:supportsRtl 属性を設定し、“true" に設定します。これを有効にすると、システムでさまざまな RTL API が有効になり、 RTL レイアウトでアプリを表示します。たとえば、アクションバーでは、アイコンとタイトルが右側に、アクションボタンが左側に表示されます。また、フレームワーク提供の View クラスで作成したレイアウトも反転されます。

アプリを RTL レイアウトで表示したときの外観をさらに最適化する必要がある場合は、最適化には 2 つの基本的なレベルがあります。

左向きと右向きのレイアウトプロパティを開始向きと終了指向のレイアウトに変換するプロパティです。
たとえば、android:layout_marginStart を使用します。は android:layout_marginLeft に、android:layout_marginEnd は android:layout_marginRight に置き換えられます。
RelativeLayout クラスには、左 / 右の位置を置き換えるための対応するレイアウト属性も用意されています。たとえば、android:layout_alignParentStart は android:layout_alignParentLeft に置き換え、android:layout_toLeftOf の代わりに android:layout_toStartOf に置き換えることができます。
または、RTL レイアウトを完全に最適化するには、ldrtl リソース修飾子（ldrtl はレイアウト方向右から左を表します）を使用して、完全に別のレイアウトファイルを指定できます。たとえば、デフォルトのレイアウトファイルを res/layout-ldrtl/ の res/layout/ と RTL 最適化レイアウト。
ldrtl 修飾子はドローアブルリソースに適しているため、グラフィックは読み方に対応する向きに配置されます

フレームワーク全体で、RTL レイアウトをサポートするさまざまな API を利用できます。たとえば、View クラスではカスタムビューに適切な動作を実装できます。また、Configuration では現在のレイアウトの向きをクエリできます。

注: SQlite を使用していて、名前が SQlite の場合の “数値のみ” 注意: String.format(String, Object...) を使用すると、エラーの原因となるは、デバイスの言語 / 地域がアラビア語に設定されている場合、アラビア語の同等の言語に変換されます。数値が ASCII として保持されるようにするには、String.format(Locale,String,Object...) を使用する必要があります。また、代わりに String.format("%d", int) も使用します。 String.valueOf(int): 数値を書式設定できます

Fragment のネスト

フラグメント内にフラグメントを埋め込むことができるようになりました。この方法は、さまざまな状況で役立ちます。動的で再利用可能な UI コンポーネントを、それ自体が動的かつ再利用しやすいものにしますたとえば、ViewPager を使用して、左右にスワイプして画面スペースの大部分を占めるフラグメントを作成する場合は、各フラグメントページにフラグメントを挿入できるようになりました。

フラグメントをネストするには、フラグメントを追加する Fragment で getChildFragmentManager() を呼び出します。これにより、トップレベルアクティビティから通常どおりに使用できる FragmentManager が返されます。フラグメントトランザクションを作成します。たとえば、次のコードは、内部からフラグメントを追加するコードです。既存の Fragment クラスの場合:

Kotlin

val videoFragment = VideoPlayerFragment()
childFragmentManager.beginTransaction().apply {
    add(R.id.video_fragment, videoFragment)
    commit()
}

Java

Fragment videoFragment = new VideoPlayerFragment();
FragmentTransaction transaction = getChildFragmentManager().beginTransaction();
transaction.add(R.id.video_fragment, videoFragment).commit();

ネストされたフラグメント内から、getParentFragment() を呼び出して親フラグメントへの参照を取得できます。

Android サポートライブラリもネストされたフラグメントをサポートするようになりました。これにより、Android 1.6 以降でネストされたフラグメント設計を実装できるようになりました。

注: レイアウトに <fragment> が含まれている場合、そのレイアウトをフラグメントにインフレートすることはできません。ネストされたフラグメントは、フラグメントに動的に追加された場合にのみサポートされます。

Renderscript

Renderscript の計算機能が拡張され、次の機能が導入されました。

スクリプトの組み込み

Renderscript の組み込みスクリプトイントリンシックを使用して、次のような一般的なオペレーションを実装できます。

Blends
Blur
Color matrix
3x3 convolve
5x5 convolve
Per-channel lookup table
Converting an Android YUV buffer to RGB

スクリプト組み込みを使用するには、各組み込みの静的 create() メソッドを呼び出して、スクリプトのインスタンスを作成します。次に、各スクリプト固有の使用可能な set() メソッドを呼び出して、必要な入力とオプションを設定します。最後に、forEach() を呼び出します。メソッドを使用してスクリプトを実行します。

スクリプトグループ

ScriptGroup を使用すると、関連する Renderscript スクリプトを連結して 1 回の呼び出しで実行できます。

ScriptGroup.Builder を使用して addKernel() を呼び出し、すべてのスクリプトをグループに追加します。一旦すべてのスクリプトを追加し、サービス間の接続を addConnection() を呼び出してスクリプトを作成します。接続の追加が完了したら、create() を呼び出します。スクリプトグループを作成しますスクリプトグループを実行する前に、入力 Allocation と setInput(Script.KernelID, Allocation) メソッドで実行する初期スクリプトを指定し、結果が書き込まれる出力 Allocation と setOutput() で実行する最終スクリプトを指定します。最後に、 execute(): スクリプトグループを実行します。

フィルタスクリプト

Filterscript は、生成されたコードをより幅広いプロセッサ（CPU、GPU、DSP）で実行できるように、既存の Renderscript API に制約を定義します。Filterscript ファイルを作成するには、.fs を作成しますファイルに .rs ファイルではなく #pragma rs_fp_relaxed を指定して、スクリプトで厳密な IEEE 754-2008 浮動小数点精度を必要としないことを Renderscript ランタイムに指示します。この精度では、denorms と round-towards-zero に対して flush-to-zero が有効になります。また、Filterscript は root() 関数のデフォルト署名で定義されているポインタをサポートしていないため、Filterscript スクリプトでは 32 ビットの組み込み型を使用しないでください。また、__attribute__((kernel)) 属性を使用してカスタムルート関数を指定する必要があります。

注: Filterscript はプラットフォームでもサポートされていますが、のサポートは、SDK Tools リリース 21.0.1 で使用できるようになります。

Android 4.2 のすべての API の変更点の詳細については、API の相違点レポートをご覧ください。

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