[翻訳] Android N PreviewのAPIの概要

Android N PreviewのAPIの概要を翻訳してみました。

よくわからない部分もあったので、おかしな点に
つきましてはコメント頂ければと思います。m(_ _)m

以下、関連する投稿へのリンクです。
■ Android N PreviewのBehavior Changes　公式　翻訳
■ Android N PreviewのBackground Optimizations　公式　翻訳
■ Android N PreviewのAPIの概要　公式　翻訳

注）この内容はPreview1時点のものです。
　　最新版とは差分が発生している可能性があります。

公式が翻訳されました ので、公式をご覧ください。 m(_ _)m

Android N for Developers

Android N is still in active development, but you can try it now as part of the N Developer Preview. The sections below highlight some of the new features for developers.

Make sure to check out the Behavior Changes to learn about areas where platform changes may affect your apps, take a look at the developer guides to learn more about key features, and download the API Reference for details on new APIs.

Android Nは現在も開発中ですが、あなたはN Developer Previewでそれを試すことが出来ます。　以下のセクションでは、開発者向け新機能のいくつかを示します。

あなたのアプリに影響するかもしれないプラットフォーム変更部分について知るためにBehavior Changesをチェックし、主要な機能についてより知るためにデベロッパーガイドを参照し、新しいAPIの詳細についてはAPI Referenceをダウンロードしてください。

Multi-window support

In Android N, we're introducing a new and much-requested multitasking feature into the platform — multi-window support.

Users can now pop open two apps on the screen at once.

• On phones and tablets running Android N, users can run two apps side-by-side or one-above-the-other in splitscreen mode. Users can resize the apps by dragging the divider between them.
  
  
  
• On Android TV devices, apps can put themselves in picture-in-picture mode, allowing them to continue showing content while the user browses or interacts with other apps.

Figure 1. Apps running in split-screen mode.

Especially on tablets and other larger-screen devices, multi-window support gives you new ways to engage users. You can even enable drag-and-drop in your app to let users conveniently drag content to or from your app — a great way to enhance your user experience.

It's straightforward to add multi-window support to your app and configure how it handles multi-window display. For example, you can specify your activity's minimum allowable dimensions, preventing users from resizing the activity below that size. You can also disable multi-window display for your app, which ensures that the system will only show your app in full-screen mode.

For more information, see the Multi-Window Support developer documentation.

Android Nで我々はプラットフォームに新しいそして多くの要望があったマルチタスク機能を導入します。 それはmulti-window supportです。

これからはユーザーは一度に２つのアプリを画面に開けます。

• Android Nが動いている電話やタブレットでは、分割画面モードで２つのアプリを左右または上下に並べて実行できます。　ユーザーは、それらの境界をドラッグすることにより、アプリの表示サイズを変更することができます。
  
  
  
• Android TVデバイスでは、アプリは自身をピクチャ・イン・ピクチャモードにでき、ユーザーが他のアプリを見たり接している間、コンテンツを見続けることを可能にします。

Figure 1. 分割画面モードで動いているアプリ

特にタブレットやほかの大画面デバイスにおいて、multi-window supportはあなたにユーザーとやりとりする新しい方法を提供します。　あなたは、ユーザーがあなたのアプリへもしくはあなたのアプリから便利よくコンテンツをドラッグできるように、アプリ内でドラッグアンドドロップを有効にすることもできます。　これはユーザーエクスペリエンスを向上させる素晴らしい方法です。

あなたのアプリにmulti-window supportを追加し、どのようにmulti-window表示を扱うかを設定することは簡単です。　例えば、ユーザーがactivityをそのサイズ以下にリサイズすることを防止するため、activityが許容する最小サイズを指定できます。　またあなたのアプリについて、multi-window表示を無効にすることも出来ます。　これはシステムがあなたのアプリをフルスクリーンモードでのみ表示することを保証します。

より詳しくは、Multi-Window Supportを参照してください。

Notification enhancements

In Android N we've redesigned notifications to make them easier and faster to use. Some of the changes include:

• Template updates: We're updating notification templates to put a new emphasis on hero image and avatar. Developers will be able to take advantage of the new templates with minimal adjustments in their code.
  
  
  
• Bundled notifications: The system can group messages together, for example by message topic, and display the group. A user can take actions, such as Dismiss or Archive, on them in place. If you’ve implemented notifications for Android Wear, you’ll already be familiar with this model.
  
  
  
• Direct reply: For real-time communication apps, the Android system supports inline replies so that users can quickly respond to an SMS or text message directly within the notification interface.
  
  
  
• Custom views: Two new APIs enable you to leverage system decorations, such as notification headers and actions, when using custom views in notifications.
  
  
  
  
  
  

**Figure 2**. Bundled notifications and direct reply. > To learn how to implement the new features, see the [Notifications](http://developer.android.com/preview/features/notification-updates.html) guide.

Android Nで、我々は通知をより容易で早く使えるように再設計しました。　変更のいくつかは次のとおりです：

• テンプレートの更新：我々は主役の画像とアバターに重点を置くため、通知テンプレートを更新しました。　開発者は最小限のコード修正で新しいテンプレートを利用できるようになります。
  
  
  
• まとめられた通知：システムはメッセージを(例えばトピックにより)グループ化でき、そのグループを表示できます。　ユーザーはその場で消去または保存のようなアクションを行うことが出来ます。　もしAndroid Wear向け通知を実装しているなら、あなたはすでにこのモデルに慣れているでしょう。
  
  
  
• ダイレクトな応答：リアルタイムでコミュニケーションするアプリ向けに、ユーザーが通知インターフェース内ですばやくSMSやテキストメッセージに応答できるようにするため、Androidシステムはインライン応答をサポートします。
  
  
  
• カスタムビュー：通知内でカスタムビューを使用するとき、二つの新しいAPIが、通知ヘッダやアクションなどのシステムの装飾を可能にします。
  
  
  
  
  
  

**Figure 2**. まとめられた通知とダイレクトな応答

この新機能の実装方法についてより学ぶには、Notifications guideを参照してください。

Profile-guided JIT/AOT compilation

In Android N, we've added a Just in Time (JIT) compiler with code profiling to ART, which lets it constantly improve the performance of Android apps as they run. The JIT compiler complements ART's current Ahead of Time (AOT) compiler and helps improve runtime performance, save storage space, and speed up app updates and system updates.

Profile-guided compilation lets ART manage the AOT/JIT compilation for each app according to its actual usage, as well as conditions on the device. For example, ART maintains a profile of each app's hot methods and can precompile and cache those methods for best performance. It leaves other parts of the app uncompiled until they are actually used.

Besides improving performance for key parts of the app, profile-guided compilation helps reduce an app's overall RAM footprint, including associated binaries. This feature is especially important on low-memory devices.

ART manages profile-guided compilation in a way that minimizes impact on the device battery. It does precompilation only when then the device is idle and charging, saving time and battery by doing that work in advance.

Android Nで我々はART向けコードプロファイリングを含むJust in Time (JIT)コンパイラを追加しました。　それはAndroidアプリが実行している間、絶えずパフォーマンスを向上します。　JITコンパイラはARTの現行のAhead of Time (AOT)コンパイラを補完し、実行時のパフォーマンスの改善、ストレージ容量の節約、アプリの更新とシステムの更新のスピードアップに役立ちます。

プロファイルに基づくコンパイルは、ARTに各アプリのAOT/JITコンパイルをデバイスのコンディションと実際の使用状況に応じて管理させます。　例えば、ARTは各アプリのよく使われるメソッドのプロファイルを保持し、プリコンパイルし、最適なパフォーマンスを得るために、それらのメソッドをキャッシュすることができます。　それはアプリの他の部分を、それらが実際に使用されるまで、コンパイルしないまま残します。

アプリの主要なパーツのパフォーマンスを向上させることに加えて、プロファイルに基づくコンパイルは、関連するバイナリを含めアプリの全体的なメモリ使用量の縮小に役立ちます。　 この機能は、特にメモリの少ないデバイスで重要です。

ARTは、デバイスのバッテリーへの影響を最小限に抑える方法で、プロファイルに基づくコンパイルを行います。　それはデバイスがアイドル状態で充電しているときのみプリコンパイルを行い、あらかじめその処理を行うことにより時間とバッテリーを節約します。

Quick path to app install

One of the most tangible benefits of ART's JIT compiler is the speed of app installs and system updates. Even large apps that required several minutes to optimize and install in Android 6.0 can now install in just a matter of seconds. System updates are also faster, since there's no more optimizing step.

ARTのJITコンパイラの最も具体的なメリットの一つは、アプリのインストールやシステム更新の速度です。　Android 6.0では最適化とインストールに数分かかるほどの大きなアプリでも、これからは数秒でインストールできます。　最適化のステップが無いので、システム更新もまた高速になります。

Doze on the go...

Android 6.0 introduced Doze, a system mode that saves battery by deferring apps' CPU and network activities when the device is idle, such as when it's sitting on a table or in a drawer.

Now in Android N, Doze takes a step further and saves battery while on the go. Any time the screen is off for a period of time and the device is unplugged, Doze applies a subset of the familiar CPU and network restrictions to apps. This means users can save battery even when carrying their devices in their pockets.



Figure 3. Doze now applies restrictions to improve battery life even when the device is not stationary.

A short time after the screen turns off while the device is on battery, Doze restricts network access and defers jobs and syncs. During brief maintenance windows, applications are allowed network access and any of their deferred jobs/syncs are executed. Turning the screen on or plugging in the device brings the device out of Doze.

When the device is stationary again, with screen off and on battery for a period of time, Doze applies the full CPU and network restrictions on PowerManager.WakeLock, AlarmManager alarms, and GPS/Wi-Fi scans.

The best practices for adapting your app to Doze are the same whether the device is moving or not, so if you already updated your app to gracefully handle Doze, you're all set. If not, start adapting your app to Doze now.

Android 6.0はDozeを導入しました。　それはデバイスがテーブルの上や引き出しの中に置かれているときなどのアイドル状態のときに、アプリのCPUとネットワーク処理を延期することによりバッテリーを節約するシステムモードです。

Android NではDozeはさらに進化し、外出中でもバッテリーを節約します。　Dozeは画面が一定期間消灯し、デバイスが充電中ではないときはいつでも、アプリに通常のCPUとネットワーク制限の一部を適用します。　これは、ユーザーがデバイスをポケットに入れて持ち運ぶ時もバッテリーを節約出来ることを意味します。

Figure 3. Dozeはこれからはデバイスが静止していないときでもバッテリ寿命を改善するため制限を適用します。

デバイスがバッテリーで動作しているとき、画面を消灯してしばらくすると、Dozeはネットワークアクセスを制限し、ジョブと同期を延期します。　短いメンテナンス時間帯に、アプリはネットワークアクセスが許可され、その延期されたジョブと同期は実行されます。　画面を点灯するか、デバイスを充電すると、デバイスはDoze状態から抜けます。

一定期間画面が消灯しバッテリーで動いていた状態で、デバイスが再び静止したとき、Dozeは完全なCPUとネットワーク制限をPowerManager.WakeLock, AlarmManagerのアラーム, GPS/Wi-Fiスキャンに適用します。

あなたのアプリをDozeに適合させるためのベストプラクティスは、デバイスが動いていても、いなくても同じです。　なので、あなたがすでにアプリをDozeをうまく扱うように更新していたならば、あなたはすべて対応済みです。　そうでなければ、アプリのDozeへの適合を始めてください。

Project Svelte: Background optimizations

Project Svelte is an ongoing effort to minimize RAM use by system and apps across the range of Android devices in the ecosystem. In Android N, Project Svelte is focused on optimizing the way apps run in the background.

Background processing is an essential part of most apps. When handled right, it can make your user experience amazing — immediate, fast, and context-aware. When not handled right, background processing can needlessly consume RAM (and battery) and affect system performance for other apps.

Since Android 5.0, JobScheduler has been the preferred way of performing background work in a way that's good for users. Apps can schedule jobs while letting the system optimize based on memory, power, and connectivity conditions. JobScheduler offers control and simplicity, and we want all apps to use it.

Another good option is GCMNetworkManager, part of Google Play Services, which offers similar job scheduling with compatibility across legacy versions of Android.

We're continuing to extend JobScheduler and GCMNetworkManager to meet more of your use cases — for example, in Android N you can now schedule background work based on changes in Content Providers. At the same time we're starting to deprecate some of the older patterns that can reduce system performance, especially on low-memory devices.

In Android N we're removing three commonly-used implicit broadcasts — CONNECTIVITY_ACTION, ACTION_NEW_PICTURE, and ACTION_NEW_VIDEO — since those can wake the background processes of multiple apps at once and strain memory and battery. If your app is receiving these, take advantage of the N Developer Preview to migrate to JobScheduler and related APIs instead.

Take a look at the Background Optimizations documentation for details.

Project Svelteは、エコシステム内の広範囲なAndroidデバイスにわたる、システムとアプリによるRAM使用量を最小化する進行中の試みです。　Android Nでは、Project Svelteはアプリのバックグラウンドでの実行方法の最適化に焦点を当てています。

バックグラウンド処理は、ほとんどのアプリにおいて重要な部分です。　正しく扱うとき、あなたのユーザーエクスペリエンスを素晴らしいもの(即座の、素早い、状況に応じた)にします。　正しく扱わないとき、バックグラウンド処理は無駄にRAM(とバッテリー)を消費し、他のアプリのシステムパフォーマンスに影響を与える可能性があります。

Android 5.0から、JobSchedulerはユーザーにとって良いという意味で、好ましいバックグラウンド処理の実行方法になっています。　アプリは、メモリ、電源、および接続状態を元にシステムを最適化させつつ、ジョブをスケジュールできます。　JobSchedulerは管理と容易さを提供します。　そして我々はすべてのアプリがそれを使うことを望みます。

もう一つの良いオプションは、Google Play Servicesの一部であるGCMNetworkManagerです。　これは、Androidの古いバージョンにも互換性がある類似のジョブスケジューリングを提供します。

我々はあなたのユースケースのより多くを満たすため、JobSchedulerとGCMNetworkManagerを拡張し続けています。　例えば、Android NではContent Providersの変化に基づいてバッググラウンド処理をスケジュールできます。　同時に、我々は（特にメモリの少ないデバイスで)システムパフォーマンスを低下させる可能性がある古いパターンの一部を廃止し始めています。

Android Nで、我々は３つの一般的に使われている暗黙のブロードキャスト(CONNECTIVITY_ACTION, ACTION_NEW_PICTURE, ACTION_NEW_VIDEO)を削除しています。　それらは一度に複数のアプリのバックグラウンドプロセスを起動し、メモリとバッテリーを切迫させる可能性があるからです。　あなたのアプリがこれらを受信している場合は、代わりにJobSchedulerと関連APIに移行するため、N Developer Previewを活用してください。

詳細については、Background Optimizationsを参照してください。

Data Saver

Figure 4. Data Saver in Settings.

Over the life of a mobile device, the cost of a cellular data plan typically exceeds the cost of the device itself. For many users, cellular data is an expensive resource that they want to conserve.

Android N introduces Data Saver mode, a new system service that helps reduce cellular data use by apps, whether roaming, near the end of the billing cycle, or on a small prepaid data pack. Data Saver gives users control over how apps use cellular data and lets developers provide more efficient service when Data Saver is on.

When a user enables Data Saver in Settings and the device is on a metered network, the system blocks background data usage and signals apps to use less data in the foreground wherever possible — such as by limiting bit rate for streaming, reducing image quality, deferring optimistic precaching, and so on. Users can whitelist specific apps to allow background metered data usage even when Data Saver is turned on.

Android N extends the ConnectivityManager to provide apps a way to retrieve the user's Data Saver preferences and monitor preference changes. All apps should check whether the user has enabled Data Saver and make an effort to limit foreground and background data usage.

Figure 4. Data Saver設定

モバイルデバイスの寿命を通して、一般的に携帯電話のデータプランのコストはデバイス自身のコストを超えています。　多くのユーザーにとって、携帯電話のデータは浪費したくない高価なリソースです。

Android NはData Saverモードを導入します。　これは、請求サイクルの終わり近くのローミングでも、少量のプリペイドデータパックでもアプリによる携帯電話のデータ使用を減らすのに役立つ新しいシステムサービスです。　Data Saverはアプリがどのように携帯電話のデータを使用するかの制御をユーザーに提供します。　そしてData Saverが有効なとき、開発者により効率的なサービスを提供させます。

ユーザーが設定画面でData Saverを有効にし、そしてデバイスが従量課金ネットワークを使用しているとき、システムはバックグラウンドのデータ使用をブロックし、フォアグラウンドのアプリに（ストリーミングのビットレートを制限したり、画像の品質を下げたり、楽観的な事前キャッシュを遅延させたりなどで)出来る限りデータ使用を少なくするようシグナルを送ります。　ユーザーはData Saverが有効の時でもバックグランドの従量課金データの使用を可能にするため、特定のアプリをホワイトリストに登録できます。

Android NはアプリがユーザーのData Saver設定を受け取り、設定変更をモニターする方法を提供するため、ConnectivityManagerを拡張します。　全てのアプリはユーザーがData Saverを有効にしているかどうかチェックし、フォアグラウンドとバックグラウンドのデータ使用を制限する努力をしなければなりません。

Quick Settings Tile API

Figure 5. Quick Settings tiles in the notification shade.

Quick Settings is a popular and simple way to expose key settings and actions, directly from the notification shade. In Android N, we've expanded the scope of Quick Settings to make it even more useful and convenient.

We've added more room for additional Quick Settings tiles, which users can access across a paginated display area by swiping left or right. We've also given users control over what Quick Settings tiles appear and where they are displayed — users can add or move tiles just by dragging and dropping them.

For developers, Android N also adds a new API that lets you define your own Quick Settings tiles to give users easy access to key controls and actions in your app.

Quick Settings tiles are reserved for controls or actions that are either urgently required or frequently used, and should not be used as shortcuts to launching an app.

Once you’ve defined your tiles, you can surface them to users, who can add them to Quick Settings just by drag and drop.

For information about creating an app tile, see the android.service.quicksettings.Tile in the downloadable API Reference.

Figure 5. 通知シェードのQuick Settingsタイル

Quick Settingsは通知シェードから直接主要な設定やアクションを見せる一般的でシンプルな方法です。　Android Nで我々はQuick Settingsの領域をさらに有益で便利にするため拡張してきました。

我々は追加のQuick Settingsタイル向けに、ユーザーが左右にスワイプすることで分割された表示エリアを横断してアクセスできる、さらなるスペースを追加しました。　また我々はユーザーにどのQuick Settingsタイルを表示するか、どこに表示するかについての管理権限を提供します。　ユーザーはタイルを単にドラッグ・アンド・ドロップすることにより、追加したり移動したり出来ます。

開発者向けに、Android Nはまた、ユーザーにあなたのアプリの主要なコントロールとアクションへの簡単なアクセスを提供するために、あなたが独自のQuick Settingsタイルを定義できる新しいAPIを追加しています。

Quick Settingsタイルは切実に必要とされている、または繰り返し使用されるコントロールまたはアクション向けに予約されており、アプリ起動のショートカットとして使用することはできません。

あなたがタイルを定義すると、あなたはユーザーにそれを見せることでき、ユーザーはそれを単にドラッグ・アンド・ドロップすることによりQuick Settingsに追加できます。

アプリのタイルの作成についての情報は、API Referenceのandroid.service.quicksettings.Tileを参照してください。

Number-blocking

Android N now supports number-blocking in the platform and provides a framework API to let service providers maintain a blocked-number list. The default SMS app, the default phone app, and carrier apps can read from and write to the blocked-number list. The list is not accessible to other apps.

By making number-blocking a standard feature of the platform, Android provides a consistent way for apps to support number-blocking across a wide range of devices. Among the other benefits that apps can take advantage of are:

• Numbers blocked on calls are also blocked on texts
  
  
  
• Blocked numbers can persist across resets and devices through the Backup & Restore feature
  
  
  
• Multiple apps can use the same blocked numbers list

Additionally, carrier app integration through Android means that carriers can read the blocked numbers list on the device and perform service-side blocking for the user in order to stop unwanted calls and texts from reaching the user through any medium, such as a VOIP endpoint or forwarding phones.

For more information, see android.provider.BlockedNumberContract in the downloadable API Reference.

Android Nはプラットフォームでnumber-blockingをサポートし、サービスプロバイダがblocked-numberリストをメンテナンスするためのフレームワークAPIを提供します。　デフォルトのSMSアプリ、デフォルトの電話アプリ、キャリアのアプリがblocked-numberリストを読み書きできます。　このリストは他のアプリからは利用可能ではありません。

number-blockingをプラットフォームの標準機能にすることにより、Androidはアプリが多くのデバイスを横断してnumber-blockingをサポートする一貫した方法を提供します。　アプリが活用できるその他の利点：

• 通話でブロックされた番号はテキストでもブロックされます。
  
  
  
• ブロックされた番号はバックアップと復元機能により、リセットやデバイス間を超えて保持されます。
  
  
  
• 複数のアプリが同じblocked numbersリストを使用できます。

また、Androidを介したキャリアアプリの統合は、キャリアがデバイス上のblocked numbersリストを読め、ユーザーに対し不必要な着信やテキストがユーザーに届くことをとめるため、(VOIPエンドポイントや転送電話などの)メディアによって、サービスサイドでブロッキングが出来ることを意味します。

より詳しくは、API Referenceのandroid.provider.BlockedNumberContractを参照してください。

Call screening

Android N allows the default phone app to screen incoming calls. The phone app does this by implementing the new CallScreeningService, which allows the phone app to perform a number of actions based on an incoming call's Call.Details, such as:

• Reject the incoming call
  
  
  
• Do not allow the call to the call log
  
  
  
• Do not show the user a notification for the call

For more information, see android.telecom.CallScreeningService in the downloadable API Reference.

Android Nでデフォルトの電話アプリは、着信を選別できます。　電話アプリは新しいCallScreeningServiceの実装によりこれを行います。　それは電話アプリに着信のCall.Detailsをもとに、次のようないくつかのアクションの実行を可能にさせます：

• 着信を拒否する
  
  
  
• 通話履歴への記録を許可しない
  
  
  
• 着信通知をユーザーに表示しない

より詳しくはAPI Referenceのandroid.telecom.CallScreeningServiceを参照してください。

Multi-locale support, more languages

Android N now lets users select multiple locales in Settings, to better support bilingual use-cases. Apps can use a new API to get the user's selected locales and then offer more sophisticated user experiences for multi-locale users — such as showing search results in multiple languages and not offering to translate webpages in a language the user already knows.

Along with multi-locale support, Android N also expands the range of languages available to users. It offers more than 25 variants each for commonly used languages such as English, Spanish, French, and Arabic. It also adds partial support for more than 100 new languages.

Apps can get the list of locales set by the user by calling LocaleList.GetDefault(). To support the expanded number of locales, Android N is changing the way that it resolves resources. Make sure that you test and verify that your apps working as expected with the new resource resolution logic.

To learn about the new resource-resolution behavior and the best practices you should follow, see Multilingual Support.

Android Nでは、より良い二か国語の併用をサポートするために、ユーザーが設定で複数のロケールを選択することができます。　アプリはユーザーが選択したロケールを取得するため、新しいAPIを使用することが出来ます。　そして、マルチロケールユーザー向けに（複数言語による検索結果の表示や、ユーザーがすでに知っている言語ではウェブページの翻訳を提供しないなどの)より高度なユーザーエクスペリエンスを提供できます。

マルチロケールのサポートに加え、Android Nはまた、ユーザーが利用可能な言語の範囲を拡大します。　それは、英語、スペイン語、フランス語、アラビア語などの一般的に使われている言語の２５以上の派生形を提供します。　また、１００以上の新しい言語のための部分的なサポートも追加されています。

アプリはLocaleList.GetDefault()を呼び出すことにより、ユーザーが設定したロケールのリストを取得できます。　拡張された多数のロケールをサポートするため、Android Nはリソース解決の方法を変更しています。　あなたのアプリが新しいリソース解決ロジックで期待通り動作していることをテストし、検証してください。

新しいリソース解決の動作についてと、あなたがすべきベストプラクティスについては、Multilingual Supportを参照してください。

ICU4J APIs in Android

Android N now offers a subset of ICU4J APIs in the Android framework under the android.icu package. Migration is easy, and mostly entails simply changing from the com.java.icu namespace to android.icu. If you are already using an ICU4J bundle in your apps, switching to the android.icu APIs provided in the Android framework can produce substantial savings in APK size.

To learn more about the Android ICU4J APIs, see ICU4J Support.

Android NはAndroidフレームワークのandroid.icuパッケージでICU4J APIsのサブセットを提供しています。　移行は容易です。　大部分は単にcom.java.icuネームスペースからandroid.icuへの変更です。　もしあなたがすでにアプリにICU4Jを同梱して使用しているなら、Androidフレームワークで提供されているandroid.icu APIsへの切替はAPKサイズの大幅な節約になります。

AndroidのICU4J APIsについてより詳しくはICU4J Supportを参照してください。

OpenGL™ ES 3.2 API

Android N adds framework interfaces and platform support for OpenGL ES 3.2, including:

• All extensions from the Android Extension Pack (AEP) except for EXT_texture_sRGB_decode.
  
  
  
• Floating-point framebuffers for HDR and deferred shading.
  
  
  
• BaseVertex draw calls to enable better batching and streaming.
  
  
  
• Robust buffer access control to reduce WebGL overhead.

The framework API for OpenGL ES 3.2 on Android N is provided with the GLES32 class. When using OpenGL ES 3.2, be sure to declare the requirement in your manifest file, using the <uses-feature> tag and the android:glEsVersion attribute.

For information about using OpenGL ES, including how to check a device's supported OpenGL ES version at runtime, see the OpenGL ES API guide.

Android NはOpenGL ES 3.2のフレームワークインターフェースとプラットフォームサポートを追加します。　それは次を含みます：

• EXT_texture_sRGB_decodeを除くAndroid Extension Pack (AEP)の全ての拡張機能
  
  
  
• HDRと遅延シェーディング向け浮動小数点フレームバッファ
  
  
  
• より良いバッチ処理とストリーミングを可能にするBaseVertexドローコール
  
  
  
• WebGLのオーバーヘッドを低減する強力なバッファーアクセスコントロール

Android NのOpenGL ES 3.2向けフレームワークAPIにはGLES32クラスがあります。　OpenGL ES 3.2を使用するときは、必ず<uses-feature>タグとandroid:glEsVersion属性を使用してマニフェストファイルに要件を宣言してください。

OpenGL ESの使用方法についてより詳しくは（デバイスがサポートするOpenGL ESバージョンの実行時のチェック方法も含め)、OpenGL ES API guideを参照してください。

Android TV recording

Android N adds the ability to record and playback content from Android TV input services via new recording APIs. Building on top of existing time-shifting APIs, TV input services can control what channel data can be recorded, how recorded sessions are saved, and manage user interaction with recorded content.

For more information, see Android TV Recording APIs.

Android Nは、新しいレコーディングAPIによって、Android TV入力サービスからコンテンツを録画し、再生する機能を追加します。　既存のタイムシフトAPI上に構築されたTV入力サービスは、どのチャンネルデータが録画できるかと、録画セッションがどのように保存されるかをコントロールでき、録画されたコンテンツとのユーザーインタラクションを管理出来ます。

より詳しくは、Android TV Recording APIsを参照してください。

Android for Work

Android for Work adds many new features and APIs for devices running Android N. Some highlights are below — for a complete list of changes, see Android for Work updates.

Android for WorkはAndroid Nで多くの新機能とAPIを追加しました。
いくつかのハイライトは下記の通りです。　(変更点の完全なリストについてはAndroid for Work Updatesを参照してください)

Work profile security challenge

Profile owners can specify a separate security challenge for apps running in the work profile. The work challenge is shown when a user attempts to open any work apps. Successful completion of the security challenge unlocks the work profile and decrypts it if necessary. For profile owners, ACTION_SET_NEW_PASSWORD prompts the user to set a work challenge, and ACTION_SET_NEW_PARENT_PROFILE_PASSWORD prompts the user to set a device lock.

Profile owners can set distinct password policies for the work challenge (such as how long the PIN needs to be, or whether a fingerprint can be used to unlock the profile) using the setPasswordQuality(), setPasswordMinimumLength() and related methods. The profile owner can also set the device lock using the DevicePolicyManager instance returned by the new getParentProfileInstance() method. Additionally, profile owners can customize the credentials screen for the work challenge using the new setOrganizationColor() and setOrganizationName() methods.

プロファイル所有者は、ワークプロファイルで実行しているアプリに個別のセキュリティチャレンジを指定できます。　ワークチャレンジは、ユーザーが任意のワークアプリを開こうとしたとき表示されます。　セキュリティチャレンジの成功は、ワークプロファイルをアンロックし、必要であれば暗号化を解除します。　プロファイル所有者のACTION_SET_NEW_PASSWORDはユーザーにワークチャレンジを設定することを促します。　またACTION_SET_NEW_PARENT_PROFILE_PASSWORDはユーザーにデバイスロックを設定するよう促します。

プロファイル所有者は、setPasswordQuality()やsetPasswordMinimumLength()や関連するメソッドを使って、(どれだけの長さのPINが必要か、または指紋がプロファイルのアンロックに使えるかどうかなどの)ワークチャレンジ向けの個別のパスワードポリシーを設定できます。　プロファイル所有者はまた、新しいgetParentProfileInstance()メソッドで返されるDevicePolicyManagerインスタンスを使用してデバイスロックを設定できます。　さらに、プロファイル所有者は新しいsetOrganizationColor()とsetOrganizationName()メソッドを使ってワークチャレンジの認証画面をカスタマイズできます。

Turn off work

On a device with a work profile, users can toggle work mode. When work mode is off the managed user is temporarily shut down, which disables work profile apps, background sync, and notifications. This includes the profile owner application. When work mode is off, the system displays a persistent status icon to remind the user that they can't launch work apps. The launcher indicates that work apps and widgets are not accessible.

ワークプロファイルのあるデバイスで、ユーザーはワークモードを切り替えることが出来ます。　ワークモードがオフのとき、管理されたユーザーは一時的にシャットダウンされます。　それにより、ワークプロファイルのアプリ、バックグラウンド同期、通知が無効になります。　これはプロファイル所有者のアプリを含みます。　ワークモードがオフのとき、システムはユーザーにワークアプリが起動できないことを気づかせるため、永続的なステータスアイコンを表示します。　ランチャーはワークアプリやウィジェットがアクセスできないことを示します。

Always on VPN

Device owners and profile owners can ensure that work apps always connect through a specified VPN. The system automatically starts that VPN after the device boots.

New DevicePolicyManager methods are setAlwaysOnVpnPackage() and getAlwaysOnVpnPackage().

Because VPN services can be bound directly by the system without app interaction, VPN clients need to handle new entry points for Always on VPN. As before, services are indicated to the system by an intent filter matching action android.net.VpnService.

Users can also manually set Always on VPN clients that implement VPNService methods in the primary user using Settings>More>Vpn.

デバイス所有者とプロファイル所有者は、ワークアプリが常に指定されたVPNを通じて接続することを保証できます。　システムはデバイスの起動後に自動的にそのVPNを開始します。

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

VPNサービスは、システムによってアプリの操作なしに直接接続されるで、VPNクライアントは常時VPN上として新しいエントリポイントを扱う必要があります。　前と同じように、サービスはandroid.net.VpnServiceアクションにマッチするインテントフィルターによってシステムに示されます。

ユーザーはまた、いつでもプライマリユーザーで手動でSettings>More>VpnでVPNServiceメソッドを実装するVPNクライアントを設定できます。

Accessibility enhancements

Android N now offers Vision Settings directly on the Welcome screen for new device setup. This makes it much easier for users to discover and configure accessibility features on their devices, including magnification gesture, font size, display size, and TalkBack.

With these accessibility features getting more prominent placement, your users are more likely to try your app with them enabled. Make sure you test your apps early with these settings enabled. You can enable them from Settings > Accessibility.

Also in Android N, accessibility services can now help users with motor impairments to touch the screen. The new API allows building services with features such as face-tracking, eye-tracking, point scanning, and so on, to meet the needs of those users.

For more information, see android.accessibilityservice.GestureDescription in the downloadable API Reference.

Android Nは視覚設定を直接新しいデバイスのセットアップのウエルカム画面で提供します。　これはユーザーにとって、彼らのデバイス上で（拡大ジェスチャー、フォントサイズ、表示サイズ、音声応答を含む)アクセシビリティ機能の発見と設定をより簡単にします。

これらのアクセシビリティ機能をより目立つようにすると、ユーザーはそれらを有効にしてあなたのアプリを試す可能性が高くなります。　早くそれらの設定を有効にして、あなたのアプリをテストしてください。　Settings > Accessibilityでそれらを有効にできます。

またAndroid Nでアクセシビリティサービスは、運動障害を持つユーザーが画面をタッチするのを助けることができます。　それらのユーザーのニーズを満たすために、新しいAPIはフェイストラッキングやアイトラッキングやポイントスキャンなどの機能をつかったサービスの構築を可能にします。

より詳しくは、API Referenceのandroid.accessibilityservice.GestureDescriptionを参照してください。

Direct boot

Direct boot improves device startup times and lets registered apps have limited functionality even after an unexpected reboot. For example, if an encrypted device reboots while the user is sleeping, registered alarms, messages and incoming calls can now continue notify the user as normal. This also means accessibility services can also be available immediately after a restart.

Direct boot takes advantage of file based encryption in Android N to enable fine grained encryption policies for both system and app data. The system uses a device-encrypted store for select system data and explicitly registered app data. By default a credential-encrypted store is used for all other system data, user data, apps, and app data.

At boot, the system starts in a restricted mode with access to device-encrypted data only, and without general access to apps or data. If you have components that you want to run in this mode, you can register them by setting a flag in the manifest. After restart, the system activates registered components by broadcasting the LOCKED_BOOT_COMPLETED intent. The system ensures registered device-encrypted app data is available before unlock. All other data is unavailable until the User confirms their lock screen credentials to decrypt it.
For more information, see Direct Boot.

下記は内容があやしいです。　てくぶ様、公式の詳細をご確認ください。 m(_ _)m

ダイレクトブートはデバイスの起動時間を改善し、予期しない再起動のあとでも、登録されたアプリに限定的な機能を持たせます。　例えば、ユーザーが寝ている間に暗号化されたデバイスがリブートした場合、登録されたアラーム、メッセージ、着信は通常通りユーザーに通知し続けることが出来ます。　これはまた、アクセシビリティのサービスも再起動後にすぐに利用可能であることを意味します。

ダイレクトブートはAndroid Nでシステムとアプリデータに対し、細かい粒度の暗号化ポリシーを可能にするため、ファイルベースの暗号化を利用しています。　システムは、システムデータと明示的に登録されたアプリデータを選択するため、デバイス暗号化ストアを使用します。　デフォルトで認証暗号化ストアはその他の全てのシステムデータ、ユーザーデータ、アプリデータに使用されます。

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

より詳しくは、Direct Bootを参照してください。

Key Attestation

Hardware-backed keystores provide a much safer method to create, store, and use cryptographic keys on Android devices. They protect keys from the Linux kernel, potential Android vulnerabilities, and extraction from rooted devices.

To make it easier and more secure to use hardware-backed keystores, Android N introduces Key Attestation. Apps and off-devices can use Key Attestation to strongly determine whether an RSA or EC key pair is hardware-backed, what the properties of the key pair are, and what constraints are applied to its usage and validity.

Apps and off-device services can request information about a key pair through an X.509 attestation certificate which must be signed by a valid attestation key. The attestation key is an ECDSA signing key which is injected into the device’s hardware-backed keystore at the factory. Therefore, an attestation certificate signed by a valid attestation key confirms the existence of a hardware-backed keystore, along with details of key pairs in that keystore.

To ensure that the device is using a secure, official Android factory image, Key Attestation requires that the device bootloader provide the following information to the Trusted Execution Environment (TEE):

• The OS version and patch level installed on the device
  
  
  
• The Verified Boot public key and lock status

For more information about the hardware-backed keystore feature, see the guide for Hardware-backed Keystore.

In addition to Key Attestation, Android N also introduces fingerprint-bound keys that are not revoked on fingerprint enrollment.

ハードウェア支援されたキーストアは、Androidデバイスで暗号化キーを作成し、保存し、使用するためのより安全なメソッドを提供します。　それは、Linuxカーネル、潜在的なAndroidの脆弱性、ルート化されたデバイスからの抽出から、キーを保護します。

ハードウェア支援されたキーストアの使用をより簡単に、またよりセキュアにするため、Android NはKey Attestationを導入します。　アプリとoff-devicesは、RSAまたはECキーペアがハードウェア支援されるかどうか、キーペアのプロパティは何か、その使用と有効性にどのような制約を適用するか、を判断するため、Key Attestationを使用できます。

アプリとoff-deviceサービスは、キーペアについての情報を、有効な認証キーによって署名されているX.509認証証明書を介して、要求できます。　認証キーは、工場出荷時にハードウェア支援されたキーストアに入れられたECDSA署名キーです。　したがって、有効な認証キーで署名されている認証証明書は、そのキーストア内のキーペアの詳細とともに、ハードウェア支援されたキーストアの存在を証明します。

デバイスがセキュアな公式のAndroidファクトリイメージを使用していること保証するため、Key Attestationはデバイスブートローダーが下記の情報をTrusted Execution Environment (TEE)に提供することが必要です。

• デバイスにインストールされているOSのバージョンとパッチレベル
  
  
  
• 検証済みの起動公開鍵と、ロックステータス

ハードウェア支援されたキーストアの機能についてより詳しくは、Hardware-backed Keystoreを参照してください。

Key Attestationに加えて、Android Nはまた指紋登録に取り消されていない指紋連動キーを導入します。

Network Security Config

In Android N, apps can customize the behavior of their secure (HTTPS, TLS) connections safely, without any code modification, by using the declarative Network Security Config instead of using the conventional error-prone programmatic APIs (e.g. X509TrustManager).

Supported features:

• Custom trust anchors. Lets an application customize which Certificate Authorities (CA) are trusted for its secure connections. For example, trusting particular self-signed certificates or a restricted set of public CAs.
  
  
  
• Debug-only overrides. Lets an application developer safely debug secure connections of their application without added risk to the installed base.
  
  
  
• Cleartext traffic opt-out. Lets an application protect itself from accidental usage of cleartext traffic.
  
  
  
• Certificate pinning. An advanced feature that lets an application limit which server keys are trusted for secure connections.

For more information, see Network Security Config.

Android Nでは、アプリはコード修正なしに、(例えば、X509TrustManagerのような)従来のエラーが発生しやすいプログラムAPIの代わりに、宣言的ネットワークセキュリティ設定を使うことにより、安全にセキュアな接続(HTTPS, TLS)の動作をカスタマイズできます。

サポートされる機能：

• カスタムトラストアンカー。 アプリに、自身のセキュアな接続のため、どの認証局(CA)が信頼されているかをカスタマイズさせます。　例えば、特定の自己署名証明書またはパブリックCAの制限されたセットを信頼します。
  
  
  
• デバッグ時のみ上書き。　インストールベースにリスクを加えることなく、アプリ開発者に安全にアプリのセキュアな接続をデバッグさせます。
  
  
  
• 平文通信の拒否。　アプリに、過失による平文通信から保護させます。
  
  
  
• 証明書のピンニング。　アプリに、どのサーバーキーがセキュアな接続向けに信頼できるかを限定させる高度な機能。

より詳しくは、Network Security Configを参照してください。

Default Trusted Certificate Authority

By default, apps that target Android N only trust system-provided certificates and no longer trust user-added Certificate Authorities (CA). Apps targeting Android N that wish to trust user-added CAs should use the Network Security Config to specify how user CAs should be trusted.

デフォルトでは、Android Nを対象にしたアプリはシステムが提供した証明書だけを信頼します。　そしてもはやユーザーが追加した認証局(CA)は信用しません。　ユーザーが追加したCAを信頼したいAndroid Nを対象にしたアプリは、ユーザーのCAがどのように信頼されるべきかを指定するため、Network Security Configを使わなくてはなりません。

APK signature scheme v2

The PackageManager class now supports verifying apps using the APK signature scheme v2. The APK signature scheme v2 is a whole-file signature scheme that significantly improves verification speed and strengthens integrity guarantees by detecting any unauthorized changes to APK files.

To maintain backward-compatibility, an APK must be signed with the v1 signature scheme (JAR signature scheme) before being signed with the v2 signature scheme. With the v2 signature scheme, verification fails if you sign the APK with an additional certificate after signing with the v2 scheme.

APK signature scheme v2 support will be available later in the N Developer Preview.

PackageManagerクラスはAPK署名スキームv2を使ったアプリの検証をサポートします。　APK署名スキームv2は、大幅に検証速度を改善し、APKファイルに対する不正な変更を検出することで整合性の保証を強化した、ファイル全体の署名スキームです。

下位互換性を維持するために、APKはv2署名スキームで署名される前に、v1署名スキーム(JAR署名スキーム)で署名されなければなりません。　v2署名スキームでは、もしv2スキームで署名した後に、APKに追加の証明書で署名すると、検証は失敗します。

APK署名スキームv2は、後日N Developer Previewで利用可能になります。

Scoped directory access

In Android N, apps can use new APIs to request access to specific external storage directories, including directories on removable media such as SD cards. The new APIs greatly simplify how your application accesses standard external storage directories, such as the Pictures directory. Apps like photo apps can use these APIs instead of using READ_EXTERNAL_STORAGE, which grants access to all storage directories, or the Storage Access Framework, which makes the user navigate to the directory.

Additionally, the new APIs simplify the steps a user takes to grant external storage access to your app. When you use the new APIs, the system uses a simple permissions UI that clearly details what directory the application is requesting access to.

For more information, see the Scoped Directory Access developer documentation.

Android Nでは、アプリは（SDカードのような取り外しできるメディア上のディレクトリを含む)特定の外部ストレージのディレクトリへのアクセスを要求するために、新しいAPIを使えます。　新しいAPIは、あなたのアプリの(ピクチャディレクトリのような)標準的な外部ストレージのディレクトリへのアクセス方法を、大幅に簡素化します。　写真アプリのようなアプリは、READ_EXTERNAL_STORAGEを使う代わりに、これらのAPIを使用できます。　これは、全てのストレージのディレクトリ、またはディレクトリへユーザーをナビゲートをするストレージアクセスフレームワークへのアクセスを許可します。

加えて、新しいAPIはユーザーがあなたのアプリに外部ストレージへのアクセスを許可するのにかかるステップを簡素化します。　新しいAPIを使用すると、システムはアプリがアクセスを要求しているディレクトリがどれかを明確に示すシンプルなパーミッションUIを使います。

より詳しくは、Scoped Directory Accessを参照してください。