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

Android 4.3 API

API レベル: 18

Android 4.3（JELLY_BEAN_MR2）は Jelly Bean リリースのアップデートであり、ユーザーとアプリに新機能を提供します。開発できます。このドキュメントでは、説明します。

アプリデベロッパーは、Android 4.3 システムイメージをダウンロードする必要があります。 SDK Manager から必要があります。Android 4.3 を搭載したデバイスをアプリをテストするには、Android 4.3 システムを使用してイメージを使用して Android Emulator でアプリをテストします。次に、Android 4.3 プラットフォームに対してアプリをビルドし、最新の API を提供します。

対象 API レベルを更新する

Android 4.3 を搭載するデバイス向けにアプリを最適化するには、以下を行います。 targetSdkVersion を "18"、Android 4.3 システムイメージにインストールし、そのうえで変更したアップデートを公開できます

Android 4.3 でも API を使用できますが、実行前にシステムの API レベルをチェックする条件をコードに追加 minSdkVersion でサポートされていない API。下位互換性の維持について詳しくは、異なる API のサポート、プラットフォームのバージョンをご覧ください。

Android サポートライブラリでは、さまざまな API を使用して実装することもできます。古いバージョンのプラットフォームに新しい機能を追加する必要はありません

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

重要な動作変更

過去に Android 向けアプリを公開したことがある場合は、 Android 4.3 における変更の影響を受けます。

アプリが暗黙的インテントを使用する場合

お客様のアプリは、制限付きプロファイル環境で誤動作する可能性があります。

制限付きプロファイル環境のユーザーは、標準 Android アプリをすべて利用できます。たとえば、制限付きプロファイルにウェブブラウザとカメラアプリが無効になっている。そのため、どのアプリが何であるかを前提として、使用できます。指定せずに startActivity() を呼び出すと、アプリで Intent を処理できるかどうかを検証する制限付きプロファイルではアプリがクラッシュする可能性があります。

暗黙的インテントを使用する場合は、必ず resolveActivity() または queryIntentActivities() を呼び出して、アプリがインテントを処理できることを確認する必要があります。例:

Kotlin

val intent = Intent(Intent.ACTION_SEND)
...
if (intent.resolveActivity(packageManager) != null) {
    startActivity(intent)
} else {
    Toast.makeText(context, R.string.app_not_available, Toast.LENGTH_LONG).show()
}

Java

Intent intent = new Intent(Intent.ACTION_SEND);
...
if (intent.resolveActivity(getPackageManager()) != null) {
    startActivity(intent);
} else {
    Toast.makeText(context, R.string.app_not_available, Toast.LENGTH_LONG).show();
}

アプリがアカウントに依存している場合

お客様のアプリは、制限付きプロファイル環境で誤動作する可能性があります。

制限付きプロファイル環境内のユーザーは、デフォルトではユーザーアカウントにアクセスできません。アプリが Account に依存している場合、アプリがクラッシュしたり動作したりする可能性があります予期しないエラーを引き起こす可能性があります。

制限付きプロファイルによってアプリが完全に使用されないようにしたい場合は、アプリが機密性の高いアカウント情報に依存している場合は、マニフェストの <application> で android:requiredAccountType 属性を指定してください要素です。

制限付きプロファイルでアプリが許可されていない場合でも、アプリの使用を継続できるようにする場合は、アカウントを必要とするアプリの機能を無効化するか、制限付きプロファイルにメインユーザーが作成したアカウントへのアクセスを許可するかを指定できます。詳細詳しくは、このモジュールの下記の制限付きプロファイルでのアカウントのサポートをご覧ください。

アプリで VideoView を使用する場合

Android 4.3 では、動画が小さく表示される場合があります。

以前のバージョンの Android で、VideoView ウィジェットが正しく機能していなかった layout_height と layout_width の "wrap_content" 値が "match_parent" と同じになるように計算しました。そのため、高さまたは幅に "wrap_content" を使用しても、希望の動画レイアウトが設定されていた可能性があります。 Android 4.3 以降では、動画のサイズが大幅に小さくなることがあります。この問題を解決するには、 "match_parent" で "wrap_content"し、動画が想定どおりに表示されることを確認します Android 4.3 とそれ以前のバージョンの両方で利用できます。

制限付きプロファイル

Android タブレットで、プライマリユーザーに基づいて制限付きプロファイルを作成できるようになりました。ユーザーが制限付きプロファイルを作成する際に、どのアプリを使用するか、定義できます。Android 4.3 の新しい API セットでは、きめ細かい制限の設定を管理できます。たとえば、新しい API を使用すると、の実行時に、アプリで使用できるコンテンツの種類をユーザーが制限されたプロファイル環境を提供します。

作成した制限をユーザーが制御するための UI は、システムの設定アプリ。アプリの制限設定をユーザーに表示するには、 ACTION_GET_RESTRICTION_ENTRIES インテントを受け取る BroadcastReceiver を作成して、アプリが提供する制限を宣言する必要があります。システムはこのインテントを呼び出して、次に、メインユーザーが以下の操作を行えるよう UI を構築します。制限付きプロファイルごとに制限を管理できます。

次の onReceive() メソッド: BroadcastReceiver を使用するには、アプリが指定する制限ごとに RestrictionEntry を作成する必要があります。各 RestrictionEntry では、制限のタイトル、説明、制限の 1 つを定義します。次のデータ型を使用できます。

TYPE_BOOLEAN: 制限 True または False を指定します
TYPE_CHOICE: 次を含む制限相互に排他的な複数の選択肢（ラジオボタンによる選択）。
TYPE_MULTI_SELECT は、相互に排他的でない複数の選択肢（チェックボックスの選択肢）がある。

次に、すべての RestrictionEntry オブジェクトを ArrayList に入れ、ブロードキャストレシーバの結果に EXTRA_RESTRICTIONS_LIST 件のエクストラ。

設定アプリでアプリの制限用の UI が作成され、 RestrictionEntry ごとに指定した一意のキーによる制限渡されます。ユーザーがアプリを起動したときに、次の方法で現在の制限を照会できます。 getApplicationRestrictions() を呼び出しています。これは、各制限の Key-Value ペアを含む Bundle を返します。 RestrictionEntry オブジェクトで定義したプロパティを使用します。

ブール値では処理できない、より具体的な制限を指定する場合、単一の場合、ユーザーが特定のアクションを指定できるユーザーが制限設定からそのアクティビティを開くことを許可できます。対象: ブロードキャストレシーバ（EXTRA_RESTRICTIONS_INTENT エクストラを含む）結果 Bundle になります。このエクストラでは、Intent を指定する必要があります。起動する Activity クラスを指定します（ putParcelable() メソッドを使用してインテントで EXTRA_RESTRICTIONS_INTENT を渡します。メインユーザーがカスタム制限を設定するアクティビティを入力すると、アクティビティは、 EXTRA_RESTRICTIONS_LIST または EXTRA_RESTRICTIONS_BUNDLE キー（指定したかどうかに応じて）（それぞれ RestrictionEntry オブジェクトまたは Key-Value ペア）を返します。

制限付きプロファイルでのアカウントのサポート

プライマリユーザーに追加されたアカウントは制限付きプロファイルで使用できますが、デフォルトでは、AccountManager API からアカウントにアクセスできません。制限付きモードで AccountManager のアカウントを追加しようとした場合失敗の結果が表示されます。これらの制限により、次のことが可能になります。選択肢は 3 つあります

制限付きプロファイルからオーナーのアカウントにアクセスすることを許可する。

制限付きプロファイルからアカウントにアクセスするには、次のように android:restrictedAccountType 属性を <application> タグに追加する必要があります。

<application ...
    android:restrictedAccountType="com.example.account.type" >

注意: この属性を有効にすると、アプリが、制限付きプロファイルからプライマリユーザーのアカウントにアクセスできるようにします。このようにアプリに表示される情報から個人を特定できる情報を開示しない場合のみすべて含めます。システム設定によりプライマリとアプリが制限付きプロファイルをアカウントに付与することをユーザーに通知して、ユーザーに明確に示す必要があります。そのアカウントへのアクセスがアプリの機能に重要です。可能であればプライマリユーザーに対して適切な制限コントロールを提供し、アカウントアクセスのレベルを定義する。許可しているかを確認します。

アカウントを変更できない特定の機能を無効にする。

アカウントを使用したいが、アプリのメインには必要でない場合アカウントが利用できるかどうかを確認し、利用できない場合は機能を無効にできます。まず、利用可能な既存のアカウントがあるかどうかを確認してください。そうでない場合は getUserRestrictions() を呼び出して新しいアカウントを作成し、結果の DISALLOW_MODIFY_ACCOUNTS エクストラを確認できます。true の場合、アカウントへのアクセスを必要とするアプリの機能はすべて無効にしてください。例:

Kotlin

val um = context.getSystemService(Context.USER_SERVICE) as UserManager
val restrictions: Bundle = um.userRestrictions
if (restrictions.getBoolean(UserManager.DISALLOW_MODIFY_ACCOUNTS, false)) {
    // cannot add accounts, disable some functionality
}

Java

UserManager um = (UserManager) context.getSystemService(Context.USER_SERVICE);
Bundle restrictions = um.getUserRestrictions();
if (restrictions.getBoolean(UserManager.DISALLOW_MODIFY_ACCOUNTS, false)) {
    // cannot add accounts, disable some functionality
}

注: このシナリオでは、Terraform 内で宣言する新しい属性がすべて表示されます。

プライベートアカウントにアクセスできない場合にアプリを無効にします。

それよりも、アプリを制限付きプロファイルで使用できないことが重要な場合は、アプリがアカウント内の機密性の高い個人情報に依存している（また、制限付きプロファイルが現在、新しいアカウントを追加できません）。 android:requiredAccountType 属性を <application> タグに追加します。

<application ...
    android:requiredAccountType="com.example.account.type" >

たとえば、Gmail アプリはこの属性を使用して、制限付きプロファイルでそれ自体を無効にします。オーナーの個人用メールアドレスは制限付きプロファイルでは使用できないためです。

無線と接続

Bluetooth Low Energy（Smart Ready）

Android では、android.bluetooth の新しい API により、Bluetooth Low Energy（LE）がサポートされるようになりました。新しい API を使用すると、Bluetooth Low Energy と通信する Android アプリを構築できます。心拍数モニターや歩数計などの周辺機器

Bluetooth LE は、一部の Bluetooth デバイスではご利用いただけません Android 搭載デバイスでは、マニフェストファイルで <uses-feature> を宣言する必要があります。 "android.hardware.bluetooth_le" の要素:

<uses-feature android:name="android.hardware.bluetooth_le" android:required="true" />

すでに Android の Classic Bluetooth API を使い慣れている場合は、 Bluetooth LE API にはいくつか違いがあります。最も重要なことは、大まかなオペレーションに使用する必要がある BluetoothManager クラスがあることです。たとえば、BluetoothAdapter の取得、接続されているデバイスの状態の確認などですたとえば次のようにして BluetoothAdapter:

Kotlin

val bluetoothManager = getSystemService(Context.BLUETOOTH_SERVICE) as BluetoothManager
bluetoothAdapter = bluetoothManager.adapter

Java

final BluetoothManager bluetoothManager =
        (BluetoothManager) getSystemService(Context.BLUETOOTH_SERVICE);
bluetoothAdapter = bluetoothManager.getAdapter();

Bluetooth LE 周辺機器を検出するには、BluetoothAdapter で startLeScan() を呼び出して実装を渡します。（BluetoothAdapter.LeScanCallback インターフェースの）Bluetooth 接続がアダプターが Bluetooth LE 周辺機器を検出すると、BluetoothAdapter.LeScanCallback 実装は Bluetooth LE 周辺機器への呼び出しを onLeScan() メソッドを使用します。このメソッドにより、値を表す BluetoothDevice オブジェクトが提供されます。デバイスの RSSI 値、デバイスの RSSI 値、記録します。

特定の種類の周辺機器のみをスキャンする場合は、代わりに startLeScan() を呼び出し、アプリがサポートする GATT サービスを指定する UUID オブジェクトの配列を含めます。

注: スキャンできるのは Bluetooth LE デバイスのみです。または 以前の API を使用してクラシック Bluetooth デバイスをスキャンします。LE と Classic の両方をスキャンすることはできません Bluetooth デバイスを 1 台ずつ持ちます。

Bluetooth LE 周辺機器に接続するには、対応するconnectGatt() BluetoothDevice オブジェクトを作成し、 BluetoothGattCallback。BluetoothGattCallback の実装が、接続に関するコールバックを受け取ります。デバイスやその他のイベントと結合します。onConnectionStateChange() ですメソッドが新しい状態として STATE_CONNECTED を渡すとデバイスとの通信を開始できるコールバックです。

デバイスで Bluetooth 機能にアクセスするには、アプリが特定の Bluetooth ユーザー権限。詳細については、Bluetooth Low Energy API ガイドをご覧ください。

Wi-Fi スキャン専用モード

ユーザーの現在地を特定する際、Android は Wi-Fi を使用してユーザーの現在地を特定付近のアクセスポイントをスキャンして場所を特定します。ただし、ユーザーはインターネットを使わずに Wi-Fi をバッテリーを節約するため、位置情報の精度が低下します。Android では、デバイスの Wi-Fi がアクセスポイントをスキャンして位置情報を取得できるようにするスキャン専用モードアクセスポイントに接続しないため、バッテリー使用量を大幅に削減できます。

Wi-Fi が現在オフになっているときにユーザーの位置情報を取得する必要がある場合は、アクション ACTION_REQUEST_SCAN_ALWAYS_AVAILABLE で startActivity() を呼び出して、Wi-Fi スキャン専用モードを有効にするようユーザーに求めています。

Wi-Fi 設定

新しい WifiEnterpriseConfig API を使用すると、エンタープライズ向けサービスで次のことが可能になります。管理対象デバイスの Wi-Fi 設定の自動化

着信に対するクイック応答

Android 4.0 以降、「クイック応答」と呼ばれる機能ユーザーは着信に応答したり電話に出たり、デバイスのロックを解除したりすることなく、すぐにテキストメッセージで着信できます。これまで、これらのクイックメッセージは常にデフォルトのメッセージアプリで処理されていました。どのアプリでも Service を作成することで、これらのメッセージを処理する機能を宣言できます。 ACTION_RESPOND_VIA_MESSAGE のインテントフィルタを使用します。

ユーザーが着信にクイック応答で応答すると、電話アプリは URI を含む ACTION_RESPOND_VIA_MESSAGE インテント受信者（呼び出し元）と EXTRA_TEXT エクストラの説明テキストを入力します。インテントを受け取ったサービスは、すぐに停止します（アプリにアクティビティは表示されません）。

このインテントを受け取るには、SEND_RESPOND_VIA_MESSAGE 権限を宣言する必要があります。

マルチメディア

MediaExtractor と MediaCodec の機能強化

Android で独自の動的アダプティブを簡単に記述できるようになりました ISO/IEC 23009-1 標準に準拠した Streaming over HTTP（DASH）プレーヤー MediaCodec と MediaExtractor の既存の API を使用します。これらの API の基盤となるフレームワークが更新され、断片化された MP4 ファイルの解析は可能だが、MPD メタデータの解析はアプリ側で行う個々のストリームを MediaExtractor に渡します。

暗号化されたコンテンツで DASH を使用する場合、getSampleCryptoInfo() メソッドによって、暗号化された各メディアの構造を記述する MediaCodec.CryptoInfo メタデータが返されることに注意してください。表示されます。また、getPsshInfo() メソッドが MediaExtractor は、DASH メディアの PSSH メタデータにアクセスできるようにします。このメソッドは、UUID オブジェクトのバイトへのマップを返します。 UUID: 暗号化スキームを指定し、バイトはデータ固有の関連付けられています

メディア DRM

新しい MediaDrm クラスは、デジタル著作権のモジュラーソリューションを提供します。 DRM 管理（DRM）をメディアコンテンツと切り離すことで、メディア再生から DRM に関する懸念事項を切り離すことができます。対象たとえば、このような API を分離することで、Widevine で暗号化されたコンテンツを、 Widevine メディア形式を使用する必要がありますこの DRM ソリューションは DASH 共通暗号化もサポートしているため、ストリーミングコンテンツにさまざまな DRM スキームを使用できます。

MediaDrm を使用すると、不透明な鍵リクエストメッセージを取得し、サーバーからのライセンス取得とプロビジョニングのためのキー応答メッセージ。お客様のアプリはサーバーとのネットワーク通信の処理を担当します。MediaDrm クラスは、メッセージの生成と処理のみを行います。

MediaDrm API は、 Android 4.1（API レベル 16）で導入された MediaCodec API コンテンツのエンコードとデコードに MediaCodec、暗号化されたコンテンツを処理するための MediaCrypto、MediaExtractor などの 2 つのインターフェースがあります。

まず、MediaExtractor を作成し、 MediaCodec オブジェクト。その後、DRM スキーム識別モジュールに UUID。通常はコンテンツ内のメタデータから取得され、コンストラクタを含む MediaDrm オブジェクトのインスタンス。

Surface からの動画のエンコード

Android 4.1（API レベル 16）で、低レベルアプリの MediaCodec クラスデコードを指します。Android 4.1 では、動画をエンコードする際、 ByteBuffer 配列を持つメディアですが、Android 4.3 では Surface をエンコーダへの入力として使用できるようになりました。たとえば、入力シーケンスをエンコードして、 OpenGL ES から生成されたフレームを使って読み込むことができます。

Surface をエンコーダの入力として使用するには、まず MediaCodec に対して configure() を呼び出します。次に、createInputSurface() を呼び出して Surface を受信し、メディアをストリーミングします。

たとえば、指定された Surface を OpenGL のウィンドウとして使用できます。それを eglCreateWindowSurface() に渡します。次に、サーフェスをレンダリングするときに、eglSwapBuffers() を呼び出してフレームを MediaCodec に渡します。

エンコードを開始するには、MediaCodec で start() を呼び出します。完了したら signalEndOfInputStream() を呼び出すエンコードを終了し、release() Surface。

メディア多重化

新しい MediaMuxer クラスは、1 つの音声ストリーム間の多重化を可能にします。 1 つの動画ストリームがありますこれらの API は、MediaExtractor に対応するものとして機能します。メディアの逆多重化（逆多重化）のために Android 4.2 で追加されたクラス。

サポートされている出力形式は、MediaMuxer.OutputFormat で定義されています。現在、サポートされている出力形式は MP4 のみです。現在、MediaMuxer は MP4 をサポートしています。音声ストリームや動画ストリームを 1 つずつに絞ることをおすすめします

MediaMuxer のほとんどは MediaCodec と連携するように設計されています MediaCodec で動画を処理してから、 MediaMuxer で MP4 ファイルに出力できます。MediaMuxer を MediaExtractor と組み合わせて使用すると、次の処理を行うこともできます。簡単に使いこなすことができます。

再生の進行状況と RemoteControlClient のスクラブ

Android 4.0（API レベル 14）では、RemoteControlClient がリモートコントロールクライアントからのメディア再生コントロール（ロック画面。Android 4.3 では、このようなコントローラで再生を行う機能が提供されるようになりました。位置と再生のスクラブ用コントロールを設定します。ご利用のデバイスでリモコンを有効にした場合は、 RemoteControlClient API を使用してメディアアプリを更新すると、再生を許可できます。 2 つの新しいインターフェースを実装してスクラブするようになりました。

まず、FLAG_KEY_MEDIA_POSITION_UPDATE フラグを setTransportControlsFlags()。

次に、次の 2 つの新しいインターフェースを実装します。

RemoteControlClient.OnGetPlaybackPositionListener: これには現在位置をリクエストするコールバック onGetPlaybackPosition() が含まれますリモコンの UI で進行状況を更新する必要がある場合に選択します。
RemoteControlClient.OnPlaybackPositionUpdateListener: これにはコールバック onPlaybackPositionUpdate() が含まれます。は、ユーザーが再生をスクラブしたときに、メディアの新しいタイムコードをアプリに通知します。リモコン UI です。
新しい位置で再生を更新したら、setPlaybackState() を呼び出して新しい再生状態、位置、速度を変更できます。

これらのインターフェースを定義したら、setOnGetPlaybackPositionListener() を呼び出して RemoteControlClient に設定できます。（それぞれ setPlaybackPositionUpdateListener()）。

グラフィック

OpenGL ES 3.0 のサポート

Android 4.3 では、OpenGL ES 3.0 の Java インターフェースとネイティブサポートが追加されています。主な新機能主なものは次のとおりです。

高度な視覚効果の高速化
高品質の ETC2/EAC テクスチャ圧縮を標準機能として
整数と 32 ビット浮動小数点数をサポートする新バージョンの GLSL ES シェーディング言語
高度なテクスチャレンダリング
テクスチャサイズとレンダリングバッファ形式の幅広い標準化

Android の OpenGL ES 3.0 用の Java インターフェースは、GLES30 で提供されています。 OpenGL ES 3.0 を使用する場合は、マニフェストファイルで <uses-feature> タグと android:glEsVersion 属性が含まれています。例:

<manifest>
    <uses-feature android:glEsVersion="0x00030000" />
    ...
</manifest>

また、setEGLContextClientVersion() を呼び出して OpenGL ES コンテキストを指定します。バージョンとして 3 を渡します。

サポートされているデバイスの確認方法など、OpenGL ES の使用方法実行時の OpenGL ES バージョンについては、OpenGL ES API ガイドをご覧ください。

ドローアブルのミップマッピング

ビットマップやドローアブルのソースとして mipmap を使用すると、さまざまな画像スケールが用意されています。アニメーション中にスケーリングされる画像。

Android 4.2（API レベル 17）では、Bitmap での mipmap のサポートが追加されました。クラス - Android は、次の場合に Bitmap 内の mip 画像を入れ替えます。 mipmap ソースを指定し、setHasMipMap() を有効にしている。Android 4.3 では、BitmapDrawable オブジェクトでも mipmap を有効にできます。そのためには、mipmap アセットとビットマップリソースファイル内で android:mipMap 属性を設定するか、hasMipMap() を呼び出します。

ユーザーインターフェース

オーバーレイの表示

新しい ViewOverlay クラスは、レイヤの上に透明なレイヤを提供します。ビジュアルコンテンツを追加できる View 継承されます。getOverlay() を呼び出すと、任意の View の ViewOverlay を取得できます。オーバーレイ常に同じサイズと位置が、ホストビュー（作成元のビュー）と同じになります。ホストビューの前に表示されるコンテンツ（拡張は不可）を追加できます。指定することもできます。

ViewOverlay の使用は、インスタンスグループやバケットなどのアニメーションをコンテナ外にスライドさせる、画面上でアイテムを移動するなどビュー階層に影響を与えませんただし、オーバーレイの使用可能領域は外部に移動するビューをアニメーション化する場合、親ビューから、目的の位置にオーバーレイを作成します。

Button のようなウィジェットビューのオーバーレイを作成すると、オーバーレイに Drawable オブジェクトを追加するには、 add(Drawable)。RelativeLayout などのレイアウトビューの getOverlay() を呼び出すと、次のようになります。返されるオブジェクトは ViewGroupOverlay です。「 ViewGroupOverlay クラスはサブクラスの ViewOverlay により View も追加可能 add(View) を呼び出してオブジェクトにアクセスします。

注: オーバーレイに追加するすべてのドローアブルとビュービジュアルのみフォーカスイベントや入力イベントを受け取ることはできません。

たとえば次のコードは、ビューを配置して右にスライドするビューをアニメーション化します。子ビューのオーバーレイに配置して、そのビューで変換アニメーションを実行します。

Kotlin

val view: View? = findViewById(R.id.view_to_remove)
val container: ViewGroup? = view?.parent as ViewGroup

container?.apply {
    overlay.add(view)
    ObjectAnimator.ofFloat(view, "translationX", right.toFloat())
            .start()
}

Java

View view = findViewById(R.id.view_to_remove);
ViewGroup container = (ViewGroup) view.getParent();
container.getOverlay().add(view);
ObjectAnimator anim = ObjectAnimator.ofFloat(view, "translationX", container.getRight());
anim.start();

光学境界レイアウト

9-patch の背景画像を含むビューで、9-patch の背景画像を表示するように隣接するビューに合わせて調整することもできます。指定することもできます。「クリップ」より後のあります。

たとえば、図 1 と図 2 は同じレイアウトを示していますが、図 1 と図 2 では同じレイアウトになっています。クリップ境界を使用します（デフォルトの動作）。図 2 は光学境界を使用しています。これは、ボタンとフォトフレームに使用される 9-patch 画像には、端のパディングが含まれます。クリップの境界を使うとき、テキストが互いに、またはテキストと揃っていないように見える。

注: 図 1 と図 2 のスクリーンショットには、レイアウト境界"有効にします。各ビューの赤い線は青い線はクリップの境界、ピンクはマージンを示します。

図 1. クリップ境界を使用したレイアウト（デフォルト）。

図 2. 光学境界を使用したレイアウト。

ビューを光学境界に基づいて配置するには、親レイアウトのいずれかで android:layoutMode 属性を "opticalBounds" に設定します。例:

<LinearLayout android:layoutMode="opticalBounds" ... >

図 3. ホロボタンの 9-patch の拡大表示光学境界です

そのためには、ビューの背景に適用する 9-patch 画像に、 9-patch ファイルの下部と右側に赤い線を使用して図 3 を参照）。赤い線は、引かれる範囲を示します。クリップの境界内に収まり、画像の光学的境界は残ります。

レイアウト内の ViewGroup の光学境界を有効にすると、すべてのグループ化でオーバーライドしない限り、子孫ビューは光学境界レイアウトモードを継承します android:layoutMode を "clipBounds" に設定します。すべてのレイアウト要素には子ビューの光学境界を設定し、それに基づいて独自の境界を適応させます。その中のビューを変更できます。ただし、レイアウト要素（ViewGroup のサブクラス）は現在のところ、自身の背景に適用する 9-patch 画像の光学境界に対応していません。

View、ViewGroup、またはそのサブクラスをサブクラス化してカスタムビューを作成すると、ビューは、このような光学的バインドの動作を継承します。

注: Holo テーマでサポートされているウィジェットはすべて更新されています。光学境界（Button、Spinner、 EditText などこのようにアプリがホロテーマを適用する場合は、android:layoutMode 属性を "opticalBounds" に指定します（Theme.Holo、Theme.Holo.Light など）。

9-patch 描画ツールで独自の 9-patch 画像の光学境界を指定するには、枠線ピクセルをクリックするだけです

Rect 値のアニメーション

新しい RectEvaluator を使用して、2 つの Rect 値の間でアニメーション化できるようになりました。この新しいクラスは、ValueAnimator.setEvaluator() に渡すことができる TypeEvaluator の実装です。

ウィンドウアタッチリスナーとフォーカスリスナー

以前は、ビューがウィンドウまたはデタッチされたときにリッスンする場合、フォーカスが変更されたときに、View クラスをオーバーライドして、 onAttachedToWindow() と onDetachedFromWindow()、または onWindowFocusChanged() をそれぞれ実装します。

アタッチイベントとデタッチイベントを受信するには、代わりに ViewTreeObserver.OnWindowAttachListener を実装し、 addOnWindowAttachListener()。フォーカスイベントを受け取るには、ViewTreeObserver.OnWindowFocusChangeListener を実装し、 addOnWindowFocusChangeListener()。

テレビのオーバースキャンのサポート

アプリがすべてのテレビで画面全体に表示されるようにするには、オーバースキャンを有効にします最適化されていますオーバースキャンモードは FLAG_LAYOUT_IN_OVERSCAN フラグによって決定されます。このフラグは、次のようなプラットフォームテーマで有効にできます。 Theme_DeviceDefault_NoActionBar_Overscanするか、カスタムテーマの windowOverscan スタイル。

画面の向き

<activity> タグの screenOrientation 属性で、ユーザーの自動回転の設定を反映する次の値がサポートされるようになりました。

"userLandscape": ユーザーが自動回転を無効にしている場合を除き、"sensorLandscape" と同じように動作します。通常の横向きにロックされ、反転しません。
"userPortrait": ユーザーが自動回転を無効にしている場合を除き、"sensorPortrait" と同じように動作します。通常の縦向きにロックされ、反転しません。
"fullUser": "fullSensor" と同じように動作し、次を除くすべての方向への回転を許可します。ユーザーが自動回転を無効にすると、ユーザーが指定した画面の向きがロックされます。

さらに、"locked" を宣言して、アプリの向きを現在の画面の向きが変わります。

回転アニメーション

次の新しい rotationAnimation フィールド: WindowManager を使用すると、3 つのアニメーションの中から 1 つを選択できます。画面の向きが切り替わったときに使用するようにします。アニメーションには次の 3 つがあります。

注: これらのアニメーションは、「全画面」を使用するようにアクティビティを設定している場合にのみ使用できます。モード。Theme.Holo.NoActionBar.Fullscreen などのテーマで有効にできます。

たとえば、「クロスフェード」を有効にしてアニメーション:

Kotlin

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    val params: WindowManager.LayoutParams = window.attributes
    params.rotationAnimation = WindowManager.LayoutParams.ROTATION_ANIMATION_CROSSFADE
    window.attributes = params
    ...
}

Java

protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    WindowManager.LayoutParams params = getWindow().getAttributes();
    params.rotationAnimation = WindowManager.LayoutParams.ROTATION_ANIMATION_CROSSFADE;
    getWindow().setAttributes(params);
    ...
}

ユーザー入力

新しいセンサータイプ

新しい TYPE_GAME_ROTATION_VECTOR センサーにより、磁気干渉を気にせずにデバイスの回転を検出できます。TYPE_ROTATION_VECTOR センサーとは異なり、TYPE_GAME_ROTATION_VECTOR は磁北に基づいていません。

新しい TYPE_GYROSCOPE_UNCALIBRATED センサーと TYPE_MAGNETIC_FIELD_UNCALIBRATED センサーは、未加工のセンサーデータを提供します。考慮する必要がありますつまり、既存の TYPE_GYROSCOPE と TYPE_MAGNETIC_FIELD です。センサーから提供されるセンサーで、ジャイロドリフトと硬鉄からの推定バイアスを考慮した表示されます。一方新しい「未調整」のこれらのセンサーの新しいバージョンは推定バイアス値を個別に提示できますこれらのセンサーを使って推定バイアスを強化して、センサーデータの独自のカスタムキャリブレーションを提供します。外部データも参照できます

通知リスナー

Android 4.3 では、新しいサービスクラス NotificationListenerService が追加されています。これにより、システムから新しい通知が送信されたときに、その通知に関する情報を受け取れるようになります。

アプリで現在、ユーザー補助サービス API を使用してシステム通知にアクセスしている場合は、代わりにこれらの API を使用するようにアプリを更新する必要があります。

連絡先プロバイダ

「連絡先」のクエリ

連絡先プロバイダの新しいクエリ Contactables.CONTENT_URI を使用すると、指定したクエリに一致するすべての連絡先に属するすべてのメールアドレスと電話番号を含む 1 つの Cursor を効率的に取得できます。

連絡先の差分のクエリ

連絡先プロバイダに、連絡先データに対する最近の変更を効率的にクエリできる新しい API が追加されました。これまでは、連絡先データに変更が加えられたときにアプリが通知を受けることができましたが、変更内容を正確に把握できず、すべての連絡先を取得してから、それらを反復処理して変更を検出する必要がありました。

挿入と更新の変更を追跡するため、CONTACT_LAST_UPDATED_TIMESTAMP パラメータを選択項目に含めて、前回のプロバイダに対するクエリ以降に変更された連絡先のみをクエリできるようになりました。

削除された連絡先を追跡するために、新しいテーブル ContactsContract.DeletedContacts には削除された連絡先のログが表示されます（ただし、削除された各連絡先は一定期間このテーブルに保持されます）。CONTACT_LAST_UPDATED_TIMESTAMP と同様に、新しい選択パラメータ CONTACT_DELETED_TIMESTAMP を使用して、前回プロバイダをクエリした後に削除された連絡先を確認できます。このテーブルには、ログを保持する日数（ミリ秒単位）を示す定数 DAYS_KEPT_MILLISECONDS も含まれています。

さらに、ユーザーが指定された場合に、連絡先プロバイダが CONTACTS_DATABASE_CREATED アクションをブロードキャストするようになりました。システム設定メニューから連絡先ストレージを消去して連絡先プロバイダのデータベース。すべての連絡を取りやめる必要があることをアプリに知らせることを目的としています。新しいクエリで再読み込みできます。

これらの API を使用して連絡先の変更を確認するサンプルコードについては、ApiDemos を参照してください。 SDK サンプルからダウンロードしていただけます。

ローカライズ

双方向テキストのサポートの改善

以前のバージョンの Android は、右から左に記述する（RTL）言語とレイアウトをサポートしています。方向が混在しているテキストは適切に処理されないことがあります。そのため Android 4.3 では、逆方向のテキストを適切に書式設定できる BidiFormatter API が追加されています。コンテンツを部分的に変更します

たとえば、「もしかして 15 Bay Street, Laurel, CA? と書かれているので、通常はローカライズされた文字列リソースと変数を String.format():

Kotlin

val suggestion = String.format(resources.getString(R.string.did_you_mean), address)

Java

Resources res = getResources();
String suggestion = String.format(res.getString(R.string.did_you_mean), address);

ただし、ロケールがヘブライ語の場合、書式設定された文字列は次のようになります。

?Bay Street, Laurel, CAהאם התכוונת ל 15

「15」は「ベイストリート」の左側である必要がありますこの問題を解決するには、BidiFormatter とその unicodeWrap() メソッドを使用します。たとえば、上記のコードは次のようになります。

Kotlin

val bidiFormatter = BidiFormatter.getInstance()
val suggestion = String.format(
        resources.getString(R.string.did_you_mean),
        bidiFormatter.unicodeWrap(address)
)

Java

Resources res = getResources();
BidiFormatter bidiFormatter = BidiFormatter.getInstance();
String suggestion = String.format(res.getString(R.string.did_you_mean),
        bidiFormatter.unicodeWrap(address));

デフォルトでは、unicodeWrap() は最初の強力な方向推定ヒューリスティック。最初の呼び出しがテキスト方向のシグナルは、コンテンツ全体の適切な方向を表していません。必要に応じて、TextDirectionHeuristics の TextDirectionHeuristic 定数のいずれかを渡すことで、別のヒューリスティックを指定できます。宛先: unicodeWrap()

注: これらの新しい API は、以前のバージョンでも使用できます。 Android サポートを通じてライブラリ。BidiFormatter クラスと関連 API があります。

ユーザー補助サービス

キーイベントを処理する

AccessibilityService が次のコールバックを受け取れるようになりました。キー入力イベントを onKeyEvent() コールバックメソッドと併用します。これにより、ユーザー補助サービスによる入力をキーボードなどのキーベースの入力デバイスを使用して、それらのイベントを以前はタップ入力やデバイスの十字キーでしか行えなかったかもしれません。

テキストを選択してコピー/貼り付け

AccessibilityNodeInfo で、以下を許可する API が提供されるようになりました。選択、切り取り、コピー、貼り付け用のAccessibilityService 作成します。

ユーザー補助サービスでは、切り取る、またはコピーするテキストを指定するため、新しいアクション、ACTION_SET_SELECTION、合格選択範囲の開始位置と終了位置は ACTION_ARGUMENT_SELECTION_START_INT と ACTION_ARGUMENT_SELECTION_END_INT です。または、既存のアクション、ACTION_NEXT_AT_MOVEMENT_GRANULARITY （以前はカーソル位置の移動のみ）を使用し、引数 ACTION_ARGUMENT_EXTEND_SELECTION_BOOLEAN を追加しました。

その後、ACTION_CUT で切り取りまたはコピーを行うことができます。 ACTION_COPY という名前を付け、後で「 ACTION_PASTE。

注: これらの新しい API は、以前のバージョンでも使用できます。 Android サポートを通じて Library（AccessibilityNodeInfoCompat を使用）クラスです。

ユーザー補助機能を宣言する

Android 4.3 以降、ユーザー補助サービスでユーザー補助機能を宣言する必要があるメタデータファイルに追加する必要があります。ケーパビリティがリクエストされた場合、その機能は機能しません。サービスの使用するには、各属性に対応する XML 属性を使用する必要があります。「capability」AccessibilityServiceInfo の定数クラスです。

たとえば、サービスが flagRequestFilterKeyEvents 機能をリクエストしない場合、キーイベントを受け取らなくなります

テストとデバッグ

自動 UI テスト

新しい UiAutomation クラスには、ユーザーをシミュレートできる API が用意されています。テスト自動化のためのアクションですプラットフォームの AccessibilityService API を使用すると、UiAutomation API を使用すると、画面コンテンツを検査し、任意のキーボードやタッチイベントを挿入できます。

UiAutomation のインスタンスを取得するには、Instrumentation.getUiAutomation() を呼び出します。順序これを行うには、instrument コマンドで -w オプションを指定する必要があります。 adb shell から InstrumentationTestCase を実行する場合。

UiAutomation インスタンスを使用すると、任意のイベントを実行してテストできます。 executeAndWaitForEvent() を呼び出し、実行する Runnable の値、つまりタイムアウトを指定してオペレーションの期間、UiAutomation.AccessibilityEventFilter インターフェースの実装。呼び出しを受けるのは、UiAutomation.AccessibilityEventFilter の実装内にあります関心のあるイベントをフィルタリングして特定のテストケースの失敗回数です

テスト中にすべてのイベントを監視するには、UiAutomation.OnAccessibilityEventListener の実装を作成して setOnAccessibilityEventListener() に渡します。リスナーインターフェースが onAccessibilityEvent() への呼び出しを受け取ります。イベントが発生するたびに、AccessibilityEvent オブジェクトを受け取るイベントを記述します。

UiAutomation API は他にもさまざまなオペレーションを公開しています（uiautomator などの UI テストツールの開発を奨励するため）たとえば UiAutomation で行える操作:

入力イベントを注入する
画面の向きを変更する
スクリーンショットを撮る

UI テストツールで最も重要なのは、UiAutomation API が機能することです。 Instrumentation とは異なり、アプリケーションの境界を越えてアクセスします。

アプリの Systrace イベント

Android 4.3 では、Trace クラスと次の 2 つの静的メソッドが追加されています。 beginSection() さんと endSection() さん、を使用すると、systrace レポートに含めるコードのブロックを定義できます。作成することにより、 Systrace ログでは、トレース可能コードのアプリ内のどこで速度が低下しているかを分析できます。

Systrace ツールの使用方法については、Systrace を使用したディスプレイとパフォーマンスの分析をご覧ください。

セキュリティ

アプリの秘密鍵の Android キーストア

Android では、KeyStore でカスタム Java セキュリティプロバイダが提供されるようになりましたと呼ばれる機能もあります。この機能を使用すると、そのアプリのみが表示、使用できるようにします。Android Key Store を読み込むには、 "AndroidKeyStore" から KeyStore.getInstance() に変更。

Android Key Store 内のアプリのプライベート認証情報を管理するには、 KeyPairGenerator は KeyPairGeneratorSpec に置き換えます。最初 getInstance() を呼び出して KeyPairGenerator のインスタンスを取得します。次に呼び出します initialize() を呼び出して、その関数に KeyPairGeneratorSpec: KeyPairGeneratorSpec.Builder。最後に、generateKeyPair() を呼び出して KeyPair を取得します。

ハードウェア認証情報ストレージ

Android は、KeyChain のハードウェア格納型ストレージもサポートしました鍵の抽出に使用不可にすることで、セキュリティが強化されます。つまり鍵がハードウェア格納型キーストア（セキュアエレメント、TPM、TrustZone）にある場合、秘密鍵のマテリアルはエクスポートできません。OS カーネルでもアクセスできません。すべての Android 搭載デバイスでストレージがサポートされるわけではありませんが、ハードウェア格納型ストレージが利用可能かどうかを実行時に確認するには、 KeyChain.IsBoundKeyAlgorithm()。

マニフェストの宣言

宣言可能な必須機能

<uses-feature> で次の値がサポートされるようになりました要素を使用して、その機能を提供するデバイスにのみアプリがインストールされるようにできます。選択できます。

FEATURE_APP_WIDGETS

お客様のアプリはアプリウィジェットを提供しているため、以下の要件を満たすデバイスにのみインストールする必要があると宣言します。ユーザーがアプリウィジェットを埋め込むことができるホーム画面または同様の場所を含むこと。例:

<uses-feature android:name="android.software.app_widgets" android:required="true" />

FEATURE_HOME_SCREEN

アプリがホーム画面の代替機能として動作し、サードパーティのホーム画面アプリに対応したデバイス例:

<uses-feature android:name="android.software.home_screen" android:required="true" />

FEATURE_INPUT_METHODS

アプリがカスタム入力方法（InputMethodService で構築されたキーボード）を提供し、以下の要件を満たすデバイスにのみインストールできることを宣言します。サードパーティの入力方法をサポートします。例:

<uses-feature android:name="android.software.input_methods" android:required="true" />

FEATURE_BLUETOOTH_LE

アプリが Bluetooth Low Energy API を使用し、デバイスにのみインストールする必要があることを宣言します Bluetooth Low Energy を介して他のデバイスと通信できる Bluetooth デバイス。例:

<uses-feature android:name="android.software.bluetooth_le" android:required="true" />

ユーザー権限

<uses-permission> で次の値がサポートされるようになりました宣言し、アプリが特定の API にアクセスするために必要な権限。

BIND_NOTIFICATION_LISTENER_SERVICE: 新しい NotificationListenerService API を使用するために必要です。
SEND_RESPOND_VIA_MESSAGE: ACTION_RESPOND_VIA_MESSAGE の受け取りに必要です使用します。

Android 4.3 でのすべての API の変更点について詳しくは、 API 差分レポート。

Android 4.3 API

対象 API レベルを更新する

重要な動作変更

アプリが暗黙的インテントを使用する場合

Kotlin

Java

アプリがアカウントに依存している場合

アプリで VideoView を使用する場合

制限付きプロファイル

制限付きプロファイルでのアカウントのサポート

Kotlin

Java

無線と接続

Bluetooth Low Energy（Smart Ready）

Kotlin

Java

Wi-Fi スキャン専用モード

Wi-Fi 設定

着信に対するクイック応答

マルチメディア

MediaExtractor と MediaCodec の機能強化

メディア DRM

Surface からの動画のエンコード

メディア多重化

再生の進行状況と RemoteControlClient のスクラブ

グラフィック

OpenGL ES 3.0 のサポート

ドローアブルのミップマッピング

ユーザー インターフェース

オーバーレイの表示

Kotlin

Java

光学境界レイアウト

Rect 値のアニメーション

ウィンドウ アタッチ リスナーとフォーカス リスナー

テレビのオーバースキャンのサポート

画面の向き

回転アニメーション

Kotlin

Java

ユーザー入力

新しいセンサータイプ

通知リスナー

連絡先プロバイダ

「連絡先」のクエリ

連絡先の差分のクエリ

ローカライズ

双方向テキストのサポートの改善

Kotlin

Java

Kotlin

Java

ユーザー補助サービス

キーイベントを処理する

テキストを選択してコピー/貼り付け

ユーザー補助機能を宣言する

テストとデバッグ

自動 UI テスト

アプリの Systrace イベント

セキュリティ

アプリの秘密鍵の Android キーストア

ハードウェア認証情報ストレージ

マニフェストの宣言

宣言可能な必須機能

ユーザー権限

ユーザーインターフェース

ウィンドウアタッチリスナーとフォーカスリスナー