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 のスクリーンショットには、 レイアウト境界"有効にします。各ビューの赤い線は 青い線はクリップの境界、ピンクはマージンを示します。
![](https://developer.android.com/static/images/tools/clipbounds_2x.png?hl=ja)
図 1. クリップ境界を使用したレイアウト(デフォルト)。
![](https://developer.android.com/static/images/tools/opticalbounds_2x.png?hl=ja)
図 2. 光学境界を使用したレイアウト。
ビューを光学境界に基づいて配置するには、親レイアウトのいずれかで android:layoutMode
属性を "opticalBounds"
に設定します。例:
<LinearLayout android:layoutMode="opticalBounds" ... >
![](https://developer.android.com/static/images/tools/ninepatch_opticalbounds_2x.png?hl=ja)
図 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 差分レポート。