API レベル: 18
Android 4.3(JELLY_BEAN_MR2
)は、ユーザーとアプリ デベロッパー向けの新機能を提供する Jelly Bean リリースのアップデートです。このドキュメントでは、いくつかの注目すべき API の概要について説明します。
アプリのデベロッパーの皆様には、お早めに、SDK Manager から Android 4.3 のシステム イメージおよび SDK プラットフォームをダウンロードしていただく必要があります。アプリをテストするにあたり、Android 4.3 が搭載された端末をお持ちでない場合は、Android 4.3 のシステム イメージを使用して Android エミュレータでアプリをテストしてください。次に、Android 4.3 プラットフォームに対してアプリをビルドし、 最新の API を提供します。
対象 API レベルのアップデート
Android 4.3 を搭載するデバイス向けにアプリを最適化するには、以下を行います。
targetSdkVersion
を
"18"
、Android 4.3 システム イメージにインストールし、
そのうえで変更したアップデートを公開できます
Android 4.3 の API を使用しながら旧バージョンも同時にサポートするには、minSdkVersion
でサポートされていない API を実行する前に、システムの API レベルをチェックする条件をコードに追加します。下位互換性の維持の詳細については、さまざまなプラットフォーム バージョンのサポートをご覧ください。
Android サポート ライブラリには、以前のバージョンのプラットフォームに新しい機能を実装できるさまざまな API も用意されています。
API レベルの仕組みについて詳しくは、API とは何かをご覧ください。 レベル
重要な動作変更
過去に Android にアプリを公開したことがある場合は、アプリが Android 4.3 の変更による影響を受ける場合があります。
アプリが暗黙的インテントを使用する場合
お客様のアプリは、制限付きプロファイル環境で誤動作する可能性があります。
制限付きプロファイル環境のユーザーは、
標準 Android アプリをすべて利用できます。たとえば、制限付きプロファイルでは、ウェブブラウザとカメラアプリが無効になっている場合があります。そのため、アプリでは、使用可能なアプリについて想定しない必要があります。Intent
を処理できるアプリがあるかどうかを確認せずに startActivity()
を呼び出すと、制限付きプロファイルでアプリがクラッシュする可能性があります。
暗黙的インテントを使用する場合は、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 を構築します。
BroadcastReceiver
の onReceive()
メソッドで、アプリが提供する制限ごとに 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
になります。このエクストラには、起動する Activity
クラスを示す Intent
を指定する必要があります(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
の実装が、接続に関するコールバックを受け取ります。
デバイスやその他のイベントと結合します。メソッドが新しい状態として STATE_CONNECTED
を渡した場合、onConnectionStateChange()
コールバック中にデバイスとの通信を開始できます。
デバイスで 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 では、MediaCodec
と MediaExtractor
の既存の API を使用して、ISO/IEC 23009-1 標準に準拠した独自の Dynamic Adaptive Streaming over HTTP(DASH)プレーヤーを簡単に作成できるようになりました。これらの 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
にアクセスします(通常はコンテンツのメタデータからアクセスします)。この 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()
を呼び出してエンコードを終了し、Surface
で release()
を呼び出します。
メディア多重化
新しい MediaMuxer
クラスを使用すると、1 つの音声ストリームと 1 つの動画ストリームの間で多重化できます。これらの API は、MediaExtractor
に対応するものとして機能します。
メディアの逆多重化(逆多重化)のために Android 4.2 で追加されたクラス。
サポートされている出力形式は、MediaMuxer.OutputFormat
で定義されています。現在、サポートされている出力形式は MP4 のみで、MediaMuxer
は一度に 1 つの音声ストリームまたは 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
- これには、リモコンが UI の進行状況を更新する必要があるときにメディアの現在の位置をリクエストするコールバック
onGetPlaybackPosition()
が含まれます。 RemoteControlClient.OnPlaybackPositionUpdateListener
- これには、コールバック
onPlaybackPositionUpdate()
が含まれます。 は、ユーザーが再生をスクラブしたときに、メディアの新しいタイムコードをアプリに通知します。 リモコン UI です。新しい位置で再生を更新したら、
setPlaybackState()
を呼び出して 新しい再生状態、位置、速度を変更できます。
これらのインターフェースを定義したら、それぞれ setOnGetPlaybackPositionListener()
と setPlaybackPositionUpdateListener()
を呼び出して RemoteControlClient
に設定できます。
グラフィック
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 ガイドをご覧ください。
ドローアブルの MIP マッピング
ビットマップやドローアブルのソースとして mipmap を使用すると、 さまざまな画像スケールが用意されています。 アニメーション中にスケーリングされる画像。
Android 4.2(API レベル 17)では、Bitmap
クラスでミップマップのサポートが追加されました。Android は、mipmap ソースを指定して setHasMipMap()
を有効にすると、Bitmap
の MIP 画像をスワップします。Android 4.3 では、mipmap アセットを指定してビットマップ リソース ファイルで android:mipMap
属性を設定するか、hasMipMap()
を呼び出すことで、BitmapDrawable
オブジェクトの mipmap を有効にできるようになりました。
ユーザー インターフェース
オーバーレイの表示
新しい 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();
光学境界レイアウト
ナインパッチの背景画像を含むビューで、ビューの「クリップ」境界ではなく、背景画像の「光学」境界に基づいて、隣接するビューと並べ替えるように指定できるようになりました。
たとえば、図 1 と図 2 は同じレイアウトを示していますが、図 1 のバージョンはクリップ境界(デフォルトの動作)を使用していますが、図 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
などそのため、アプリが Holo テーマ(Theme.Holo
、Theme.Holo.Light
など)を適用している場合は、android:layoutMode
属性を "opticalBounds"
に設定することで、すぐにメリットを得ることができます。
Draw 9-patch ツールで独自の NinePatch 画像の光学境界を指定するには、境界ピクセルを Ctrl キーを押しながらクリックします。
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"
を宣言して、アプリの向きを
現在の画面の向きが変わります。
回転アニメーション
WindowManager
の新しい rotationAnimation
フィールドを使用すると、システムが画面の向きを切り替える際に使用する 3 つのアニメーションのいずれかを選択できます。アニメーションには次の 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 を使用して連絡先の変更を確認するサンプルコードについては、SDK サンプルのダウンロードで入手できる ApiDemos サンプルをご覧ください。
ローカライズ
双方向テキストのサポートの改善
以前のバージョンの 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」は「Bay Street」の左側に配置する必要があります。この問題を解決するには、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
から unicodeWrap()
に TextDirectionHeuristic
定数のいずれかを渡して、別のヒューリスティックを指定できます。
注: これらの新しい API は、Android の以前のバージョンでも、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 以降、ユーザー補助サービスでユーザー補助機能を宣言する必要がある
メタデータ ファイルに追加する必要があります。メタデータ ファイルで機能がリクエストされていない場合、その機能は no-op になります。サービスのユーザー補助機能を宣言するには、AccessibilityServiceInfo
クラスのさまざまな「機能」定数に対応する XML 属性を使用する必要があります。
たとえば、サービスが 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 では、beginSection()
と endSection()
の 2 つの静的メソッドを持つ Trace
クラスが追加されました。これにより、systrace レポートに含めるコードブロックを定義できます。アプリ内でトレース可能なコードのセクションを作成すると、systrace ログでアプリ内での遅延が発生している場所をより詳細に分析できます。
Systrace ツールの使用方法については、Systrace を使用してディスプレイとパフォーマンスを分析するをご覧ください。
セキュリティ
アプリの秘密鍵の Android キーストア
Android では、KeyStore
機能に Android Key Store というカスタム Java セキュリティ プロバイダが用意されています。これにより、アプリでのみ参照および使用できる秘密鍵を生成して保存できます。Android Key Store を読み込むには、"AndroidKeyStore"
を KeyStore.getInstance()
に渡します。
Android Key Store でアプリの秘密認証情報を管理するには、KeyPairGenerator
で KeyPairGeneratorSpec
を使用して新しい鍵を生成します。最初
getInstance()
を呼び出して KeyPairGenerator
のインスタンスを取得します。次に、initialize()
を呼び出して、KeyPairGeneratorSpec.Builder
を使用して取得した KeyPairGeneratorSpec
のインスタンスを渡します。最後に、generateKeyPair()
を呼び出して KeyPair
を取得します。
ハードウェア認証情報ストレージ
Android は、KeyChain
のハードウェア格納型ストレージもサポートしました
鍵の抽出に使用不可にすることで、セキュリティが強化されます。つまり、鍵をハードウェア ベースのキーストア(セキュア エレメント、TPM、TrustZone)に格納すると、暗号オペレーションに使用できますが、秘密鍵マテリアルをエクスポートすることはできません。OS カーネルでも
アクセスできません。すべての Android 搭載デバイスが Google One VPN の
ハードウェア格納型ストレージが利用可能かどうかを実行時に確認するには、
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 差分レポート。