page.title=API の概要 page.keywords=プレビュー,sdk,互換性 page.tags=previewresources, androidm sdk.platform.apiLevel=22-mnc page.image=images/cards/card-api-overview_16-9_2x.png @jd:body
M Developer Preview では、ユーザーやアプリ開発者に Android プラットフォームの次期リリースの新機能をいち早く試していただくことができます。 このドキュメントでは、いくつかの注目すべき API の概要について説明します。
M Developer Preview は、Developer の早期導入者とテスターを対象としています。 是非 M Developer Preview を試してフィードバックをご提供ください。あなたのご意見が、Android フレームワークの方向性を決定する上で貴重な情報になります。
注意: M Developer Preview を使用したアプリは、Google Play ストアには公開しないでください。
注: このドキュメントには、まだ developer.android.com のリファレンス マテリアルにないクラスやメソッドが多数登場します。 このドキュメントでは、API エレメントは {@code code style} 形式で記載されています(ハイパーリンクなし)。 これらのエレメントに関する API ドキュメント(準備段階)については、プレビューのリファレンスをダウンロードしてください。
過去に Android にアプリを公開したことがある場合は、アプリがプラットフォームの変更による影響を受ける場合があります。
詳細については、Behavior Changes をご覧ください。
このプレビューでは、アプリのリンク機能を強化することで Android のインテント システムが向上しました。この機能では、所有するウェブドメインにアプリを関連付けることができます。 この関連付けに基づいて、プラットフォームが特定のウェブリンクの処理に使用するデフォルトのアプリを決めることができ、ユーザーにアプリを選択させる操作をスキップできます。この機能の実装方法については、 アプリのリンク機能をご覧ください。
システムで、アプリの自動フルデータ バックアップと復元を実行できるようになりました。この動作は、M Preview を対象としたアプリでデフォルトで有効になっています。追加のコードは必要ありません。 ユーザーが Google アカウントを削除すると、バックアップ データも削除されます。 この機能の仕組みとファイル システムでバックアップ対象を設定する方法については、 アプリの自動バックアップをご覧ください。
このプレビューでは、サポートされる端末での指紋スキャンを使用したユーザー認証や、端末のロック解除メカニズム(ロック画面のパスワードなど)を使って最後にユーザーが認証された時期の確認などを行える新しい API が提供されます。 これらの API は、Android キーストローク システムと共に使用します。
指紋スキャンでユーザーを認証するには、新しい {@code android.hardware.fingerprint.FingerprintManager} クラスのインスタンスを取得して、 {@code FingerprintManager.authenticate()} メソッドを呼び出します。アプリは、指紋センサー付きの、互換性のある端末上で実行している必要があります。 指紋認証フローのユーザー インターフェースをアプリに実装し、UI には標準の Android 指紋アイコンを使用する必要があります。Android 指紋アイコン({@code c_fp_40px.png})はサンプルアプリに含まれています。指紋認証を使用するアプリを複数開発する場合は、それぞれのアプリで個別にユーザーの指紋を認証する必要があります。
アプリでこの機能を使用するには、まずマニフェストに {@code USE_FINGERPRINT} パーミッションを追加する必要があります。
<uses-permission android:name="android.permission.USE_FINGERPRINT" />
アプリでの指紋認証の実装については、 指紋ダイアログのサンプルをご覧ください。
この機能をテストする場合は、次の手順を使用します。
adb -e emu finger touch <finger_id>
Windows では、{@code telnet 127.0.0.1 <emulator-id>}、 {@code finger touch <finger_id>} の順に実行する必要がある場合があります。
アプリでは、ユーザーがいつ、最後に端末のロックを解除したかに基づいて、ユーザーを認証できます。この機能によって、ユーザーがアプリ固有のパスワードを覚えたり、開発者が独自の認証ユーザー インターフェースを実装したりする必要性がなくなります。 アプリでこの機能を使用する場合は、ユーザー認証用の公開鍵か秘密鍵を実装する必要があります。
ユーザーが正常に認証された後、同じキーを再使用できるタイムアウト期間を設定するには、{@link javax.crypto.KeyGenerator} か {@link java.security.KeyPairGenerator} のセットアップ後に新しい {@code android.security.keystore.KeyGenParameterSpec.setUserAuthenticationValidityDurationSeconds()} メソッドを呼び出します。 現在、この機能は対象暗号化操作で動作します。
再認証ダイアログを過度に表示しないようにします。アプリでは、まず暗号オブジェクトを使用し、タイムアウトした場合は {@link android.app.KeyguardManager#createConfirmDeviceCredentialIntent(java.lang.CharSequence, java.lang.CharSequence) createConfirmDeviceCredentialIntent()} メソッドを使用してユーザーをアプリ内で再認証するようにします。
アプリでのこの機能の実装については、 資格情報の確認サンプルをご覧ください。
このプレビューでは、ユーザーが直感的にすばやく共有できるようにする API が提供されます。アプリで特定のアクティビティを起動するダイレクト シェアのターゲットを定義すると、それらのダイレクト シェアのターゲットは [共有] メニューに表示されるようになります。 この機能を使うと、他のアプリ内にある連絡先などのターゲットにコンテンツを共有できます。 たとえば、ダイレクト シェアのターゲットによって他のソーシャル ネットワーク アプリのアクティビティが起動し、そのアプリ内の特定の友人やコミュニティに直接コンテンツを共有できるようになります。
ダイレクト シェアのターゲットを有効にするには、まず
{@code android.service.} を拡張するクラスを定義する必要があります。
{@code chooser.ChooserTargetService} クラス。マニフェストで
{@code ChooserTargetService} を宣言します。その宣言内で、
{@code BIND_CHOOSER_TARGET_SERVICE} パーミッションと、
{@code SERVICE_INTERFACE} アクションを使ったインテント フィルタを指定します。
次の例は、マニフェストで {@code ChooserTargetService} を宣言する方法を示しています。
<service android:name=".ChooserTargetService" android:label="@string/service_name" android:permission="android.permission.BIND_CHOOSER_TARGET_SERVICE"> <intent-filter> <action android:name="android.service.chooser.ChooserTargetService" /> </intent-filter> </service>
{@code ChooserTargetService} に公開するアクティビティごとに、 {@code "android.service.chooser.chooser_target_service"} という名前の {@code <meta-data>} 要素をアプリのマニフェストに追加します。
<activity android:name=".MyShareActivity” android:label="@string/share_activity_label"> <intent-filter> <action android:name="android.intent.action.SEND" /> </intent-filter> <meta-data android:name="android.service.chooser.chooser_target_service" android:value=".ChooserTargetService" /> </activity>
このプレビューでは、音声アクションと共に使用することでアプリに対話形式の音声操作をビルドできる新しい音声インタラクション API が提供されます。 {@code android.app.Activity.isVoiceInteraction()} メソッドを呼び出して、アクティビティが音声アクションへの応答として開始されたかどうかを確認します。 音声アクションへの応答であった場合、アプリで {@code android.app.VoiceInteractor} クラスを使用してユーザーに音声の確認や、オプションのリストからの選択などを要求できます。 音声アクションの実装の詳細については、 音声アクションの開発者サイトをご覧ください。
このプレビューでは、アシスタントを介してユーザーがアプリを操作できる新しい方法が用意されています。この機能を使用するには、ユーザーが現在のコンテキストを使うようアシスタントを有効にする必要があります。 有効にすると、ホーム ボタンを長押しすることで、すべてのアプリ内でアシスタントを呼び出すことができます。
{@link android.view.WindowManager.LayoutParams#FLAG_SECURE} フラグを設定すると、アプリが現在のコンテキストをアシスタントと共有しないようにできます。新しい {@code android.app.Activity.AssistContent} クラスを使用すると、プラットフォームがアシスタントに渡す標準的な情報セットの他に、アプリで追加の情報を共有できます。
アプリから追加のコンテキストをアシスタントに提供するには、次の手順を使用します。
このプレビューでは、通知に関して次のような API の変更点が追加されています。
このプレビューでは、Bluetooth スタイラスを使用したユーザー入力のサポートが強化されました。互換性のある Bluetooth スタイラスと電話やタブレットをペアリングして接続できます。 接続されている間、タッチスクリーンからの位置情報とスタイラスからの筆圧やボタン情報を合わせることで、タッチスクリーン単独の場合よりも表現の幅が大きく広がります。 新しい {@code View.onStylusButtonPressListener} コールバックと {@code GestureDetector.OnStylusButtonPressListener} コールバックをアクティビティに登録すると、スタイラスのボタンが押されたことをアプリがリッスンし、次のアクションを実行できるようになります。
スタイラスのボタン操作を検出するには、{@link android.view.MotionEvent} メソッドと定数を使用します。
アプリで Bluetooth Low Energy スキャンを実行する場合は、新しい {@code android.bluetooth.le.ScanSettings.Builder.setCallbackType()} メソッドを使って、設定された {@link android.bluetooth.le.ScanFilter} に一致する宣伝パケットが最初に見つかったときと、それが長期間見つからない場合に通知する目的でのみコールバックが必要であると指定できます。 このスキャン アプローチは、以前のプラットフォーム バージョンで提供されていたものよりもはるかに効率的です。
このプレビューでは、Nexus 6 と Nexus 9 端末のアクセス ポイント2.0 Release 1 仕様のサポートが追加されました。アクセス ポイント 2.0 の資格情報をアプリに提供するには、 {@code setPlmn()} や {@code setRealm()} などの {@link android.net.wifi.WifiEnterpriseConfig} クラスの新しいメソッドを使用します。 {@link android.net.wifi.WifiConfiguration} オブジェクトで、 {@link android.net.wifi.WifiConfiguration#FQDN} フィールドと {@code providerFriendlyName} フィールドを設定できます。新しい {@code ScanResult.PasspointNetwork} プロパティは、検出されたネットワークがアクセス ポイント 2.0 のアクセス ポイントを表しているかどうかを示します。
互換性のあるハードウェアで、ディスプレイの解像度を 4K レンダリングにアップグレードするようアプリから要求できるようになりました。 現在の物理的解像度を照会するには、新しい {@code android.view.Display.Mode} API を使用します。UI が低い論理的解像度で描画されていて、より高い物理的解像度にアップスケールされた場合は、 {@code Display.Mode.getPhysicalWidth()} メソッドが返す物理的解像度が {@link android.view.Display#getSize(android.graphics.Point) getSize()} で報告される論理的解像度と異なる場合があります。
アプリ ウィンドウの {@code WindowManager.LayoutParams.preferredDisplayModeId} プロパティを設定することで、アプリの実行時に物理的解像度を変更するようシステムに要求できます。この機能は、4K ディスプレイの解像度に切り替えたい場合に便利です。 4K ディスプレイ モード中、UI は引き続き元の解像度(1080p など)で表示され、4K にアップスケールされますが、 {@link android.view.SurfaceView} オブジェクトではコンテンツをネイティブの解像度で表示する場合があります。
M Preview を実行する端末で、テーマの属性が {@link android.content.res.ColorStateList} でサポートされるようになりました。 {@link android.content.res.Resources#getColorStateList(int) getColorStateList()} メソッドと {@link android.content.res.Resources#getColor(int) getColor()} メソッドは廃止されました。これらの API を呼び出す場合は、代わりに新しい {@code Context.getColorStateList()} メソッドか {@code Context.getColor()} メソッドを呼び出します。 これらのメソッドは、{@link android.support.v4.content.ContextCompat} の v4 appcompat ライブラリにもあります。
このプレビューでは、次のように Android でのオーディオ処理が改善されました。
このプレビューでは、ビデオ処理の API に次のような新機能が追加されました。
このプレビューでは、カメラのフラッシュやカメラによる画像の再処理にアクセスするための新しい API が用意されています。
カメラ端末にフラッシュ ユニットが付属している場合は、{@code CameraManager.setTorchMode()} メソッドを呼び出すことで、カメラ端末を開かずにフラッシュ ユニットのタッチモードのオン/オフを切り替えることができます。 アプリには、フラッシュ ユニットやカメラ端末のフラッシュの独占所有権はありません。 トーチモードは、カメラ端末が利用不可になったときや、トーチを付けている他のカメラリソースが利用不可になったときにオフになり、利用できなくなります。 他のアプリでも {@code setTorchMode()} を呼び出してトーチモードをオフにできます。 最後にトーチモードをオンにしたアプリが閉じられると、トーチモードはオフになります。
{@code CameraManager.registerTorchCallback()} メソッドを呼び出すことで、トーチモードの状態に関する通知を受けるようコールバックを登録できます。コールバックを初めて登録したときに、現在検知されているすべてのフラッシュ ユニット付きのカメラ端末のトーチモードの状態が即座に呼び出されます。 トーチモードが正常にオン/オフされると、 {@code CameraManager.TorchCallback.onTorchModeChanged()} メソッドが呼び出されます。
{@link android.hardware.camera2 Camera2} API は、YUV とプライベートな不透明形式の画像の再処理をサポートするよう拡張されました。 アプリは、再処理機能が利用可能かどうかを {@code CameraCharacteristics.REQUEST_AVAILABLE_CAPABILITIES} 経由で確認します。 端末が再処理をサポートしている場合は、 {@code CameraDevice.createReprocessableCaptureSession()} を呼び出して再処理可能なカメラ撮影セッションを作成し、入力バッファの再処理の要求を作成できます。
入力バッファのフローをカメラの再処理入力に接続するには、{@code ImageWriter} クラスを使用します。 空のバッファを取得するには、次のプログラミング モデルを使用します。
{@code ImageWriter} オブジェクトを {@code android.graphics.ImageFormat.PRIVATE} 画像と共に使用する場合、アプリから直接画像データにアクセスすることはできません。 代わりに、{@code ImageWriter.queueInputImage()} メソッドをバッファコピーなしで呼び出して、{@code ImageFormat.PRIVATE} 画像を直接 {@code ImageWriter} に渡します。
{@code ImageReader} クラスで {@code android.graphics.ImageFormat.PRIVATE} 形式の画像ストリームがサポートされるようになりました。 これにより、アプリが {@code ImageReader} 出力画像の循環的な画像のキューを維持でき、1 つ以上の画像を選択して、それらをカメラの再処理用に {@code ImageWriter} に送ることができます。
このプレビューには、次のような Android for Work 用の新しい API が含まれています。
さらに、Google Play サービスでアプリの制限を設定することで、デバイス オーナーは FRP のロック解除用の別の Google アカウントを指定して、端末でアクティベートされたアカウントを置き換えることができます。
プロファイルやデバイス オーナーは、 {@code DevicePolicyManager.setPermissionPolicy()} を使用するすべてのアプリケーションのすべての実行時の要求に対するパーミッション ポリシーを設定でき、通常のとおりユーザーにパーミッションを付与するよう要求する、自動的に付与する、パーミッションをサイレントに拒否する、のいずれかを行うことができます。 後者のポリシーが設定されている場合、ユーザーはプロファイルやデバイス オーナーによって選択された内容を [設定] にあるアプリのパーミッション画面で修正できません。
M Developer Preview のすべての API の変更点の詳細については、API Differences Report をご覧ください。