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() を呼び出して、アプリがインテントを処理できることを確認する必要があります。例:

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()
}

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 つあります

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

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
}

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
}

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

無線と接続

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:

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

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) を呼び出してオブジェクトにアクセスします。

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

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

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()
}

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 つがあります。

• ROTATION_ANIMATION_CROSSFADE
• ROTATION_ANIMATION_JUMPCUT
• ROTATION_ANIMATION_ROTATE

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

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

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

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

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():

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

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

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

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

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

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

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 差分レポート。