図 1. 分割画面モードで実行されているアプリ
Android N は現在も開発中ですが、N Developer Preview の一部として Android N を試用できます。 以下のセクションでは、デベロッパー向けの新しい機能の一部を紹介しています。
動作の変更点を確認して、プラットフォームの変更がアプリに影響を及ぼす可能性のある領域について把握してください。また、デベロッパー ガイドを参照して主な機能について詳しく学習し、API リファレンスをダウンロードして、新しい API の詳細を理解してください。
Android N では、多くのユーザーから求められていたマルチタスク機能がプラットフォームに新しく導入されました。つまり、マルチ ウィンドウがサポートされるようになりました。
ユーザーは同時に 2 つのアプリを画面に開くことができます。
図 1. 分割画面モードで実行されているアプリ
特にタブレットや大画面の端末では、マルチ ウィンドウのサポートにより、ユーザーを引き付ける新しい方法が提供されます。 アプリでドラッグ アンド ドロップを有効にすると、ユーザーはアプリとの間でコンテンツを簡単にドラッグすることができるので、快適な使い心地を実現することができます。
マルチ ウィンドウのサポートをアプリに追加して、マルチ ウィンドウ ディスプレイを処理する方法を設定するのは簡単です。 たとえば、アクティビティの最小許容ディメンションを指定すると、ユーザーはアクティビティをそのサイズより小さく変更できなくなります。 また、アプリに対してマルチ ウィンドウ ディスプレイを無効にし、アプリを全画面モードのみで表示することもできます。
詳細については、マルチ ウィンドウのサポートに関するデベロッパー向けドキュメントをご覧ください。
Android N では、通知が再設計されており、さらに使いやすくなっています。 次のような点が変更されました。
MessageStyle クラスを使用して、通知に関連付けられているさらに多くのユーザー インターフェース ラベルをカスタマイズできます。
メッセージ、会話、タイトル、コンテンツ ビューを設定できます。
図 2. バンドル通知とダイレクト リプライ
以上の新しい機能を実装する方法の詳細については、通知に関するガイドをご覧ください。
Android N では、コード プロファイリングにも対応した Just in Time（JIT）コンパイラーが ART に追加されており、Android アプリを実行するときのパフォーマンスが向上しています。 JIT コンパイラーは、ART で現在使用されている Ahead of Time（AOT）コンパイラーを補完するものであり、ランタイム パフォーマンスの向上、ストレージ スペースの削減、アプリとシステムのアップデートの高速化に貢献します。
プロファイルに基づいたコンパイルを使用すると、アプリの実際の使用方法や端末上での状態に応じて、ART が各アプリの AOT / JIT コンパイルを管理します。 たとえば、ART は各アプリのホット メソッドのプロファイルを維持し、これらのメソッドをプリコンパイルしてキャッシュに保存することにより、パフォーマンスを最適化します。 また、アプリの他の部分は、実際に使用されるときまでコンパイルされません。
プロファイルに基づいたコンパイルは、アプリの主要部分のパフォーマンスを向上させ、関連するバイナリなど、アプリの全体的な RAM 使用量を削減します。 この機能は、メモリが少ない端末で特に重要です。
ART は、端末の電池への影響が最小限になるようにプロファイルに基づいたコンパイルを管理します。 端末がアイドル状態および充電中のときにのみ、プリコンパイルが事前に実行されるため、時間と電池が節約できます。
ART の JIT コンパイラーの最も明確な利点の 1 つは、アプリのインストールとシステム アップデートの速度です。 Android 6.0 では最適化とインストールの実行に数分かかっていたサイズの大きいアプリでも、数秒でインストールできるようになりました。 最適化のステップが不要になったため、システム アップデートも高速化されています。
Android 6.0 では Doze システムモードが導入されています。これにより、端末が机に置かれているときや引き出しに収められているときなどのアイドル時にアプリの CPU とネットワーク通信の実行を保留し、電池を節約します。
Android N では Doze が改良され、外出中でも電池を節約できるようになっています。画面をしばらくオフにしたり端末を電源から抜いたりすると、Doze により、通常の CPU およびネットワーク制限の一部がアプリに適用されます。つまり、端末をポケットに入れて持ち歩いているときでも電池を節約できます。
図 3. Doze により、端末が静止していないときでも制限が適用され、電池の寿命が延長される
端末が電池で動作しているときに画面をしばらくオフにすると、Doze はネットワーク アクセスを制限し、ジョブと同期を保留します。 アプリはメンテナンス ウィンドウと呼ばれる短い時間にネットワークにアクセスしたり、保留中のジョブや同期を実行したりします。 画面をオンにするか、端末を電源に接続すると、端末の Doze モードは解除されます。
電池で動作している端末が再び静止状態になり、画面がしばらくオフになると、Doze は完全な CPU およびネットワーク制限を {@link android.os.PowerManager.WakeLock}、{@link android.app.AlarmManager} アラーム、GPS / Wi-Fi スキャンに適用します。
アプリを Doze に対応させるためのベスト プラクティスは端末を持ち歩いているかどうかには関係ありません。そのため、Doze が適切に処理されるようにアプリを既にアップデートしている場合は、追加の対応は必要ありません。 そうでない場合は、アプリの Doze 対応を行ってください。
Project Svelte は、Android エコシステムのさまざまな端末でシステムやアプリによる RAM の使用を最小限にする取り組みです。 Android N での Project Svelte は、アプリをバックグラウンドで実行する方法を最適化することに重点を置いています。
ほとんどのアプリでは、バックグラウンド処理が非常に重要になります。バックグラウンド処理を適切に実行すると、状況に応じて高速に実行できるなどユーザー エクスペリエンスが大幅に向上します。バックグラウンド処理が不適切な場合は、RAM（と電池）が必要以上に消費され、他のアプリのシステム パフォーマンスに影響を及ぼす可能性があります。
Android 5.0 以降では、ユーザーに適した方法でバックグラウンド処理を実行する {@link android.app.job.JobScheduler} が推奨されています。 これによって、メモリ、電源、接続の状態に基づいてシステムを最適化しながら、アプリでジョブをスケジュールできます。 JobScheduler はシンプルな制御を提供するため、すべてのアプリで JobScheduler を使用することが効果的です。
もう 1 つの適切な選択肢は、Google Play サービスの一部である GCMNetworkManager です。この機能も同様のジョブ スケジュール機能を提供しますが、こちらは以前のバージョンの Android とも互換性があります。
さらに多くのユースケースに対応するために、JobScheduler と GCMNetworkManager の拡張は継続されています。たとえば、Android N では、コンテンツ プロバイダの変更に基づいてバックグラウンド処理をスケジュールできるようになりました。
また、特にメモリの少ない端末でシステム パフォーマンスを低下させる可能性のある一部の古いパターンの廃止も開始されています。
一般的に使用される暗黙的なブロードキャストである
{@link android.net.ConnectivityManager#CONNECTIVITY_ACTION}、{@link
android.hardware.Camera#ACTION_NEW_PICTURE}、{@link
android.hardware.Camera#ACTION_NEW_VIDEO} は複数のアプリのバックグラウンド処理を同時に起動するので、メモリと電池に負荷をかける可能性があります。そのため、Android N では、この 3 つのブロードキャストが削除されています。
アプリがこれらのブロードキャストを受信する場合は、N Developer Preview を使用して、JobScheduler とそれに関連する API に移行してください。
詳細については、バックグラウンド処理の最適化に関するドキュメントをご覧ください。
図 4. [Settings] でのデータセーバー
一般的に、モバイル端末のライフサイクル全体では、モバイルデータ通信プランのコストが端末自体のコストを上回ります。 多くのユーザーにとって、モバイルデータ通信は、節約する必要のある高価なリソースです。
Android N では、ローミング、課金サイクルの終了近く、または短期間のデータパックであるかどうかに関係なく、アプリによるモバイルデータ通信の使用を削減する新しいシステム サービスであるデータセーバー モードが導入されています。 データセーバーを使用すると、アプリによるモバイルデータ通信の使用方法をユーザーが制御できます。また、デベロッパーは、データセーバーがオンのときに、より効率よく通信するサービスを提供できるようになります。
ユーザーが [Settings] でデータセーバーを有効にし、端末が従量制課金ネットワークに接続されている場合、システムは、ストリーミングのビットレートを制限したり、画質を低下させたり、オプティミスティックなプレキャッシングを保留したりすることにより、バックグラウンドでのデータ使用をブロックし、フォアグラウンドでのデータ使用をなるべく抑えるようにアプリに指示します。 ユーザーは特定のアプリをホワイトリストに登録することにより、データセーバーがオンになっているときでも、バックグラウンドで従量制データ通信を使用できます。
Android N は {@link android.net.ConnectivityManager} を拡張することで、ユーザーのデータセーバー設定を取得する方法と、設定の変更を監視する方法を提供しています。 すべてのアプリは、ユーザーがデータセーバーを有効にしているかどうかを確認し、フォアグラウンドおよびバックグラウンドでのデータ使用を制限する必要があります。
Android N では、新しい 3D レンダリング API である Vulkan™ がプラットフォームに統合されています。OpenGL™ ES と同様に、Vulkan は Khronos グループによって管理されている 3D グラフィックおよびレンダリングのオープン スタンダードです。
Vulkan は、ドライバの CPU オーバーヘッドを最小化するため、およびアプリケーションが GPU の動作をより直接的に制御できるように設計されています。 また、Vulkan は、複数のスレッドが作業を実行できるようにする（コマンド バッファの作成を同時に行うなど）ことによって、より優れた並列処理が可能です。
Vulkan 開発ツールおよびライブラリは、Android NDK に含まれています。次のようなものが含まれます。
Vulkan は、Nexus 5X、Nexus 6P、Nexus Player などの Vulkan 対応ハードウェアを備えた端末上のアプリでのみ利用できます。 Vulkan を可能な限りより多くの端末に導入するためにパートナーと緊密に協力し合っています。
詳細については、API ドキュメントをご覧ください。
図 5. 通知シェードにあるクイック設定タイル
クイック設定は、通知シェードから主要な設定とアクションを直接公開するための一般的で簡単な方法です。 Android N では、クイック設定の範囲が拡大され、さらに使いやすく便利な機能になっています。
クイック設定タイル用のスペースが広くなったので、ユーザーは、左または右にスワイプして、ページ分割された表示領域でこれらのタイルにアクセスできます。 また、ユーザーは、表示するクイック設定タイルとその表示場所を制御できるようになっています。ユーザーはタイルをドラッグ アンド ドロップして、追加または移動できます。
Android N では、デベロッパーが独自のクイック設定タイルを定義できる新しい API が追加されており、ユーザーはこの API を通じて、アプリの主なコントロールとアクションに簡単にアクセスできます。
クイック設定タイルは、緊急に必要な、または頻繁に使用されるコントロールやアクション用に用意されたものであり、アプリを起動するためのショートカットとして使用するべきではありません。
タイルの定義が完了すると、ユーザーにタイルを公開できるようになります。ユーザーはタイルをドラッグ アンド ドロップするだけで、クイック設定にタイルを追加できます。
アプリタイルを作成する方法については、ダウンロード可能な API リファレンスに掲載されている android.service.quicksettings.Tile のドキュメントをご覧ください。
Android N では、プラットフォームで電話番号のブロックがサポートされており、サービス プロバイダがブロックされた電話番号のリストを保持するためのフレームワーク API が提供されています。 デフォルトの SMS アプリ、デフォルトの電話アプリ、携帯通信会社アプリは、ブロックされた電話番号のリストを読み込んだり、このリストに書き込んだりできます。 その他のアプリはこのリストにアクセスできません。
Android では、電話番号のブロックをプラットフォームの標準の機能にすることにより、幅広い端末で電話番号をブロックできるようにする一貫した方法がアプリに提供されています。 その他にアプリは次のような機能も利用できます。
また、Android に携帯通信会社のアプリが組み込まれていると、携帯通信会社は端末上のブロックリストを読み込んで迷惑な電話やテキスト メッセージをサービス側でブロックできます。これによって、VOIP エンドポイントや転送電話などいかなる媒体を介しても、ブロックされた番号はユーザーに到達できなくなります。
詳細については、ダウンロード可能な API リファレンスの android.provider.BlockedNumberContract をご覧ください。
Android N では、デフォルトの電話アプリで着信をスクリーニングできます。新しい CallScreeningService を実装することによって、電話アプリは着信をスクリーニングします。これにより、電話アプリは着信する電話の {@link android.telecom.Call.Details Call.Details} に基づいて次のようなアクションを実行できます。
詳細については、ダウンロード可能な API リファレンスの android.telecom.CallScreeningService をご覧ください。
Android N では、[Settings] でマルチロケールを選択できるようになり、複数言語を使用するユーザーへのサポートが強化されました。 アプリで新しい API を使用して、ユーザーが選択したロケールを取得すると、複数のロケールを設定しているユーザーに対してより洗練されたユーザー エクスペリエンスを提供できます。たとえば、検索結果を複数の言語で表示したり、ユーザーが理解している言語のウェブページでは翻訳の提案を行わないようにしたりすることが可能になります。
また、Android N では、マルチロケールのサポートに加えて、ユーザーが利用できる言語が追加されています。 英語、スペイン語、フランス語、アラビア語などの一般的な言語に対して、それぞれ 25 以上のバリエーションが提供されます。 100 以上の新しい言語も部分的にサポートされています。
アプリは、LocaleList.GetDefault() を呼び出すことにより、ユーザーが設定したロケールのリストを取得できます。
Android N では、ロケール数の増加に対応するために、リソースを解決する方法が変更されています。
この新しいリソース解決ロジックでアプリが想定どおりに動作することをテストおよび確認してください。
新しいリソース解決動作と順守する必要のあるベスト プラクティスの詳細については、複数言語のサポートをご覧ください。
Android N では、肌色の異なる絵文字や異体字セレクターのサポートなど、絵文字の追加と絵文字関連機能が導入されています。 アプリで絵文字をサポートする場合は、以下のガイドラインに従い、これらの絵文字関連機能を利用します。
Android N では、Android フレームワーク内で ICU4J API のサブセットが提供されており、android.icu パッケージにあります。
移行は簡単で、ほとんどの場合、名前空間を com.java.icu から android.icu に変更するだけです。
アプリで ICU4J バンドルを既に使用している場合は、Android フレームワークで提供されている android.icu API に移行すると、APK サイズを大幅に削減できます。
Android ICU4J API の詳細については、ICU4J のサポートをご覧ください。
Android N では、OpenGL ES 3.2 用の以下のようなフレームワーク インターフェースとプラットフォーム サポートが追加されています。
EXT_texture_sRGB_decode を除く Android エクステンション パック（AEP）のすべての拡張機能
Android N の OpenGL ES 3.2 用のフレームワーク API は、GLES32 クラスで提供されます。
OpenGL ES 3.2 を使用する場合、<uses-feature> タグと android:glEsVersion 属性を使用してマニフェスト ファイルで要件を宣言する必要があります。
端末でサポートされる OpenGL ES のバージョンを実行時に確認する方法など、OpenGL ES の使用方法については、OpenGL ES API ガイドをご覧ください。
Android N では、新しい recording API を介して Android TV 入力サービスからコンテンツを録画して再生する機能が追加されています。 TV 入力サービスでは、録画できるチャンネル データや録画したセッションを保存する方法の制御、ユーザーによる録画されたコンテンツの操作の管理を行うことができます。このサービスは、既存の time-shifting API を使用して構築されています。
詳細については、Android TV Recording API をご覧ください。
Android for Work は、Android N を実行している端末に多くの新しい機能と API を追加するものです。主要な機能の一部を以下に紹介します。変更点の完全なリストについては、Android for Work のアップデートをご覧ください。
N SDK を対象としているプロファイル オーナーは、仕事用プロファイルで実行しているアプリで個別にセキュリティ確認を行うよう指定することができます。
ユーザーが仕事用アプリを開こうとすると、仕事用プロファイル用のセキュリティ確認画面が表示されます。
セキュリティの確認に成功すると、仕事用プロファイルのロックが解除され、必要に応じて暗号化も解除されます。
プロファイル オーナーは、ACTION_SET_NEW_PASSWORD でユーザーに仕事用プロファイル用のセキュリティ確認を設定するように求めたり、ACTION_SET_NEW_PARENT_PROFILE_PASSWORD でユーザーに端末のロックを設定するように求めたりします。
プロファイル オーナーは、setPasswordQuality()、setPasswordMinimumLength()、および関連するメソッドを使用して、仕事用プロファイル用のセキュリティ確認に個別のパスコード ポリシー（PIN に必要な長さや、指紋によるプロファイルのロック解除が可能かどうかなど）を設定できます。
また、新しい getParentProfileInstance() メソッドが返す DevicePolicyManager インスタンスを使用して端末のロックを設定できます。
さらに、新しい setOrganizationColor() メソッドおよび setOrganizationName() メソッドを使用して仕事用プロファイル用のセキュリティ確認画面をカスタマイズすることができます。
ユーザーは、仕事用プロファイルがある端末でワークモードを切り替えることができます。ワークモードがオフになると、管理されているユーザーが一時的にシャットダウンされ、仕事用プロファイルのアプリ、バックグラウンドでの同期、通知が無効になります。 これには、プロファイル オーナーのアプリが含まれます。 また、ワークモードがオフになると、仕事用アプリを起動できないことをユーザーに示すステータス アイコンが表示されたままになります。 ランチャーは、仕事用アプリとウィジェットにアクセスできないことを示します。
デバイス オーナーとプロファイル オーナーは、指定した VPN を介して仕事用アプリが常時接続するように設定できます。 端末が起動すると、システムは VPN を自動的に開始します。
setAlwaysOnVpnPackage() と getAlwaysOnVpnPackage() は新しい DevicePolicyManager のメソッドです。
システムがアプリの介入なしに VPN サービスを直接バインドするため、Always on VPN の新しいエンドポイントは VPN クライアント側で処理する必要があります。
以前と同じように、システムへのサービスの通知はインテント フィルタのマッチング アクション android.net.VpnService で行います。
プライマリ ユーザーは、[Settings] > [More] > [Vpn] から、VPNService のメソッドを実装した Always on VPN クライアントを手動で設定することもできます。
アプリでは、コーポレート・カラーやロゴを含むプロファイル オーナーとデバイス オーナーのプロビジョニング フローをカスタマイズできます。DevicePolicyManager.EXTRA_PROVISIONING_MAIN_COLOR はフローカラーをカスタマイズします。DevicePolicyManager.EXTRA_PROVISIONING_LOGO_URI は、コーポレート ロゴを含むフローをカスタマイズします。
Android N では、新しい端末のセットアップのオープニング画面に [Vision Settings] が直接表示されます。 これにより、ユーザーは、ズーム操作、フォントサイズ、ディスプレイ サイズ、TalkBack など、端末のユーザー補助機能を簡単に見つけて設定できるようになっています。
このようなユーザー補助機能が目立つ場所に配置されたため、ユーザーがこれらの機能を有効にしてアプリを試用する可能性が高まりました。 これらの設定を有効にして、アプリを事前にテストするようにしてください。 これらの設定は、[Settings] > [Accessibility] で有効にできます。
Android N では、ユーザー補助機能サービスにより、運動障害のあるユーザーが画面をタップすることを支援できます。 この新しい API を使用すると、顔追跡、視線追跡、ポイント スキャンなどの機能を備えたサービスを構築して、これらのユーザーのニーズに対応することができます。
詳細については、ダウンロード可能な API リファレンスの android.accessibilityservice.GestureDescription をご覧ください。
ダイレクト ブートは端末のスタートアップ時間を短縮し、予期しない再起動後でも、登録されたアプリの一部の機能が使用できるようにします。たとえば、ユーザーの就寝中に暗号化された端末が再起動した場合でも、登録したアラーム、メッセージ、電話の着信をユーザーに通常どおり通知することができます。 また、再起動後にユーザー補助機能サービスをすぐに使用することもできます。
ダイレクト ブートでは、Android N のファイルベースの暗号化を活用して、システムとアプリのデータに対してきめ細かい暗号化ポリシーを有効にします。システムは、一部のシステムデータと明示的に登録されたアプリデータに端末暗号化ストアを使用します。 デフォルトでは、他のすべてのシステムデータ、ユーザーデータ、アプリ、アプリデータには、認証情報暗号化ストアが使用されます。
システムは起動時に端末暗号化データのみにアクセスできる制限モードになります。この状態では、アプリやデータへの一般的なアクセスは許可されません。このモードで実行する必要のあるコンポーネントがある場合、マニフェストにフラグを設定することでコンポーネントを登録できます。
再起動後、システムは、LOCKED_BOOT_COMPLETED インテントをブロードキャストすることにより、登録済みのコンポーネントをアクティベートします。
システムは、ロック解除する前に、登録済みの端末暗号化アプリデータを利用できるようにします。
他のすべてのデータは、ユーザーがロック画面の認証情報を確認して暗号化を解除するまで利用できません。
ハードウェアがサポートするキーストアは、Android 端末で暗号化キーを作成、格納、使用するためのより安全な方法を提供します。 このキーストアは、Linux カーネル、Android の潜在的な脆弱性、ルート権限を取得された端末からの抽出からキーを保護します。
ハードウェアがサポートするキーストアの使用をさらに簡単かつ安全にするために、Android N では、キーの構成証明が導入されています。 アプリや別の端末は、キーの構成証明を使用して RSA または EC キーペアがハードウェアでサポートされているかどうか、キーペアのプロパティはどのようなものか、使用方法や有効性にどのような制限が適用されるかを積極的に確認することができます。
アプリや別の端末のサービスは、有効な構成証明キーによって署名された X.509 構成証明書を通じて、キーペアについての情報をリクエストできます。 この構成証明キーは、出荷前に端末のハードウェアがサポートするキーストアに挿入される ECDSA 署名キーです。したがって、有効な構成証明キーによって署名される構成証明書により、ハードウェアがサポートするキーストアの存在に加えて、そのキーストアのキーペアの詳細が確認されます。
端末が Android の安全な公式ファクトリー イメージを使用していることを確認するために、キーの構成証明では、端末のブートローダーが以下の情報を Trusted Execution Environment（TEE）に提供することが要求されます。
ハードウェアがサポートするキーストアの機能の詳細については、ハードウェアがサポートするキーストアに関するガイドをご覧ください。
Android N では、キーの構成証明に加えて、指紋にバインドされたキーが導入されています。このキーは、指紋を登録しても無効になることはありません。
Android N では、エラーが発生しやすいプログラムによる従来の API（X509TrustManager など）ではなく、宣言型のネットワーク セキュリティ構成を使用することにより、コードを変更することなく、セキュアな（HTTPS、TLS）接続の動作をアプリで安全にカスタマイズできます。
以下の機能がサポートされます。
詳細については、ネットワーク セキュリティ構成をご覧ください。
既定では、Android N 用アプリは、システムが提供する証明書のみを信頼し、ユーザーが追加した証明機関（CA）を信頼しません。 ユーザーが追加した CA を信頼する必要がある Android N 向けのアプリは、ネットワーク セキュリティ構成を使用して、ユーザー CA を信頼する方法を指定する必要があります。
Android N では、APK 署名スキーム v2 というアプリのインストール時間を高速化したり、APK ファイルに無許可の変更が行われないようにしたりする新しいアプリ署名スキームが導入されています。 既定では、Android Studio 2.2 と Gradle 2.2 用の Android プラグインで APK 署名スキーム v2 と従来の署名スキーム（JAR 署名を使用する）の両方を使用してアプリに署名します。
APK 署名スキーム v2 をアプリに適用することをお勧めしますが、この新しいスキームは必須ではありません。
APK 署名スキーム v2 を使用するときにアプリが正しくビルドされていない場合は、この新しいスキームを無効にできます。
無効化プロセスにより、Android Studio 2.2 と Gradle 2.2 用の Android プラグインでアプリへの署名に従来の署名スキームのみが使用されるようになります。
従来のスキームのみを使用して署名するには、モジュール レベルの build.gradle ファイルを開き、v2SigningEnabled false という行をリリース用署名構成に追加します。
android {
...
defaultConfig { ... }
signingConfigs {
release {
storeFile file("myreleasekey.keystore")
storePassword "password"
keyAlias "MyReleaseKey"
keyPassword "password"
v2SigningEnabled false
}
}
}
警告: APK 署名スキーム v2 を使用してアプリに署名し、さらにアプリに変更を加える場合、アプリの署名は無効になります。
そのため、APK 署名スキーム v2 を使用してアプリに署名する場合は、署名後ではなく署名前に zipalign などのツールを使用します。
詳細については、Android Studio でアプリに署名する方法や、Gradle 用の Android プラグインを使用してアプリへの署名用ビルドファイルを構成する方法を説明する Android Studio ドキュメントをご覧ください。
Android N では、アプリで新しい API を使用して、SD カードなどのリムーバブル メディア上のディレクトリといった特定の外部ストレージ ディレクトリへのアクセスをリクエストできるようになりました。
この新しい API は、アプリが Pictures ディレクトリなどの標準の外部ストレージ ディレクトリにアクセスする方法を大幅に簡略化します。
写真アプリなどのアプリでは、READ_EXTERNAL_STORAGE の代わりに、この API ですべてのストレージ ディレクトリやストレージ アクセス フレームワークにアクセスできるため、ユーザーはそのディレクトリに移動できます。
また、この新しい API は、ユーザーがアプリに外部ストレージへのアクセスを付与するステップを簡素化します。 この新しい API を使用する場合、アプリがどのディレクトリへのアクセス許可を求めているかをわかりやすく説明するシンプルな UI が使用されます。
詳細については、特定のディレクトリへのアクセスに関するデベロッパー向けドキュメントをご覧ください。
Android N では、ユーザーは Alt キー + / キーを同時に押してキーボード ショートカット画面をトリガーできます。この画面には、システムとアプリから使用できるすべてのショートカットが表示されます。
これらは使用可能な場合はアプリのメニューから自動的に取得されますが、デベロッパーは独自に微調整したショートカットのリストを画面に表示することもできます。
ダウンロード可能な API リファレンスで説明するように、新しい Activity.onProvideKeyboardShortcuts() メソッドをオーバーライドしてこれを実行することができます。
アプリ内のどこででもキーボード ショートカット ヘルパーをトリガーするには、関連アクティビティの {@code Activity.requestKeyboardShortcutsHelper()} を呼び出します。
長時間実行するアプリではパフォーマンスが大幅に変動する可能性があります。これは、端末のコンポーネントがその温度制限に達するとシステムによりシステムオンチップ エンジンが抑制されるためです。 この変動は、高性能で長時間実行するアプリを作成するアプリのデベロッパーの移動目標となります。
これらの制限に対処するために、Android N には、パフォーマンス維持モードのサポートが含まれており、OEM は長時間実行するアプリに端末のパフォーマンスに関するヒントを提供することができます。 アプリのデベロッパーはこれらのヒントを使用して、長時間にわたる予測可能な一定レベルの端末のパフォーマンスに合わせてアプリを調整できます。
アプリのデベロッパーが N Developer Preview でこの新しい API を試すことができるのは、Nexus 6P 端末上でのみです。 この機能を使用するには、パフォーマンス維持モードで実行するウィンドウにパフォーマンス維持ウィンドウ フラグを設定します。 このフラグは {@code Window.setSustainedPerformanceMode()} メソッドを使用して設定します。 このウィンドウがフォーカスされていない場合、このモードは自動的に無効になります。
Android N には、新しい VR モードのためのプラットフォーム サポートと最適化が追加され、デベロッパーは高品質モバイル端末 VR 体験をユーザーのために生み出すことができます。 多数のパフォーマンス強化があり、VR アプリ用の CPU コアへの排他アクセスが含まれます。アプリでは、VR 用に動作するインテリジェントなヘッド トラッキングやステレオ方式の通知を利用できます。 最も重要な点は、Android N によって大幅に遅延の少ないグラフィックが実現される点です。 Android N 向け VR アプリのビルドの詳細については、Google VR SDK for Android を参照してください。
Android N では、印刷サービスのデベロッパーが、各プリンターや印刷ジョブに関する追加情報を公開できるようになりました。
各プリンターを一覧表示する場合、印刷サービスでは以下の 2 つの方法で各プリンターのアイコンを設定できます。
PrinterInfo.Builder.setResourceIconId() を呼び出すことにより、リソース ID からアイコンを設定できます
PrinterInfo.Builder.setHasCustomPrinterIcon() を呼び出して、android.printservice.PrinterDiscoverySession.onRequestCustomPrinterIcon() を使用してアイコンがリクエストされた場合のコールバックを設定することにより、ネットワークからアイコンを表示できます
また、追加情報を表示する各プリンターのアクティビティを提供する場合は、PrinterInfo.Builder.setInfoIntent() を呼び出します。
印刷ジョブ通知に印刷ジョブの進捗状況やステータスを表示する場合は、android.printservice.PrintJob.setProgress() と android.printservice.PrintJob.setStatus() をそれぞれ呼び出します。
これらのメソッドの詳細については、ダウンロード可能な API リファレンスをご覧ください。
FrameMetricsListener API を使用すると、アプリでその UI レンダリング パフォーマンスを監視できます。
この API は、アプリの現在のウィンドウのフレーム タイミング情報を転送するストリーミング Pub / Sub API を公開することにより、この機能を提供します。
返されるデータは、adb shell
dumpsys gfxinfo framestats によって表示される内容と同じですが、過去の 120 フレームに制限されません。
FrameMetricsListener を使用すると、USB 接続を使用せずに、本番環境のインタラクション レベルの UI パフォーマンスを計測できます。 この API により、{@code adb shell dumpsys gfxinfo} を実行するより粒度の高いデータの収集が可能になります。 アプリの特定のインタラクション データを収集できるため、この粒度の高さが可能となります。アプリのパフォーマンス全体の包括的な概要を取得したり、包括的な状態を明確にしたりする必要はありません。 この機能を使用して、パフォーマンス データを収集したり、アプリでの実際のユースケースにおける UI パフォーマンスの低下を検出したりすることができます。
ウィンドウを監視するには、FrameMetricsListener.onMetricsAvailable() コールバック メソッドを実装して、これを対象のウィンドウに登録します。
詳細については、ダウンロード可能な API リファレンスの {@code FrameMetricsListener} クラスのドキュメントをご覧ください。
この API は {@code FrameMetrics} オブジェクトを提供します。これには、レンダリング サブシステムがフレーム ライフサイクル内のさまざまなマイルストーンで報告するタイミング データが含まれます。サポートされているメトリックは、{@code UNKNOWN_DELAY_DURATION}、{@code INPUT_HANDLING_DURATION}、{@code ANIMATION_DURATION}、{@code LAYOUT_MEASURE_DURATION}、{@code DRAW_DURATION}、{@code SYNC_DURATION}、{@code COMMAND_ISSUE_DURATION}、{@code SWAP_BUFFERS_DURATION}、{@code TOTAL_DURATION}、{@code FIRST_DRAW_FRAME} です。
旧バージョンの Android では、アプリはストレージ アクセス フレームワークを使用して、ユーザーが Google ドライブなどのクラウド ストレージ アカウントからファイルを選択できるようにしていました。 ただし、バイトコードの直接表現がなかったファイルを表示する方法はありませんでした。すべてのファイルは入力ストリームの提供が必要でした。
Android N では、ストレージ アクセス フレームワークに仮想ファイルの概念が追加されています。 仮想ファイル機能を使用すると、バイトコードの直接表現がなくても、{@link android.content.Intent#ACTION_VIEW} インテントで使用できるドキュメント URI を {@link android.provider.DocumentsProvider} で返すことができます。 また、Android N では、ユーザー ファイル（仮想またはそれ以外）に別の形式を提供できます。
アプリで仮想ドキュメントの URI を取得するには、{@link android.content.Intent} を作成してからファイル ピッカーの UI を開きます。 アプリでは {@link android.content.ContentResolver#openInputStream(Uri) openInputStream()} メソッドを使用して仮想ファイルを直接開くことができないため、{@link android.content.Intent#CATEGORY_OPENABLE} カテゴリが含まれている場合はどの仮想ファイルも受信されません。
ユーザーが選択した後で、{@link android.app.Activity#onActivityResult onActivityResult()} メソッドが呼び出されます。 以下のコード スニペットに示すように、アプリは仮想ファイルの URI と入力ストリームを取得できます。
// Other Activity code ...
final static private int REQUEST_CODE = 64;
// We listen to the OnActivityResult event to respond to the user's selection.
@Override
public void onActivityResult(int requestCode, int resultCode,
Intent resultData) {
try {
if (requestCode == REQUEST_CODE &&
resultCode == Activity.RESULT_OK) {
Uri uri = null;
if (resultData != null) {
uri = resultData.getData();
ContentResolver resolver = getContentResolver();
// Before attempting to coerce a file into a MIME type,
// check to see what alternative MIME types are available to
// coerce this file into.
String[] streamTypes =
resolver.getStreamTypes(uri, "*/*");
AssetFileDescriptor descriptor =
resolver.openTypedAssetFileDescriptor(
uri,
streamTypes[0],
null);
// Retrieve a stream to the virtual file.
InputStream inputStream = descriptor.createInputStream();
}
}
} catch (Exception ex) {
Log.e("EXCEPTION", "ERROR: ", ex);
}
}
ユーザー ファイルへのアクセスの詳細については、ストレージ アクセス フレームワークのガイドをご覧ください。