Android N PreviewのBehavior Changesを翻訳してみました。

まってれば公式が対応してくれるのではないかという気もしますが・・・
おかしな部分があればコメント頂ければと思います。

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

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

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

Behavior Changes

Along with new features and capabilities, Android N includes a variety of system and API behavior changes. This document highlights some of the key changes that you should understand and account for in your apps.

If you have previously published an app for Android, be aware that your app might be affected by these changes in the platform.

新機能に加え、Android Nは多様なシステムとAPIの変更点を含みます。　このドキュメントはあなたが理解し、アプリに含むべきいくつかの重要な変更点を示します。

もしあなたが以前にAndroidアプリを公開している場合、あなたのアプリがこのプラットフォームでこれらの変更による影響を受けるかもしれないことに注意してください。

Performance Improvements

Android N contains system behavior changes aimed at improving the battery life of devices, RAM usage, and app performance. These changes can impact the availability of system resources and system notifications to your app. You should review these changes and evaluate how your app may need to adjust to them.

Android Nはデバイスのバッテリ寿命、RAM使用量、アプリのパフォーマンスの改良を目的としたシステムの動作変更を含みます。　これらの変更はあなたのアプリのシステムリソースとシステム通知の可用性に影響を与える可能性があります。　あなたはこれらの変更を確認し、どのようにあなたのアプリがそれらに合わせる必要があるのか判断すべきです。

Doze

Introduced in Android 6.0 (API level 23), Doze improves battery life by deferring CPU and network activities when a user leaves a device unplugged, stationary, and with the screen turned off. Android N brings further enhancements to Doze by applying a subset of CPU and network restrictions while the device is unplugged with the screen turned off, but not necessarily stationary, for example, when a handset is traveling in a user’s pocket.

Figure 1. Illustration of how Doze applies a first level of system activity restrictions to improve battery life.

When a device is on battery power, and the screen has been off for a certain time, the device enters Doze and applies the first subset of restrictions: It shuts off app network access, and defers jobs and syncs. If the device is stationary for a certain time after entering Doze, the system applies the rest of the Doze restrictions to PowerManager.WakeLock, AlarmManager alarms, GPS, and Wi-Fi scans. Regardless of whether some or all Doze restrictions are being applied, the system wakes the device for brief maintenance windows, during which applications are allowed network access and can execute any deferred jobs/syncs.

Figure 2. Illustration of how Doze applies a second level of system activity restrictions after the device is stationary for a certain time.

Note that activating the screen on or plugging in the device exits Doze and removes these processing restrictions. The additional behavior does not affect recommendations and best practices in adapting your app to the prior version of Doze introduced in Android 6.0 (API level 23), as discussed in Optimizing for Doze and App Standby. You should still follow those recommendations, such as using Google Cloud Messaging (GCM) to send and receive messages, and start planning updates to accomodate the additional Doze behavior.

Android 6.0 (API level 23)で導入されたDozeは、充電せず、静止させ、画面を消灯した状態でユーザーがデバイスから離れたときにCPUとネットワーク使用を遅延させることでバッテリ寿命を改善します。　Android Nはスマホがポケットに入れられて移動している場合などの充電しておらず、画面が消灯しており、しかし必ずしも静止していない期間に、CPUとネットワークに対する制限のサブセットを適用することで、Dozeに更なる機能強化をもたらします。

Figure 1. Dozeがバッテリ寿命を改善するためにどのようにシステム活動制限の一段階目を適用させるかのイラスト。

デバイスがバッテリ駆動中で一定期間画面が消灯しているとき、デバイスはDoze状態になり、制限の最初のサブセットが適用されます：これは、アプリのネットワークアクセスを遮断し、ジョブと同期を延期します。

Doze状態になった後一定期間デバイスが静止した場合、システムはDoze制限の残りの部分を
PowerManager.WakeLock, AlarmManager alarms, GPS, Wi-Fiスキャンに適用します。　Doze制限の一部または全部が適用中かどうかに関係なく、システムはアプリがネットワークアクセスを許可され、延期されたジョブと同期を実行できる短いメンテナンス時間のためデバイスを起こします。

Figure 2. Dozeが一定期間デバイスが静止した後に、どのようにシステム活動制限の二段階目を適用させるかのイラスト。

画面を点灯するかデバイスを充電すると、Doze状態を抜けてこれらの制限が無くなることに注意してください。　この追加の動作は、DozeとApp Standbyへの最適化で解説された、Android 6.0 (API level 23)で導入された前バージョンのDozeにあなたのアプリを適合させる推奨方法とベストプラクティスに影響しません。　あなたは今後もメッセージの送受信にGoogle Cloud Messaging (GCM)を利用するなどのそれらの推奨方法に従うべきです。　そしてDozeの追加の動作に適合するためのアップデートの企画を始めるべきです。

Project Svelte: Background Optimizations

Android N removes three implicit broadcasts in order to help optimize both memory use and power consumption. This change is necessary because implicit broadcasts frequently start apps that have registered to listen for them in the background. Removing these broadcasts can substantially benefit device performance and user experience.

Mobile devices experience frequent connectivity changes, such as when moving between Wi-Fi and mobile data. Currently, apps can monitor for changes in connectivity by registering a receiver for the implicit CONNECTIVITY_ACTION broadcast in their manifest. Since many apps register to receive this broadcast, a single network switch can cause them all to wake up and process the broadcast at once.

Similarly, apps can register to receive implicit ACTION_NEW_PICTURE and ACTION_NEW_VIDEO broadcasts from other apps, such as Camera. When a user takes a picture with the Camera app, these apps wake up to process the broadcast.

To alleviate these issues, Android N applies the following optimizations:

Apps targeting Android N do not receive CONNECTIVITY_ACTION broadcasts, even if they have manifest entries to request notification of these events. Apps running in the foreground can still listen for CONNECTIVITY_CHANGE on their main thread if they request notification with a BroadcastReceiver.
Apps cannot send or receive ACTION_NEW_PICTURE or ACTION_NEW_VIDEO broadcasts. This optimization affects all apps, not only those targeting Android N.

In general, apps should remove dependence on manifest-declared receivers for implicit broadcasts as well as on background services.

The Android framework provides several solutions to mitigate the need for these implicit broadcasts or background services. For example, the JobScheduler API provides a robust mechanism to schedule network operations when specified conditions, such as connection to an unmetered network, are met. You can even use JobScheduler to react to changes to content providers.

For more information about this behavior change and how to adapt your app, see Background Optimizations.

Android Nはメモリ使用と電力消費の両方を最適化するため３つの暗黙のブロードキャストを削除します。　バックグラウンドで暗黙のブロードキャストがそれらをリッスンするように登録したアプリを繰り返し起動するため、この変更は必要です。　これらのブロードキャストの削除は、デバイスのパフォーマンスとユーザーエクスペリエンスに実質的に役立ちます。

モバイルデバイスは、Wi-Fiとモバイルデータ間の切替時のように頻繁に接続の変更があります。　現在、アプリはマニフェストに暗黙のCONNECTIVITY_ACTIONブロードキャストのレシーバーを登録することにより、接続の変更を監視できます。　多くのアプリがこのブロードキャストの受信を登録しているため、１つのネットワーク切替がそれらすべてが起動して同時にブロードキャストを処理する原因となります。

同様に、アプリはカメラなどの他のアプリからの暗黙のACTION_NEW_PICTUREとACTION_NEW_VIDEOブロードキャストの受信を登録できます。　ユーザーがカメラアプリで撮影したとき、これらのアプリはブロードキャストを処理するために起動します。

これらの問題を軽減するため、Android Nは下記の最適化をします：

Android Nを対象としたアプリは、それらのイベント通知を要求するマニフェストの記載があっても、CONNECTIVITY_ACTIONブロードキャストを受け取りません。　フォアグラウンドで実行しているアプリは、BroadcastReceiverで通知を要求した場合、引き続きメインスレッドでCONNECTIVITY_CHANGEを受信できます。
アプリはACTION_NEW_PICTUREまたはACTION_NEW_VIDEOブロードキャストを送信または受信できません。　この最適化はAndroid Nを対象としたアプリだけでなく、すべてに影響します。

一般的には、アプリはマニフェストに記載された暗黙のブロードキャストレシーバーとバックグラウンドサービスへの依存を取り除くべきです。

Androidのフレームワークは、これらの暗黙のブロードキャストやバックグラウンドサービスの必要性を軽減するために、いくつかのソリューションを提供しています。　例えば、JobScheduler APIは、定額ネットワークへの接続のようなある条件下のネットワーク操作をスケジュールする堅牢なメカニズムを提供します。　あなたは、JobSchedulerをcontent providersの変更の対応にも使用できます。

この動作の変更とどのようにアプリを適応させるかの詳細については、Background Optimizationsを参照してください。

Permissions Changes

Android N includes changes to permissions that may affect your app, including user accounts permissions and a new permission for writing to external storage. Here is a summary of the permissions that have changed in the preview:

GET_ACCOUNTS (Deprecated)

The GET_ACCOUNTS permission is now deprecated. The system ignores this permission for apps that target Android N.

Android Nには、ユーザーアカウントパーミッションと外部ストレージ書込についての新しいパーミッションを含む、あなたのアプリに影響するかもしれないパーミッション変更があります。

プレビュー版で変更されたパーミッションの概要は次の通りです：

GET_ACCOUNTS（Deprecated）

GET_ACCOUNTSパーミッションは廃止されました。　Android Nを対象としたアプリの場合、システムはこのパーミッションを無視します。

Accessibility Improvements

Android N includes changes intended to improve the usability of the platform for users with low or impaired vision. These changes should generally not require code changes in your app, however you should review these feature and test them with your app to assess potential impacts to user experience.

Android Nは視力の弱いユーザー向けにプラットフォームの操作性を改善することを目的とした変更を含みます。　一般的にこれらの変更はあなたのアプリのコード修正を必要としません。しかしユーザーエクスペリエンスへの潜在的な影響を評価するため、これらの機能を確認し、あなたのアプリでテストすべきです。

Screen Zoom

Android N enables users to set Display size which magnifies or shrinks all elements on the screen, thereby improving device accessibility for users with low vision. Users cannot zoom the screen past a minimum screen width of sw320dp, which is the width of a Nexus 4, a common medium-sized phone.
　

Figure 3. The screen on the right shows the effect of increasing the Display size of a device running an Android N system image.

When the device density changes, the system notifies running apps in the following ways:

If an app targets API level 23 or lower, the system automatically kills all its background processes. This means that if a user switches away from such an app to open the Settings screen and changes the Display size setting, the system kills the app in the same manner that it would in a low-memory situation. If the app has any foreground processes, the system notifies those processes of the configuration change as described in Handling Runtime Changes, just as if the device's orientation had changed.
If an app targets Android N, all of its processes (foreground and background) are notified of the configuration change as described in Handling Runtime Changes.

Most apps do not need to make any changes to support this feature, provided the apps follow Android best practices. Specific things to check for:

Test your app on a device with screen width sw320dp and be sure it performs adequately.
When the device configuration changes, update any density-dependent cached information, such as cached bitmaps or resources loaded from the network. Check for configuration changes when the app resumes from the paused state.

Note: If you cache configuration-dependent data, it's a good idea to include relevant metadata such as the appropriate screen size or pixel density for that data. Saving this metadata allows you to decide whether you need to refresh the cached data after a configuration change.

Avoid specifying dimensions with px units, since they do not scale with screen density. Instead, specify dimensions with density-independent pixel (dp) units.

Android Nは視力の弱いユーザーにとってのデバイスの操作性を改善するため、ユーザーが画面上のすべての要素を拡大または縮小する表示サイズを設定できるようにします。　ユーザーは一般的な中型の電話、Nexus 4の幅であるsw320dpの最小の画面幅を超えてズームすることはできません。

Figure 3. 右側の画面はAndroid Nが動作しているデバイスの拡大表示の効果を示します。

デバイス密度が変化したとき、システムは次の方法で実行中のアプリに通知します：

アプリのターゲットAPIレベルが23以下の場合、システムは自動で全てのバックグラウンドプロセスを強制終了します。　これはユーザーが設定画面を開くためそのようなアプリから切り替えて、ディスプレイサイズを変更した場合、システムがメモリ不足の状況時と同様のやり方でアプリを強制終了することを意味します。　アプリが何らかのフォアグラウンドプロセスを持っている場合、システムはそれらのプロセスにHandling Runtime Changesで解説されているように、あたかもデバイスの向きが変更されたかのように、構成変更を通知します。
　
アプリがAndroid Nを対象としている場合、その(フォアグラウンドとバックグラウンドの)すべてのプロセスにHandling Runtime Changesで解説されているように構成変更が通知されます。

アプリがAndroidのベストプラクティスに従っているならば、ほとんどのアプリはこの機能をサポートするために何らかの変更を加える必要がありません。　チェックが必要な項目：

画面幅がsw320dpのデバイスでアプリをテストし、適切に動くことを確認してください。
デバイスの構成変更があった時、ネットワークからロードされキャッシュされたビットマップやリソースのような、すべての密度の依存したキャッシュ情報を更新してください。　アプリがポーズ状態から再開するとき、構成の変更を確認してください。

注：もし構成に依存するデータをキャッシュするなら、そのデータに適した画面サイズやピクセル密度などの関連するメタデータを含めることをお勧めします。　このメタデータを保存すると、構成変更の後にキャッシュされたデータのリフレッシュが必要かどうかを判断できます。

ピクセル(px)単位で大きさを指定することは避けてください。なぜならそれらは画面密度に比例しないからです。　代わりに、密度に依存しないピクセル(dp)単位で大きさを指定してください。

Vision Settings in Setup Wizard

Android N includes Vision Settings on the Welcome screen, where users can set up the following accessibility settings on a new device: Magnification gesture, Font size, Display size and TalkBack. This change increases the visibility of bugs related to different screen settings. To assess the impact of this feature, you should test your apps with these settings enabled. You can find the settings under Settings > Accessibility.

Android NはWelcome画面に視覚設定を含みます。　ユーザーは新しいデバイスで次の操作性をセットアップ出来ます：　拡大ジェスチャー、フォントサイズ、ディスプレイサイズと音声応答。　この変更は、異なる画面設定に関連するバグを目立たせます。　この機能の影響を評価するため、あなたはそれらの設定を有効にしてアプリをテストすべきです。　この設定はSettings > Accessibilityで見つけられます。

NDK Apps Linking to Platform Libraries

Android N includes namespace changes to prevent loading of non-public APIs. If you use the NDK, you should only be using public APIs from the Android platform. Using non-public APIs in the next official release of Android can cause your app to crash.

In order to alert you to use of non-public APIs, apps running on an Android N device generate an error in logcat output when an app calls a non-public API. This error is also displayed on the device screen as a message to help raise awareness of this situation. You should review your app code to remove use of non-public platform APIs and thoroughly test your apps using a preview device or emulator.

If your app depends on platform libraries, see the NDK documentation for typical fixes for replacing common private APIs with public API equivalents. You may also be linking to platform libraries without realizing it, especially if your app uses a library that is part of the platform (such as libpng), but is not part of the NDK. In that case, ensure that your APK contains all the .so files you intended to link against.

Caution: Some third-party libraries may link to non-public APIs. If your app uses these libraries, your app may crash when running on the next official release of Android.

Apps should not depend on or use native libraries that are not included in the NDK, because they may change, or be removed from one Android release to another. The switch from OpenSSL to BoringSSL is an example of such a change. Also, different devices may offer different levels of compatibility, because there are no compatibility requirements for platform libraries not included in the NDK. If you must access non-NDK libraries on older devices, make the loading dependent on the Android API level.

To help you diagnose these types problems here are some example Java and NDK errors you might encounter when attempting to build your app with Android N:

Example Java error:

java.lang.UnsatisfiedLinkError: dlopen failed: library "/system/lib/libcutils.so"
    is not accessible for the namespace "classloader-namespace"

Example NDK error:

dlopen failed: cannot locate symbol "__system_property_get" referenced by ...

Here are some typical fixes for apps encountering these types of errors:

Use of getJavaVM and getJNIEnv from libandroid_runtime.so can be replaced with standard JNI functions:

    AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h>
    AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or
    JavaVM::AttachCurrentThread from <jni.h>.

Use of property_get symbol from libcutils.so can be replaced with the public alternative__system_property_get. To do this, use __system_property_get with the following include:

    #include <sys/system_properties.h>

Use of SSL_ctrl symbol from libcrypto.so should be replaced with an app local version. For example, you should statically link libcyrpto.a in your .so file or include your own dynamically libcrypto.so from BoringSSL or OpenSSL in your app.

Android Nは非パブリックAPIの読み込みを防止するため、ネームスペースの変更を含みます。　もしNDKを使用する場合は、AndroidプラットフォームのパブリックAPIのみを使用すべきです。　Androidの次の公式リリースで非パブリックAPIを使用すると、アプリがクラッシュする可能性があります。

あなたに非パブリックAPIの使用を警告するため、Android Nデバイス上のアプリは非パブリックAPIを呼び出したときにlogcatにエラー出力します。　このエラーはまた、この状態を気づきやすくするためデバイスの画面にメッセージとしても表示されます。　あなたは非パブリックAPIの使用を取り除くためアプリのコードを確認し、プレビュー版デバイスかエミュレーターで徹底的にテストすべきです。

アプリがプラットフォームライブラリに依存している場合、一般的なプライベートAPIを同等のパブリックAPIに置き換えるため、NDK documentationの典型的な修正方法を参照してください。　また、あなたのアプリが(libpngのような)プラットフォームの一部であるが、NDKの一部ではないライブラリを使用する場合、気づかずにプラットフォームライブラリにリンクしてしまうかもしれません。　そのような場合、あなたのAPKがあなたがリンクしようと考えているすべての.soファイルを含んでいることを確認してください。

注：一部のサードパーティ製のライブラリが非パブリックAPIにリンクしているかもしれません。　あなたのアプリがそのようなライブラリを使用している場合、あなたのアプリはAndroidの次の公式リリース上で動かしたときにクラッシュするかもしれません。

アプリはNDKに含まれていないネイティブライブラリに依存したり使ったりするべきではありません。　なぜならそれらはAndroidのリリースごとに変更されたり削除されたりするかもしれないからです。　OpenSSLからBoringSSLへの切り替えは、そのような変更の例です。　また、異なるデバイスは異なるレベルの互換性を提供するかもしれません。　なぜならNDKに含まれていないプラットフォームライブラリには互換性の要件がないからです。　もし古いデバイスで非NDKライブラリにアクセスしなければならない場合、Android APIレベルに合わせてロードしてください。

あなたが問題の原因を突き止めるのを助けるため、あなたのアプリをAndroid N向けにビルドしようとしたときに遭遇するかもしれないいくつかのJavaとNDKのエラー例を示します：

Javaのエラー例：

java.lang.UnsatisfiedLinkError: dlopen failed: library "/system/lib/libcutils.so"
    is not accessible for the namespace "classloader-namespace"

NDKのエラー例：

dlopen failed: cannot locate symbol "__system_property_get" referenced by ...

これらのタイプのエラーに遭遇したアプリのいくつかの典型的な修正方法は次の通りです：

libandroid_runtime.soのgetJavaVMとgetJNIEnvの使用はstandard JNI functionsで置き換えることが出来ます。

AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h>
AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or
JavaVM::AttachCurrentThread from <jni.h>.

libcutils.soのproperty_getシンボルの使用は、パブリックなalternative__system_property_getで置き換えることができます。　これを行うには、次のように__system_property_get使用します。

#include <sys/system_properties.h>

libcrypto.soのSSL_ctrlシンボルの使用は、アプリのローカルバージョンに置き換える必要があります。　例えば、あなたは.soファイルで静的にlibcyrpto.aにリンクするか、またはBoringSSLやOpenSSLの動的libcrypto.soをアプリに含める必要があります。

Android for Work

Android N contains changes for apps that target Android for Work, including changes to certificate installation, password resetting, secondary user management, and access to device identifiers. If you are building apps for Android for Work environments, you should review these changes and modify your app accordingly.

You must install a delegated certificate installer before the DPC can set it. For both profile and device-owner apps targeting the N SDK, you should install the delegated certificate installer before the device policy controller (DPC) calls DevicePolicyManager.setCertInstallerPackage(). If the installer is not already installed, the system throws an IllegalArgumentException.
Reset password restrictions for device admins now apply to profile owners. Device admins can no longer use DevicePolicyManager.resetPassword() to clear passwords or change ones that are already set. Device admins can still set a password, but only when the device has no password, PIN, or pattern.
Device and profile owners can manage accounts even if restrictions are set. Device owners and profile owners can call the Account Management APIs even if DISALLOW_MODIFY_ACCOUNTS user restrictions are in place.
Device owners can manage secondary users more easily. When a device is running in device owner mode, the DISALLOW_ADD_USER restriction is automatically set. This prevents users from creating unmanaged secondary users. In addition, the CreateUser() and createAndInitial() methods are deprecated; the new DevicePolicyManager.createAndManageUser() method replaces them.
Device owners can access device identifiers. A Device owner can access the Wi-Fi MAC address of a device, using DevicePolicyManagewr.getWifiMacAddress(). If Wi-Fi has never been enabled on the device, this method returns a value of null.

For more information about changes to Android for Work in Android N, see Android for Work Updates.

Android NはAndroid for Work向けアプリに対する変更があります。　それは証明書のインストール、パスワードリセット、セカンダリユーザ管理、デバイス識別子へのアクセスについての変更を含みます。　もしあなたがAndroid for Work環境向けのアプリを作成しているならば、これらの変更を確認し、それに応じてアプリを修正する必要があります。

DPCが設定を行う前に、委任証明書インストーラをインストールする必要があります。　プロファイルとN SDKを対象としたデバイスオーナーアプリの両方のために、デバイスポリシーコントローラ(DPC)がDevicePolicyManager.setCertInstallerPackage()を呼び出す前に委任証明書インストーラをインストールする必要があります。　インストーラがインストールされていない場合、システムはIllegalArgumentExceptionをスローします。
　
デバイス管理者向けパスワード制限が解除され、プロファイルオーナーに適用されます。　デバイス管理者はもはやパスワードのクリアやすでにセットされているパスワードを変更するために、DevicePolicyManager.resetPassword()を使用できません。　デバイス管理者は今後もパスワードを設定できますが、それはデバイスにパスワードまたはPINまたはパターンが設定されていない場合に限られます。
　
デバイスとプロファイルのオーナーは制限が設定されている場合でも、アカウントを管理することができます。　デバイスのオーナーとプロファイルのオーナーはDISALLOW_MODIFY_ACCOUNTSユーザー制限が適用されている場合でも、アカウント管理APIを呼び出すことができます。

- デバイスのオーナーはより簡単に二次ユーザーを管理することができます。　デバイスがデバイスオーナーモードで実行されているとき、`DISALLOW_ADD_USER`制限が自動的に設定されます。　これにより管理されていない二次ユーザーを作成することを防ぎます。　また、`CreateUser()`と`createAndInitial()`は非推奨になりました。　新しい`DevicePolicyManager.createAndManageUser()`がそれらを置き換えます。
- デバイスオーナーは、デバイス識別子にアクセスできます。　デバイスオーナーは`DevicePolicyManagewr.getWifiMacAddress()`を使用してデバイスのWi-Fi MACアドレスにアクセスできます。　デバイスのWi-Fiが有効でない場合、このメソッドは`null`値を返します。

Android NのAndroid for Workの変更についての詳細については、Android for Work Updatesを参照してください。

Other important points

When an app is running on Android N, but targets a lower API level, and the user changes display size, the app process is killed. The app must be able to gracefully handle this scenario. Otherwise, it crashes when the user restores it from Recents.

　You should test your app to ensure that this behavior does not occur. You can do so by causing an identical crash when killing the app manually via DDMS.

　Apps targeting N and above are not automatically killed on density changes; however, they may still respond poorly to configuration changes.

Apps on Android N should be able to gracefully handle configuration changes, and should not crash on subsequent starts. You can verify app behavior by changing font size (Setting > Display > Font size), and then restoring the app from Recents.
アプリがAndroid Nで実行されているが、低いAPIレベルを対象にしている場合、ユーザーがディプレイサイズを変更すると、アプリのプロセスは強制終了します。　アプリはこのシナリオをうまく処理できなければなりません。　さもなくば、ユーザーがアプリを最近使った一覧から復元したとき、アプリはクラッシュします。

あなたはこの現象が発生しないことを確実にするために、アプリをテストする必要があります。　あなたはDDMSで手動でアプリを強制終了させ同様のクラッシュを引き起こすことでこれを行うことが出来ます。

Nとそれ以上を対象にしたアプリは、密度の変更時に自動で強制終了されることはありません。　しかし、かれらはまだ構成変更への対応が不十分かもしれません。

- Android N上のアプリは、構成変更をうまく処理し、次回起動時にクラッシュしないようにする必要があります。　あなたはフォントサイズ(Setting > Display > Font size)を変更し、その後、最近使った一覧からアプリを復元することでアプリの動作を検証することが出来ます。