Android 7.0 for Developers

Android 7.0 Nougat では、ユーザーおよびデベロッパー向けのさまざまな機能や性能を新たに導入しました。このドキュメントでは、デベロッパー向けの新しい機能の一部を紹介しています。

プラットフォームの変更によりアプリが影響を受ける分野については、Android 7.0 の動作の変更点をご覧ください。

Android 7.0 の一般ユーザー向けの機能については、www.android.com をご覧ください。

マルチウィンドウのサポート

Android 7.0 では、多くのユーザーから求められていたマルチタスク機能がプラットフォームに新しく導入されました。つまり、マルチウィンドウがサポートされるようになりました。

ユーザーは同時に 2 つのアプリを画面に開くことができます。

Android 7.0 を搭載しているスマートフォンやタブレットでは、分割画面モードで 2 つのアプリを左右や上下に並べて実行できます。また、2 つのアプリの間にある分割線をドラッグしてアプリのサイズを変更することもできます。
Android TV 端末では、アプリをピクチャインピクチャモードにすると、アプリにコンテンツを表示したまま、他のアプリをブラウジングまたは操作することができます。

図 1. 分割画面モードで実行されているアプリ

特にタブレットや大画面の端末では、マルチウィンドウのサポートにより、新たな方法でユーザーを引き付けることが可能になります。アプリでドラッグアンドドロップを有効にすると、ユーザーはアプリから、またはアプリに対してコンテンツを簡単にドラッグすることができるようになり、ユーザーエクスペリエンスが向上します。

マルチウィンドウのサポートをアプリに追加して、マルチウィンドウディスプレイを処理する方法を設定するのは簡単です。たとえば、アクティビティの最小許容ディメンションを指定すると、ユーザーはアクティビティをそのサイズより小さく変更できなくなります。また、アプリに対してマルチウィンドウディスプレイを無効にし、アプリを全画面モードのみで表示することもできます。

詳細については、マルチウィンドウのサポートに関するデベロッパー向けドキュメントをご覧ください。

通知の機能強化

Android 7.0 では、通知が再設計されており、さらに使いやすくなっています。次のような点が変更されました。

テンプレートのアップデート:通知テンプレートは、ヒーローイメージやアバターを中心としたデザインにアップデートされています。デベロッパーは、コードに最小限の変更を加えるだけで、この新しいテンプレートを活用できます。
メッセージスタイルのカスタマイズ:MessagingStyle クラスを使用して、通知に関連するさらに多くのユーザーインターフェースラベルをカスタマイズできます。メッセージ、会話、タイトル、コンテンツビューを設定できます。
バンドル通知:メッセージをグループ化できます。たとえば、メッセージをトピックごとにグループ化して、各グループを表示できます。ユーザーは、各グループに対して、消去やアーカイブといったアクションを実行できます。Android Wear 向けの通知を実装したことがある場合は、このモデルはおなじみでしょう。
ダイレクトリプライ:Android システムでは、インラインリプライがサポートされています。リアルタイム通信アプリを使用しているユーザーは、通知インターフェース内で直接 SMS やテキストメッセージにすばやく応答できます。
カスタムビュー:2 つの新しい API を使用すると、通知でカスタムビューを使用するときに、通知ヘッダーやアクションなどのシステムデコレーションを活用できます。

図 2. バンドル通知とダイレクトリプライ

以上の新しい機能を実装する方法の詳細については、通知に関するガイドをご覧ください。

プロファイルに基づいた JIT / AOT コンパイル

Android 7.0 では、コードプロファイリングにも対応した Just in Time（JIT）コンパイラーが ART に追加されており、Android アプリを実行するときのパフォーマンスが向上しています。JIT コンパイラーは、ART で現在使用されている Ahead of Time（AOT）コンパイラーを補完するものであり、ランタイムパフォーマンスの向上、ストレージスペースの削減、アプリとシステムアップデートの高速化に貢献します。

プロファイルに基づいたコンパイルを使用すると、アプリの実際の使用方法や端末上での状態に応じて、ART が各アプリの AOT / JIT コンパイルを管理します。たとえば、ART は各アプリのホットメソッドのプロファイルを維持し、これらのメソッドをプリコンパイルしてキャッシュに保存することにより、パフォーマンスを最適化します。また、アプリの他の部分は、実際に使用されるときまでコンパイルされません。

プロファイルに基づいたコンパイルは、アプリの主要部分のパフォーマンスを向上させ、関連するバイナリなど、アプリの全体的な RAM 使用量を削減します。この機能は、メモリが少ない端末で特に重要です。

ART は、端末の電池への影響が最小限になるようにプロファイルに基づいたコンパイルを管理します。端末がアイドル状態および充電中のときにのみ、プリコンパイルが事前に実行されるため、時間と電池を節約できます。

アプリの高速インストール

ART の JIT コンパイラーの最も明確な利点の 1 つは、高速なアプリのインストールとシステムアップデートです。Android 6.0 では最適化とインストールの実行に数分かかっていたサイズの大きいアプリが、数秒でインストールできるようになりました。最適化のステップが不要になったため、システムアップデートも高速化されています。

どこでも機能する Doze

Android 6.0 では Doze システムモードが導入されています。これにより、端末が机に置かれているときや引き出しに収められているときなどのアイドル時にアプリの CPU とネットワーク通信の実行を保留し、電池を節約します。

Android 7.0 では Doze が改良され、外出中でも電池を節約できるようになっています。画面をしばらくオフにしたり端末を電源から抜いたりすると、Doze により、通常の CPU およびネットワーク制限の一部がアプリに適用されます。つまり、端末をポケットに入れて持ち歩いているときでも電池を節約できます。

図 3. Doze により、端末が静止していないときでも制限が適用され、電池の寿命が延長される

端末が電池で動作しているときに画面をしばらくオフにすると、Doze はネットワークアクセスを制限し、ジョブと同期を保留します。アプリはメンテナンスの時間枠と呼ばれる短い時間にネットワークにアクセスしたり、保留中のジョブや同期を実行したりします。画面をオンにするか、端末を電源に接続すると、端末の Doze モードは解除されます。

電池で動作している端末が再び静止状態になり、画面がしばらくオフになると、Doze は完全な CPU およびネットワーク制限を PowerManager.WakeLock、AlarmManager アラーム、GPS や Wi-Fi のスキャンに適用します。

アプリを Doze に対応させるためのベストプラクティスは端末を持ち歩いているかどうかにかかわらず同じです。そのため、Doze が適切に処理されるようにアプリを既にアップデートしている場合は、追加の対応は必要ありません。そうでない場合は、アプリの Doze 対応を行ってください。

Project Svelte:バックグラウンド処理の最適化

Project Svelte は、Android エコシステムのさまざまな端末でシステムやアプリによる RAM の使用を最小限にする取り組みです。Android 7.0 での Project Svelte は、アプリをバックグラウンドで実行する方法を最適化することに重点を置いています。

ほとんどのアプリでは、バックグラウンド処理が非常に重要になります。バックグラウンド処理を適切に実行すると、状況に応じて高速に実行できるなどユーザーエクスペリエンスが大幅に向上します。バックグラウンド処理が不適切な場合は、RAM（と電池）が必要以上に消費され、他のアプリのシステムパフォーマンスに影響を及ぼす可能性があります。

Android 5.0 以降では、ユーザーに適した方法でバックグラウンド処理を実行する JobScheduler が推奨されています。これによって、メモリ、電源、接続の状態に基づいてシステムを最適化しながら、アプリでジョブをスケジュールできます。JobScheduler ではシンプルな制御が可能であり、すべてのアプリで JobScheduler を使用すると効果的です。

もう 1 つの適切な選択肢は、Google Play サービスの一部である GCMNetworkManager です。この機能も同様のジョブスケジュール機能を提供しますが、こちらは以前のバージョンの Android とも互換性があります。

さらに多くのユースケースに対応するために、JobScheduler と GCMNetworkManager の拡張は継続されています。たとえば、Android 7.0 では、コンテンツプロバイダの変更に基づいてバックグラウンド処理をスケジュールできるようになりました。また、特にメモリの少ない端末でシステムパフォーマンスを低下させる可能性のある一部の古いパターンの廃止も開始されています。

一般的に使用される暗黙的なブロードキャストである CONNECTIVITY_ACTION、ACTION_NEW_PICTURE、ACTION_NEW_VIDEO は複数のアプリのバックグラウンド処理を同時に起動するので、メモリと電池に負荷をかける可能性があります。そのため、Android 7.0 では、この 3 つのブロードキャストが削除されています。アプリがこれらのブロードキャストを受信する場合は、Android 7.0 を使用して、JobScheduler とそれに関連する API に移行してください。

詳細については、バックグラウンド処理の最適化に関するドキュメントをご覧ください。

SurfaceView

Android 7.0 では、同期処理が SurfaceView クラスに追加され、次のような特定のケースでは TextureView よりも電池の持ちが良くなります。動画または 3D コンテンツをレンダリングするとき、スクロールや動画アニメーションの配置が含まれるアプリは、TextureView よりも SurfaceView を使用したほうが消費電力を節約できます。

SurfaceView クラスを使用すると、画面上での合成処理の電池効率がさらに向上します。これは、アプリウィンドウのコンテンツとは別に、専用のハードウェアで合成が行われるためです。その結果、作成される中間コピーが TextureView よりも削減されます。

SurfaceView オブジェクトのコンテンツの位置が、そこに含まれるアプリのコンテンツと同期を取って更新されるようになりました。この変更による影響として、SurfaceView で単純な遷移や再生中の動画をスケーリングしたときに、その動きに応じてビューの横に黒いバーが表示されることがなくなりました。

Android 7.0 以降は、TextureView の代わりに SurfaceView を使用して、消費電力を節約することを強くお勧めします。

データセーバー

図 4. [Settings] でのデータセーバー

一般的に、モバイル端末のライフサイクル全体では、モバイルデータ通信プランの費用が端末自体の費用を上回ります。多くのユーザーにとって、モバイルデータ通信は、節約する必要のある高価なリソースです。

Android 7.0 では、ローミング、課金サイクルの終了間際、または短期間のデータパックであるかどうかに関係なく、アプリによるモバイルデータ通信の使用を削減する新しいシステムサービスであるデータセーバーモードが導入されています。データセーバーを使用すると、アプリによるモバイルデータ通信の使用方法をユーザーが制御できます。また、デベロッパーは、データセーバーがオンのときに、より効率よく通信するサービスを提供できるようになります。

ユーザーが [Settings] でデータセーバーを有効にし、端末が従量制課金ネットワークに接続されている場合、システムは、ストリーミングのビットレートを制限したり、画質を低下させたり、オプティミスティックなプレキャッシングを保留したりすることにより、バックグラウンドでのデータ使用をブロックし、フォアグラウンドでのデータ使用をなるべく抑えるようにアプリに指示します。ユーザーがホワイトリストに登録したアプリは、データセーバーがオンになっているときでも、バックグラウンドで従量制データ通信を使用できます。

Android 7.0 は ConnectivityManager を拡張することで、ユーザーのデータセーバー設定を取得する方法と、設定の変更を監視する方法をアプリに提供しています。すべてのアプリは、ユーザーがデータセーバーを有効にしているかどうかを確認し、フォアグラウンドおよびバックグラウンドでのデータ使用を制限する必要があります。

Vulkan API

Android 7.0 では、新しい 3D レンダリング API である Vulkan™ がプラットフォームに統合されています。OpenGL™ ES と同様に、Vulkan は Khronos グループによって管理されている 3D グラフィックおよびレンダリングのオープンスタンダードです。

Vulkan は、ドライバの CPU オーバーヘッドを最小化するため、およびアプリケーションが GPU の動作をより直接的に制御できるように設計されています。また、Vulkan は、複数のスレッドが作業を実行できるようにする（コマンドバッファーの作成を同時に行うなど）ことによって、より優れた並列処理が可能です。

Vulkan 開発ツールおよびライブラリは、Android 7.0DK に含まれています。次のようなものが含まれます。

ヘッダー
検証レイヤ（デバッグライブラリ）
SPIR-V シェーダーコンパイラー
SPIR-V シェーダーのランタイムコンパイルライブラリ

Vulkan は、Nexus 5X、Nexus 6P、Nexus Player などの Vulkan 対応ハードウェアを備えた端末上のアプリでのみ利用できます。Google では Vulkan を可能な限りより多くの端末に導入するために、パートナーと連携して作業を進めています。

詳細については、API ドキュメントをご覧ください。

Quick Settings Tile API

図 5. 通知シェードにあるクイック設定タイル

クイック設定は、通知シェードから主要な設定とアクションを直接公開するための一般的で簡単な方法です。Android 7.0 では、クイック設定の範囲が拡大され、さらに使いやすく便利な機能になっています。

クイック設定タイル用のスペースが広くなったので、ユーザーは、左または右にスワイプして、ページ分割された表示領域でこれらのタイルにアクセスできます。また、ユーザーは、表示するクイック設定タイルとその表示場所を制御できるようになっています。ユーザーはタイルをドラッグアンドドロップして、追加または移動できます。

Android 7.0 では、デベロッパーが独自のクイック設定タイルを定義できる新しい API が追加されています。これにより、ユーザーはアプリの主なコントロールとアクションに簡単にアクセスできるようになります。

クイック設定タイルは、緊急に必要な、または頻繁に使用されるコントロールやアクション用に用意されたものであり、アプリを起動するためのショートカットとして使用するべきではありません。

タイルの定義が完了すると、ユーザーにタイルを公開できるようになります。ユーザーはタイルをドラッグ＆ドロップするだけで、クイック設定にタイルを追加できます。

アプリタイルを作成する方法については、ダウンロード可能な API リファレンスに掲載されている android.service.quicksettings.Tile のドキュメントをご覧ください。

電話番号のブロック

Android 7.0 では、プラットフォームで電話番号のブロックがサポートされており、サービスプロバイダがブロックされた電話番号のリストを保持するためのフレームワーク API が提供されています。デフォルトの SMS アプリ、デフォルトの電話アプリ、携帯通信会社アプリは、ブロックされた電話番号のリストを読み込んだり、このリストに書き込んだりできます。その他のアプリはこのリストにアクセスできません。

Android では、電話番号のブロックをプラットフォームの標準の機能にすることで、幅広い端末でアプリによる電話番号のブロック方法を統一できるようにしています。その他にアプリは次のような機能も利用できます。

ブロックされた電話番号は、テキストメッセージでもブロックされる
ブロックされた電話番号は、リセットした端末や、バックアップと復元をした端末でも保持される
複数のアプリが同じブロックリストを使用できる

また、Android に携帯通信会社のアプリが組み込まれていると、携帯通信会社は端末上のブロックリストを読み込んで迷惑な電話やテキストメッセージをサービス側でブロックできます。これによって、VOIP エンドポイントや転送電話などいかなる媒体を介しても、ブロックされた番号はユーザーに到達できなくなります。

詳細については、ダウンロード可能な API リファレンスの android.provider.BlockedNumberContract をご覧ください。

通話スクリーニング

Android 7.0 では、デフォルトの電話アプリで着信をスクリーニングできます。新しい CallScreeningService を実装することによって、電話アプリは着信をスクリーニングします。これにより、電話アプリは着信する電話の Call.Details に基づいて次のようなアクションを実行できます。

着信を拒否する
着信を通話履歴に含めない
着信通知をユーザーに表示しない

詳細については、ダウンロード可能な API リファレンスの android.telecom.CallScreeningService をご覧ください。

マルチロケールのサポートと言語の追加

Android 7.0 では、[Settings] でマルチロケールを選択できるようになり、複数言語を使用するユーザーへのサポートが強化されました。アプリで新しい API を使用して、ユーザーが選択したロケールを取得すると、複数のロケールを設定しているユーザーに対してより洗練されたユーザーエクスペリエンスを提供できます。たとえば、検索結果を複数の言語で表示したり、ユーザーが理解している言語のウェブページでは翻訳の提案を行わないようにしたりすることが可能になります。

また、Android 7.0 では、マルチロケールのサポートに加えて、ユーザーが利用できる言語が追加されています。英語、スペイン語、フランス語、アラビア語などの一般的な言語に対して、それぞれ 25 以上のバリエーションが提供されます。100 以上の新しい言語も部分的にサポートされています。

アプリは、LocaleList.GetDefault() を呼び出すことにより、ユーザーが設定したロケールのリストを取得できます。Android 7.0 では、ロケール数の増加に対応するために、リソースを解決する方法が変更されています。この新しいリソース解決ロジックでアプリが想定どおりに動作することをテストおよび確認してください。

新しいリソース解決動作と順守すべきベストプラクティスの詳細については、複数言語のサポートをご覧ください。

新しい絵文字

Android 7.0 では、肌色の異なる絵文字や異体字セレクターのサポートなど、絵文字の追加と絵文字関連機能が導入されています。アプリで絵文字をサポートする場合は、以下のガイドラインに従い、これらの絵文字関連機能を利用します。

絵文字を挿入する前に端末に絵文字が含まれていることを確認する。システムフォントで表示される絵文字を確認するには、hasGlyph(String) メソッドを使用します。
絵文字が異体字セレクターをサポートしていることを確認する。異体字セレクターを使用すると、特定の絵文字をカラーまたは白黒で表示できます。アプリは、モバイル端末では白黒よりもカラーで絵文字を表示する必要があります。ただし、アプリでテキストメッセージ内に絵文字を表示する場合は、白黒バージョンを使用する必要があります。絵文字に異体字があるかどうかを確認するには、異体字セレクターを使用します。異体字のある文字の完全なリストについては、異体字に関する Unicode ドキュメントの「絵文字異体字シーケンス」セクションを確認してください。
絵文字が肌色をサポートしていることを確認する。Android 7.0 では、レンダリングされる絵文字の肌色を好みの色に変更できます。キーボードアプリでは、肌色が複数ある絵文字をわかりやすく表示して、ユーザーが好みの肌色を選択できるようにする必要があります。肌色修飾子を持つシステムの絵文字を確認するには、hasGlyph(String) メソッドを使用します。肌色を使用する絵文字を確認するには、Unicode ドキュメントをご覧ください。

Android の ICU4J API

Android 7.0 では、Android フレームワーク内の android.icu パッケージで ICU4J API のサブセットが提供されております。移行は簡単で、ほとんどの場合、名前空間を com.java.icu から android.icu に変更するだけです。アプリで ICU4J バンドルを既に使用している場合は、Android フレームワークで提供されている android.icu API に移行すると、APK サイズを大幅に削減できます。

Android ICU4J API の詳細については、ICU4J のサポートをご覧ください。

WebView

Chrome と WebView を組み合わせて使う

Android 7.0 以降で実行する Chrome バージョン 51 以降は、端末上の Chrome APK を使用して Android システムの WebView の提供やレンダリングを行います。このアプローチにより、端末自体のメモリ消費が改善され、WebView を最新に保つために必要な帯域幅も削減されます（スタンドアロンの WebView APK は、Chrome が有効である限り更新されなくなります）。

[Developer Options] を有効にして [WebView implementation] を選択すると、WebView プロバイダを選択できます。端末にインストールされた互換性のある Chrome の任意のバージョン（開発、ベータ、安定版）か、スタンドアロンの Webview APK を使用して、WebView の実装として動作させることができます。

マルチプロセス

Android 7.0 の Chrome バージョン 51 以降は、デベロッパーオプションの [Multiprocess WebView] が有効になっている場合、WebView は別のサンドボックスプロセスでウェブコンテンツを実行します。

WebView チームでは、将来のバージョンの Android で Multiprocess WebView を有効にする前に、このバージョンでの互換性やランタイムパフォーマンスに関するフィードバックを求めています。このバージョンでは、スタートアップ時間、メモリの合計使用量、ソフトウェアレンダリングパフォーマンスの低下が予想されます。

マルチプロセスモードで予想外の問題が見つかった場合は、ご報告ください。Chromium Bug Tracker から WebView チームにご連絡をお願いします。

ページを読み込む前に Javascript が実行される

Android 7.0 以降を対象とするアプリでは、新しいページが読み込まれるときに、Javascript コンテキストがリセットされます。現在、コンテキストは、新しい WebView インスタンスで、最初に読み込まれるページに持ち越されます。

Javascript を WebView に挿入する予定のデベロッパーの方は、ページの読み込みが開始した後にスクリプトが実行されるようにしてください。

安全でないオリジンでの位置情報

Android 7.0 以降を対象とするアプリでは、Geolocation API は安全なオリジン（HTTPS 経由）でのみ許可されます。このポリシーは、ユーザーが安全でない接続を使用しているときにユーザーの個人情報を保護するために設計されています。

WebView ベータ版でのテスト

WebView は定期的に更新されるため、WebView ベータ版チャンネルを使用して頻繁にアプリとの互換性をテストすることをお勧めします。Android 7.0 の WebView のプレビューリリース版をテストするには、Chrome 開発版または Chrome ベータ版をダウンロードおよびインストールして、先ほど説明した [Developer options] で WebView の実装として選択します。Chromium Bug Tracker から問題を報告して、新しいバージョンの WebView をリリースする前に問題を修正できるようご協力ください。

OpenGL™ ES 3.2 API

Android 7.0 では、OpenGL ES 3.2 用の以下のようなフレームワークインターフェースとプラットフォームサポートが追加されています。

EXT_texture_sRGB_decode を除く Android エクステンションパック（AEP）のすべての拡張機能
HDR および遅延シェーディング用の浮動小数点フレームバッファ
一括処理とストリーミングを向上させるための BaseVertex 描画呼び出し
WebGL のオーバーヘッドを低減するための堅牢なバッファアクセスコントロール

Android 7.0 の OpenGL ES 3.2 用のフレームワーク API は、GLES32 クラスで提供されます。OpenGL ES 3.2 を使用する場合、<uses-feature> タグと android:glEsVersion 属性を使用してマニフェストファイルで要件を宣言する必要があります。

端末でサポートされる OpenGL ES のバージョンを実行時に確認する方法など、OpenGL ES の使用方法については、OpenGL ES API ガイドをご覧ください。

Android TV の録画機能

Android 7.0 では、新しい recording API を介して Android TV 入力サービスからコンテンツを録画して再生する機能が追加されています。TV 入力サービスでは、録画できるチャンネルデータや録画したセッションを保存する方法の制御、ユーザーによる録画されたコンテンツの操作の管理を行うことができます。このサービスは、既存の time-shifting API を使用して構築されています。

詳細については、Android TV Recording API をご覧ください。

Android for Work

Android for Work は、Android 7.0 を実行している端末に多くの新しい機能と API を追加するものです。主要な機能の一部を以下に紹介します。変更点の完全なリストについては、Android for Work のアップデートをご覧ください。

仕事用プロファイルによるセキュリティ確認

N SDK を対象としているプロファイルオーナーは、仕事用プロファイルで実行しているアプリで個別にセキュリティ確認を行うよう指定することができます。ユーザーが仕事用アプリを開こうとすると、仕事用プロファイル用のセキュリティ確認画面が表示されます。セキュリティの確認に成功すると、仕事用プロファイルのロックが解除され、必要に応じて暗号化も解除されます。プロファイルオーナーは、ACTION_SET_NEW_PASSWORD でユーザーに仕事用プロファイル用のセキュリティ確認を設定するように求めたり、ACTION_SET_NEW_PARENT_PROFILE_PASSWORD でユーザーに端末のロックを設定するように求めたりします。

プロファイルオーナーは、setPasswordQuality()、setPasswordMinimumLength()、および関連するメソッドを使用して、仕事用プロファイル用のセキュリティ確認に個別のパスコードポリシー（PIN に必要な桁数や、指紋によるプロファイルのロック解除が可能かどうかなど）を設定できます。また、新しい getParentProfileInstance() メソッドが返す DevicePolicyManager インスタンスを使用して端末のロックを設定できます。さらに、新しい setOrganizationColor() メソッドおよび setOrganizationName() メソッドを使用して仕事用プロファイル用のセキュリティ確認画面をカスタマイズすることができます。

ワークモードのオフ

ユーザーは、仕事用プロファイルがある端末でワークモードを切り替えることができます。ワークモードがオフになると、管理されているユーザーが一時的にシャットダウンされ、仕事用プロファイルのアプリ、バックグラウンドでの同期、通知が無効になります。これには、プロファイルオーナーのアプリが含まれます。また、ワークモードがオフになると、仕事用アプリを起動できないことをユーザーに示すステータスアイコンが表示されたままになります。ランチャーは、仕事用アプリとウィジェットにアクセスできないことを示します。

Always on VPN

デバイスオーナーとプロファイルオーナーは、指定した VPN を介して仕事用アプリが常時接続するように設定できます。端末が起動すると、システムは VPN を自動的に開始します。

setAlwaysOnVpnPackage() と getAlwaysOnVpnPackage() は新しい DevicePolicyManager のメソッドです。

システムがアプリの介入なしに VPN サービスを直接バインドするため、Always on VPN の新しいエンドポイントは VPN クライアント側で処理する必要があります。以前と同じように、システムへのサービスの通知はインテントフィルタのマッチングアクション android.net.VpnService で行います。

ユーザーは、[Settings] > [More] > [Vpn] から、VPNService のメソッドを実装した Always on VPN クライアントを手動で設定することもできます。[Settings] から Always on VPN を有効にするこのオプションを使用できるのは、API レベル 24 を対象とする VPN クライアントのみです。

カスタマイズされたプロビジョニング

アプリでは、コーポレートカラーやロゴを含むプロファイルオーナーとデバイスオーナーのプロビジョニングフローをカスタマイズできます。DevicePolicyManager.EXTRA_PROVISIONING_MAIN_COLOR はフローカラーをカスタマイズします。DevicePolicyManager.EXTRA_PROVISIONING_LOGO_URI は、コーポレートロゴを含むフローをカスタマイズします。

ユーザー補助機能の強化

Android 7.0 では、新しい端末のセットアップのオープニング画面に [Vision Settings] が直接表示されます。これにより、ユーザーは、ズーム操作、フォントサイズ、ディスプレイサイズ、TalkBack など、端末のユーザー補助機能を簡単に見つけて設定できるようになっています。

このようなユーザー補助機能が目立つ場所に配置されたため、ユーザーがこれらの機能を有効にしてアプリを試用する可能性が高まりました。これらの設定を有効にして、アプリを事前にテストするようにしてください。これらの設定は、[Settings] > [Accessibility] で有効にできます。

Android 7.0 では、ユーザー補助機能サービスにより、障害のあるユーザーが画面をタップすることを支援できます。この新しい API を使用すると、顔追跡、視線追跡、ポイントスキャンなどの機能を備えたサービスを構築して、これらのユーザーのニーズに対応することができます。

詳細については、ダウンロード可能な API リファレンスの android.accessibilityservice.GestureDescription をご覧ください。

ダイレクトブート

ダイレクトブートはデバイスのスタートアップ時間を短縮し、予期しない再起動後でも、登録されたアプリの一部の機能が使用できるようにします。たとえば、ユーザーの就寝中に暗号化された端末が再起動した場合でも、登録したアラーム、メッセージ、電話の着信をユーザーに通常どおり通知することができます。また、再起動後にユーザー補助機能サービスをすぐに使用することもできます。

ダイレクトブートでは、Android 7.0 のファイルベースの暗号化を活用して、システムとアプリのデータに対してきめ細かい暗号化ポリシーを有効にします。システムは、一部のシステムデータと明示的に登録されたアプリデータに端末暗号化ストアを使用します。デフォルトでは、他のすべてのシステムデータ、ユーザーデータ、アプリ、アプリデータには、認証情報暗号化ストアが使用されます。

システムは起動時に端末暗号化データのみにアクセスできる制限モードになります。この状態では、アプリやデータへの一般的なアクセスは許可されません。このモードで実行する必要のあるコンポーネントがある場合、マニフェストにフラグを設定することでコンポーネントを登録できます。再起動後、システムは、LOCKED_BOOT_COMPLETED インテントをブロードキャストすることにより、登録済みのコンポーネントをアクティベートします。システムは、ロック解除する前に、登録済みの端末暗号化アプリデータを利用できるようにします。他のすべてのデータは、ユーザーがロック画面の認証情報を確認して暗号化を解除するまで利用できません。

詳細については、ダイレクトブートをご覧ください。

キーの構成証明

Android 7.0 では、キーの構成証明という新しいセキュリティツールが導入され、端末のハードウェアでサポートされているキーストアにキーのペアが保存され、アプリが使用する機密情報が適切に保護されます。このツールを使用すると、アプリを実行する端末がルート権限を取得している場合でも、安全なハードウェアに存在するキーをアプリで操作することで信頼性が向上します。ハードウェアでサポートされているキーストアのキーをアプリで使用するには、特にキーを使用してアプリ内の機密情報を確認する場合、このツールを使用する必要があります。

キーの構成証明を使用すると、RSA または EC キーのペアが作成され、端末の信頼される実行環境（TEE）にある、端末のハードウェアがサポートするキーストアにキーペアが保存されていることを確認できます。また、アプリのバックエンドサーバーなどの別の端末のサービスを使用して、キーペアの使用方法や有効性を判断し、厳密に検証することもできます。これらの機能により、端末にルート権限が付与されていたり、端末を実行する Android プラットフォームのセキュリティが侵害された場合でも、キーペアを保護するセキュリティのレベルを高めることができます。

注: Android 7.0 を実行するごく一部の端末のみがハードウェアレベルのキーの構成証明をサポートします。Android 7.0 を実行するその他のすべての端末はソフトウェアレベルのキーの構成証明を使用します。本番環境レベルで端末のハードウェアがサポートするキーのプロパティを確認する前に、端末がハードウェアレベルのキーの構成証明をサポートすることを確認する必要があります。これを行うには、Google 構成証明ルートキーによって署名されたルート証明書が構成証明書チェーンに含まれていることに加えて、キーの説明のデータ構造内の attestationSecurityLevel 要素が TrustedEnvironment セキュリティレベルに設定されていることを確認する必要があります。

詳細については、キーの構成証明に関するデベロッパー向けドキュメントをご覧ください。

ネットワークセキュリティ構成

Android 7.0 では、エラーが発生しやすいプログラムによる従来の API（X509TrustManager など）ではなく、宣言型のネットワークセキュリティ構成を使用することにより、コードを変更することなく、セキュアな（HTTPS、TLS）接続動作をアプリで安全にカスタマイズできます。

以下の機能がサポートされます。

カスタムトラストアンカー。アプリのセキュアな接続にどの証明機関（CA）を信頼するかをカスタマイズできます。たとえば、特定の自己署名証明書や制限された一連の公的 CA を信頼できます。
デバッグ限定のオーバーライド。アプリのデベロッパーは、インストールベースに対する追加リスクなしに、アプリのセキュアな接続を安全にデバッグできます。
クリアテキストトラフィックのオプトアウト。クリアテキストトラフィックの意図しない使用からアプリを保護できます。
証明書のピン留め。アプリのセキュアな接続で信頼するサーバーキーを制限できる高度な機能です。

詳細については、ネットワークセキュリティ構成をご覧ください。

既定の信頼される証明機関

既定では、Android 7.0 用アプリは、システムが提供する証明書のみを信頼し、ユーザーが追加した証明機関（CA）を信頼しません。ユーザーが追加した CA を信頼する必要がある Android N 向けのアプリは、ネットワークセキュリティ構成を使用して、ユーザー CA を信頼する方法を指定する必要があります。

APK 署名スキーム v2

Android 7.0 では、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 7.0 では、アプリで新しい API を使用して、SD カードなどのリムーバブルメディア上のディレクトリといった特定の外部ストレージディレクトリへのアクセスをリクエストできるようになりました。この新しい API は、アプリが Pictures ディレクトリなどの標準の外部ストレージディレクトリにアクセスする方法を大幅に簡略化します。写真アプリなどのアプリでは、READ_EXTERNAL_STORAGE の代わりに、この API ですべてのストレージディレクトリやストレージアクセスフレームワークにアクセスできるため、ユーザーはそのディレクトリに移動できます。

また、この新しい API は、ユーザーがアプリに外部ストレージへのアクセスを付与するステップを簡素化します。この新しい API を使用する場合、アプリがどのディレクトリへのアクセス許可を求めているかをわかりやすく説明するシンプルな UI が使用されます。

詳細については、特定のディレクトリへのアクセスに関するデベロッパー向けドキュメントをご覧ください。

キーボードショートカットヘルパー

Android 7.0 では、ユーザーは Meta キー + / キーを同時に押してキーボードショートカット画面をトリガーできます。この画面には、システムとアプリから使用できるすべてのショートカットが表示されます。ショートカットが存在する場合、これらのショートカットが自動的にアプリのメニューから取得されます。独自に調整したショートカットのリストを画面に表示することもできます。ダウンロード可能な API リファレンスで説明しているように、新しい Activity.onProvideKeyboardShortcuts() メソッドをオーバーライドしてこれを実行することができます。

注: この Meta キーはすべてのキーボードに存在するわけではありません。Macintosh キーボードでは Command キー、Windows キーボードでは Windows キー、Pixel C および Chrome OS キーボードでは Search キーが Meta キーになります。

アプリ内のどこででもキーボードショートカットヘルパーをトリガーするには、関連アクティビティの Activity.requestKeyboardShortcutsHelper() を呼び出します。

Custom Pointer API

Android 7.0 では Custom Pointer API が導入され、ポインターの外観、表示、動作をカスタマイズできるようになりました。この機能は、ユーザーがマウスやタッチパッドを使用して UI オブジェクトを操作する際に特に便利です。既定のポインターは、標準のアイコンを使用します。この API には、マウスやタッチパッドの特定の動作に応じたポインターアイコンの外観の変更など、高度な機能も含まれています。

ポインターアイコンを設定するには、View クラスのonResolvePointerIcon() メソッドをオーバーライドします。このメソッドは、PointerIcon オブジェクトを使用して、特定のモーションイベントに対応したアイコンを描画します。

Sustained Performance API

長時間動作するアプリではパフォーマンスが大幅に変動する可能性があります。これは、端末のコンポーネントがその温度制限に達すると、システムによりシステムオンチップエンジンが抑制されるためです。この変動は、高性能で長時間動作するアプリを作成するアプリのデベロッパーにとって目標が変動することを意味します。

これらの制限に対処するために、Android 7.0 ではパフォーマンス維持モードがサポートされており、OEM は長時間実行するアプリに端末のパフォーマンスに関する情報を提供することができます。アプリのデベロッパーはこれらの情報を使用することで、長時間にわたって予測可能な一定レベルの端末パフォーマンスが保たれるようにアプリを調整できます。

アプリのデベロッパーが Android 7.0 でこの新しい API を試すことができるのは、Nexus 6P 端末上でのみです。この機能を使用するには、パフォーマンス維持モードで実行するウィンドウにパフォーマンス維持ウィンドウフラグを設定します。このフラグは Window.setSustainedPerformanceMode() メソッドを使用して設定します。このウィンドウがフォーカスされていない場合、このモードは自動的に無効になります。

VR サポート

Android 7.0 には、新しい VR モードのためのプラットフォームサポートと最適化が追加されており、デベロッパーはユーザー向けに高品質モバイル端末 VR 体験を生み出すことができます。また、VR アプリ用の CPU コアへの排他アクセスなど、さまざまな点でパフォーマンスが強化されています。アプリでは、VR 用に動作するインテリジェントなヘッドトラッキングやステレオ方式の通知を利用できます。最も重要な点は、Android 7.0 によって非常に遅延の少ないグラフィックが実現されることです。Android 7.0 向け VR アプリのビルドの詳細については、Google VR SDK for Android を参照してください。

印刷サービス機能の強化

Android 7.0 では、印刷サービスのデベロッパーが、各プリンターや印刷ジョブに関する追加情報を公開できるようになりました。

各プリンターを一覧表示する場合、印刷サービスでは以下の 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

FrameMetricsListener API を使用すると、アプリでその UI レンダリングパフォーマンスを監視できます。この API は、アプリの現在のウィンドウのフレームタイミング情報を転送するストリーミング Pub / Sub API を公開することにより、この機能を提供します。返されるデータは、adb shell dumpsys gfxinfo framestats によって表示される内容と同じですが、過去の 120 フレームに制限されません。

FrameMetricsListener を使用すると、USB 接続を使用せずに、本番環境のインタラクションレベルの UI パフォーマンスを計測できます。この API により、adb shell dumpsys gfxinfo を実行するより粒度の高いデータの収集が可能になります。アプリの特定のインタラクションデータを収集できるため、この粒度の高さが実現します。アプリのパフォーマンス全体の包括的な概要を取得したり、包括的な状態を明確にしたりする必要はありません。この機能を使用して、パフォーマンスデータを収集したり、アプリでの実際のユースケースにおける UI パフォーマンスの低下を検出したりすることができます。

ウィンドウを監視するには、FrameMetricsListener.onMetricsAvailable() コールバックメソッドを実装して、これを対象のウィンドウに登録します。詳細については、ダウンロード可能な API リファレンスの FrameMetricsListener クラスのドキュメントをご覧ください。

この API は FrameMetrics オブジェクトを提供します。これには、レンダリングサブシステムがフレームライフサイクル内のさまざまなマイルストーンで報告するタイミングデータが含まれます。サポートされているメトリックは、UNKNOWN_DELAY_DURATION, INPUT_HANDLING_DURATION、ANIMATION_DURATION、LAYOUT_MEASURE_DURATION, DRAW_DURATION、SYNC_DURATION, COMMAND_ISSUE_DURATION、SWAP_BUFFERS_DURATION、TOTAL_DURATION、FIRST_DRAW_FRAME です。

仮想ファイル

旧バージョンの Android では、アプリはストレージアクセスフレームワークを使用して、ユーザーが Google Drive などのクラウドストレージアカウントからファイルを選択できるようにしていました。ただし、バイトコードの直接表現がないファイルを表示する方法はなく、すべてのファイルは入力ストリームを提供する必要がありました。

Android 7.0 では、ストレージアクセスフレームワークに仮想ファイルの概念が追加されています。仮想ファイル機能を使用すると、バイトコードの直接表現がなくても、ACTION_VIEW インテントで使用できるドキュメント URI を DocumentsProvider で返すことができます。また、Android 7.0 では、ユーザーファイル（仮想またはそれ以外）に別の形式を提供できます。

アプリで仮想ドキュメントの URI を取得するには、Intent を作成してからファイルピッカーの UI を開きます。アプリでは openInputStream() メソッドを使用して仮想ファイルを直接開くことができないため、CATEGORY_OPENABLE カテゴリが含まれている場合はどの仮想ファイルも受信されません。

ユーザーが選択した後で、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);
      }
  }

ユーザーファイルへのアクセスの詳細については、ストレージアクセスフレームワークのガイドをご覧ください。