Docs: Migration of N docs to about/versions/

  to: /guide/topics/resources/multilingual-support.html

- from: /preview/j8-jack.html

  to: /guide/platform/j8-jack.html

- from: /about/versions/marshmallow/samples.html

  to: /about/versions/marshmallow/android-6.0-samples.html

- from: /preview/behavior-changes.html

  to: /about/versions/nougat/android-7.0-changes.html

- from: /preview/samples.html

  to: /about/versions/nougat/android-7.0-samples.html

- from: /preview/guide.html

  to: /about/versions/nougat/android-7.0-testing.html

- from: /preview/api-overview.html

  to: /about/versions/nougat/android-7.0.html

- from: /preview/index.html

  to: /about/versions/nougat/index.html

- from: /preview/features/background-optimization.html

  to: /topic/performance/background-optimization.html

- from: /preview/features/data-saver.html

  to: /training/basics/network-ops/data-saver.html

toc:

- title: Nougat

  path: /about/versions/nougat/index.html

  section:

  - title: Android 7.0 APIs

    path: /about/versions/nougat/android-7.0.html

  - title: Android 7.0 Changes

    path: /about/versions/nougat/android-7.0-changes.html

  - title: Android 7.0 Samples

    path: /about/versions/nougat/android-7.0-samples.html

  - title: Android 7.0 Testing

    path: /about/versions/nougat/android-7.0-testing.html

- title: Marshmallow

  path: /about/versions/marshmallow/index.html

  section:

  - title: Android 6.0 Changes

    path: /about/versions/marshmallow/android-6.0-changes.html

  - title: Android 6.0 Samples

    path: /about/versions/marshmallow/samples.html

    path: /about/versions/marshmallow/android-6.0-samples.html

  - title: Android 6.0 Testing

    path: /about/versions/marshmallow/android-6.0-testing.html

- title: Lollipop

  path: /about/versions/lollipop.html

page.title=Android 6.0 Testing Guide

page.image=images/cards/card-n-guide_2x.png

meta.tags="preview", "testing"

page.tags="preview", "developer preview"

@jd:body

<div id="qv-wrapper">

  <div id="qv">

    <h2>In this document</h2>

      <ol>

        <li><a href="#runtime-permissions">Testing Permissions</a></li>

        <li><a href="#doze-standby">Testing Doze and App Standby</a></li>

        <li><a href="#ids">Auto Backup and Device Identifiers</a></li>

      </ol>

  </div>

</div>

<p>

  Android 6.0 gives you an opportunity to ensure your apps work with the next

  version of the platform. This preview includes a number of APIs and behavior changes that can

  impact your app, as described in the <a href="{@docRoot}preview/api-overview.html">API

  Overview</a> and <a href="{@docRoot}preview/behavior-changes.html">Behavior Changes</a>. In testing

  your app with the preview, there are some specific system changes that you should focus on to

  ensure that users have a good experience.

</p>

<p>

  This guide describes the what and how to test preview features with your app. You should

  prioritize testing of these specific preview features, due to their high potential impact on your

  app's behavior:

</p>

<ul>

  <li><a href="#runtime-permissions">Permissions</a>

  </li>

  <li><a href="#doze-standby">Doze and App Standby</a>

  </li>

  <li><a href="#ids">Auto Backup and Device Identifiers</a></li>

</ul>

<h2 id="runtime-permissions">Testing Permissions</h2>

<p>

  The new <a href="{@docRoot}preview/features/runtime-permissions.html">Permissions</a> model

  changes the way that permissions are allocated to your app by the user. Instead of granting all

  permissions during the install procedure, your app must ask the user for individual permissions

  at runtime. For users this behavior provides more granular control over each app’s activities, as

  well as better context for understanding why the app is requesting a specific permission. Users

  can grant or revoke the permissions granted to an app individually at any time. This feature of

  the preview is most likely to have an impact on your app's behavior and may prevent some of your

  app features from working, or they may work in a degraded state.

</p>

<p class="caution">

  This change affects all apps running on the new platform, even those not targeting the new

  platform version. The platform provides a limited compatibility behavior for legacy apps, but you

  should begin planning your app’s migration to the new permissions model now, with a goal of

  publishing an updated version of your app at the official platform launch.

</p>

<h3 id="permission-test-tips">Test tips</h3>

<p>

  Use the following test tips to help you plan and execute testing of your app with the new

  permissions behavior.

</p>

<ul>

  <li>Identify your app’s current permissions and the related code paths.</li>

  <li>Test user flows across permission-protected services and data.</li>

  <li>Test with various combinations of granted/revoked permission.</li>

  <li>Use the {@code adb} tool to manage permssions from the command line:

    <ul>

      <li>List permissions and status by group:

        <pre>adb shell pm list permissions -d -g</pre>

      </li>

      <li>Grant or revoke one or more permissions using the following syntax:<br>

        <pre>adb shell pm [grant|revoke] &lt;permission.name&gt; ...</pre>

      </li>

    </ul>

  </li>

  <li>Analyze your app for services that use permissions.</li>

</ul>

<h3 id="permission-test-strategy">Test strategy</h3>

<p>

  The permissions change affects the structure and design of your app, as well as

  the user experience and flows you provide to users. You should assess your app’s current

  permissions use and start planning for the new flows you want to offer. The official release of

  the platform provides compatibility behavior, but you should plan on updating your app and not

  rely on these behaviors.

</p>

<p>

  Identify the permissions that your app actually needs and uses, and then find the various code

  paths that use the permission-protected services. You can do this through a combination of

  testing on the new platform and code analysis. In testing, you should focus on opting in to

  runtime permissions by changing the app’s {@code targetSdkVersion} to the preview version. For

  more information, see <a href="{@docRoot}preview/setup-sdk.html#">Set up

the Android N SDK</a>.

</p>

<p>

  Test with various combinations of permissions revoked and added, to highlight the user flows that

  depend on permissions. Where a dependency is not obvious or logical you should consider

  refactoring or compartmentalizing that flow to eliminate the dependency or make it clear why the

  permission is needed.

</p>

<p>

  For more information on the behavior of runtime permissions, testing, and best practices, see the

  <a href="{@docRoot}preview/features/runtime-permissions.html">Permissions</a> developer

  preview page.

</p>

<h2 id="doze-standby">Testing Doze and App Standby</h2>

<p>

  The power saving features of Doze and App Standby limit the amount of background processing that

  your app can perform when a device is in an idle state or while your app is not in focus. The

  restrictions the system may impose on apps include limited or no network access,

  suspended background tasks, suspended Notifications, ignored wake requests, and alarms. To ensure

  that your app behaves properly with these power saving optimizations, you should test your app by

  simulating these low power states.

</p>

<h4 id="doze">Testing your app with Doze</h4>

<p>To test Doze with your app:</p>

<ol>

<li>Configure a hardware device or virtual device with an Android N system image.</li>

<li>Connect the device to your development machine and install your app.</li>

<li>Run your app and leave it active.</li>

<li>Simulate the device going into Doze mode by running the following commands:

<pre>

$ adb shell dumpsys battery unplug

$ adb shell dumpsys deviceidle step

$ adb shell dumpsys deviceidle -h

</pre>

  </li>

  <li>Observe the behavior of your app when the device is re-activated. Make sure it

    recovers gracefully when the device exits Doze.</li>

</ol>

<h4 id="standby">Testing apps with App Standby</h4>

<p>To test the App Standby mode with your app:</p>

<ol>

  <li>Configure a hardware device or virtual device with an Android N system image.</li>

  <li>Connect the device to your development machine and install your app.</li>

  <li>Run your app and leave it active.</li>

  <li>Simulate the app going into standby mode by running the following commands:

<pre>

$ adb shell am broadcast -a android.os.action.DISCHARGING

$ adb shell am set-idle <packageName> true

</pre>

  </li>

  <li>Simulate waking your app using the following command:

    <pre>$ adb shell am set-idle &lt;packageName&gt; false</pre>

  </li>

  <li>Observe the behavior of your app when it is woken. Make sure it recovers gracefully

    from standby mode. In particular, you should check if your app's Notifications and background

    jobs continue to function as expected.</li>

</ol>

<h2 id="ids">Auto Backup for Apps and Device-Specific Identifiers</h2>

<p>If your app is persisting any device-specific identifiers, such as Google

Cloud Messaging registration ID, in internal storage,

make sure to follow best practices to exclude the storage

location from auto-backup, as described in <a href="{@docRoot}preview/backup/index.html">Auto

Backup for Apps</a>. </p>

page.title=Behavior Changes

page.title=Android 7.0 Changes

page.keywords=preview,sdk,compatibility

meta.tags="preview", "compatibility"

page.tags="preview", "developer preview"

meta.tags="Android 7.0", "Nougat", "android n", "compatibility"

page.tags="Android 7.0", "Nougat", "android n", "developer preview"

page.image=images/cards/card-n-changes_2x.png

@jd:body

<h2>See Also</h2>

<ol>

  <li><a href="{@docRoot}preview/api-overview.html">

    Android N for Developers</a></li>

    Android 7.0 APIs</a></li>

</ol>

</div>

<p>

  Along with new features and capabilities, Android N

  Along with new features and capabilities, Android 7.0

  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.

<h2 id="perf">Battery and Memory</h2>

<p>

Android N includes system behavior changes aimed at improving the battery life

Android 7.0 includes system behavior changes aimed at improving the battery life

of devices and reducing RAM usage. These changes can affect your app’s access to

system resources, along with the way your app interacts with other apps via

certain implicit intents.

<p>

  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

  stationary, and with the screen turned off. Android 7.0 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.

</p>

<img src="{@docRoot}preview/images/doze-diagram-1.png"

<img src="{@docRoot}images/android-7.0/doze-diagram-1.png"

  alt="" height="251px" id="figure1" />

<p class="img-caption">

  <strong>Figure 1.</strong> Illustration of how Doze applies a first level of

</p>

<img src="{@docRoot}preview/images/doze-diagram-2.png"

<img src="{@docRoot}images/android-7.0/doze-diagram-2.png"

  alt="" id="figure2" />

<p class="img-caption">

  <strong>Figure 2.</strong> Illustration of how Doze applies a second level of

<h3 id="bg-opt">Project Svelte: Background Optimizations</h3>

<p>

  Android N removes three implicit broadcasts in order to help optimize both

  Android 7.0 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

</p>

<p>

  To alleviate these issues, Android N applies the following

  To alleviate these issues, Android 7.0 applies the following

  optimizations:

</p>

<ul>

  <li>Apps targeting Android N do not receive {@link

  <li>Apps targeting Android 7.0 do not receive {@link

  android.net.ConnectivityManager#CONNECTIVITY_ACTION} broadcasts, even if they

  have manifest entries to request notification of these events. Apps that are

  running can still listen for {@code CONNECTIVITY_CHANGE} on their main thread

  <li>Apps cannot send or receive {@link

  android.hardware.Camera#ACTION_NEW_PICTURE} or {@link

  android.hardware.Camera#ACTION_NEW_VIDEO} broadcasts. This optimization

  affects all apps, not only those targeting Android N.

  affects all apps, not only those targeting Android 7.0.

  </li>

</ul>

<p>If your app uses any of these intents, you should remove dependencies

  on them as soon as possible so that you can target Android N devices properly.

  on them as soon as possible so that you can target Android 7.0 devices properly.

  The Android framework provides several solutions to mitigate the need for

  these implicit broadcasts. For example, the {@link

  android.app.job.JobScheduler} API provides a robust mechanism to schedule

<h2 id="perm">Permissions Changes</h2>

<p>

  Android N includes changes to permissions that may affect your app.

  Android 7.0 includes changes to permissions that may affect your app.

</p>

<h3 id="permfilesys">File system permission changes</h3>

<p>

  In order to improve the security of private files, the private directory of

  apps targeting Android N or higher has restricted access (<code>0700</code>).

  apps targeting Android 7.0 or higher has restricted access (<code>0700</code>).

  This setting prevents leakage of metadata of private files, such as their size

  or existence. This permission change has multiple side effects:

</p>

    stored files by filename. Legacy applications may end up with an

    unaccessible path when accessing {@link

    android.app.DownloadManager#COLUMN_LOCAL_FILENAME}. Apps targeting

    Android N or higher trigger a {@link java.lang.SecurityException} when

    Android 7.0 or higher trigger a {@link java.lang.SecurityException} when

    attempting to access

    {@link android.app.DownloadManager#COLUMN_LOCAL_FILENAME}.

    Legacy applications that set the download location to a public location by

<h2 id="sharing-files">Sharing Files Between Apps</h2>

<p>

For apps targeting Android N, the Android framework enforces

For apps targeting Android 7.0, the Android framework enforces

the {@link android.os.StrictMode} API policy that prohibits exposing {@code file://} URIs

outside your app. If an intent containing a file URI leaves your app, the app fails

with a {@code FileUriExposedException} exception.

<h2 id="accessibility">Accessibility Improvements</h2>

<p>

  Android N includes changes intended to improve the usability of the

  Android 7.0 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

<h3 id="screen-zoom">Screen Zoom</h3>

<p>

  Android N enables users to set <strong>Display size</strong>which magnifies

  Android 7.0 enables users to set <strong>Display size</strong>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 <a href=

<div class="cols">

<div class="col-6">

  <img src="{@docRoot}preview/images/screen-zoom-1.png" alt="" height="XXX" id="figure1" />

  <img src="{@docRoot}images/android-7.0/screen-zoom-1.png" alt="" height="XXX" id="figure1" />

</div>

<div class="col-6">

  <img src="{@docRoot}preview/images/screen-zoom-2.png" alt="" height="XXX" id="figure1" />

  <img src="{@docRoot}images/android-7.0/screen-zoom-2.png" alt="" height="XXX" id="figure1" />

</div>

</div> <!-- end cols -->

<p class="img-caption">

  <strong>Figure 3.</strong> The screen on the right shows the effect of

  increasing the Display size of a device running an Android N system image.

  increasing the Display size of a device running an Android 7.0 system image.

</p>

  Runtime Changes</a>, just as if the device's orientation had changed.

  </li>

  <li>If an app targets Android N, all of its processes

  <li>If an app targets Android 7.0, all of its processes

  (foreground and background) are notified of the configuration change as

  described in <a href=

  "{@docRoot}guide/topics/resources/runtime-changes.html">Handling

<h3 id="vision-settings">Vision Settings in Setup Wizard</h3>

<p>

  Android N includes Vision Settings on the Welcome screen, where users can

  Android 7.0 includes Vision Settings on the Welcome screen, where users can

  set up the following accessibility settings on a new device:

  <strong>Magnification gesture</strong>, <strong>Font size</strong>,

  <strong>Display size</strong> and <strong>TalkBack</strong>. This change

<h2 id="ndk">NDK Apps Linking to Platform Libraries</h2>

<p>

  Starting in Android N, the system prevents apps from dynamically linking

  Starting in Android 7.0, the system prevents apps from dynamically linking

  against non-NDK libraries, which may cause your app to crash. This change in

  behavior aims to create a consistent app experience across platform updates

  and different devices. Even though your code might not be linking against

  private libraries, it's possible that a third-party static library in your

  app could be doing so. Therefore, all developers should check to make sure

  that their apps do not crash on devices running Android N. If your app uses

  that their apps do not crash on devices running Android 7.0. If your app uses

  native code, you should only be using <a href=

  "{@docRoot}ndk/guides/stable_apis.html">public NDK APIs</a>.

</p>

<p>

  To help you identify issues loading private libraries, logcat may generate a

  warning or runtime error. For example, if your app targets API level 23 or

  lower, and tries to access a private library on a device running Android N,

  lower, and tries to access a private library on a device running Android 7.0,

  you may see a warning similar to the following:

</p>

<p>

  You may also see these logcat outputs if your app uses third-party libraries

  that dynamically link to private platform APIs. The readelf tool in the

  Android NDK allows you to generate a list of all dynamically linked shared

  Android 7.0DK allows you to generate a list of all dynamically linked shared

  libraries of a given <code>.so</code> file by running the following command:

</p>

<h2 id="afw">Android for Work</h2>

<p>

  Android N contains changes for apps that target Android for Work, including

  Android 7.0 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

  DER-encoded format under a .crt or .cer file extension.

  </li>

  <li>Starting in Android N, fingerprint enrollment and storage are managed per user.

  <li>Starting in Android 7.0, fingerprint enrollment and storage are managed per user.

  If a profile owner’s Device Policy Client (DPC) targets pre-N on an N device,

  the user is still able to set fingerprint on the device, but work

  applications cannot access device fingerprint. When the DPC targets N and

  is returned, even if the encryption key is specific to the user or profile.

  </li>

  <li>In Android N, several methods that would ordinarily affect the entire

  <li>In Android 7.0, several methods that would ordinarily affect the entire

  device behave differently if the device has a work profile installed with a

  separate work challenge. Rather than affecting the entire device, these

  methods apply only to the work profile. (The complete list of such methods is

</ul>

<p>

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

  For more information about changes to Android for Work in Android 7.0, see

  <a href="{@docRoot}preview/features/afw.html">Android for Work Updates</a>.

</p>

<h2 id="annotations">Annotations Retention</h2>

<p>

Android N fixes a bug where the visibility of annotations was being ignored.

Android 7.0 fixes a bug where the visibility of annotations was being ignored.

This issue enabled the runtime to access annotations that it should not have been

able to. These annotations included:

</p>

<h2 id="other">Other Important Points</h2>

<ul>

<li>When an app is running on Android N, but targets a lower API level,

<li>When an app is running on Android 7.0, 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.

</li>

<li>

Apps on Android N should be able to gracefully handle configuration changes,

Apps on Android 7.0 should be able to gracefully handle configuration changes,

and should not crash on subsequent starts. You can verify app behavior

by changing font size (<strong>Setting</strong> >

<strong>Display</strong> > <strong>Font size</strong>), and then restoring

<li>

Due to a bug in previous versions of Android, the system did not flag writing

to a TCP socket on the main thread as a strict-mode violation. Android N fixes this bug.

to a TCP socket on the main thread as a strict-mode violation. Android 7.0 fixes this bug.

Apps that exhibit this behavior now throw an {@code android.os.NetworkOnMainThreadException}.

Generally, performing network operations on the main thread is a bad idea because these operations

usually have a high tail latency that causes ANRs and jank.

common example is storing too much data in

{@link android.app.Activity#onSaveInstanceState Activity.onSaveInstanceState()},

which causes {@code ActivityThread.StopInfo} to throw a

{@code RuntimeException} when your app targets Android N.

{@code RuntimeException} when your app targets Android 7.0.

</li>

<li>

</li>

<li>

If an app on Android N with

If an app on Android 7.0 with

{@link android.Manifest.permission#DELETE_PACKAGES DELETE_PACKAGES}

permission tries to delete a package, but a different app had installed that package,

the system requires user confirmation. In this scenario, apps should expect