Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit f3851c16 authored by David Friedman's avatar David Friedman
Browse files

Docs: Migration of N docs to about/versions/

With the transition from N Preview to actual Nougat Release, this CL moves
the high-level overview files from the preview directory into the
about/versions/ directory, under which an archive of current and previous
Android versions' changes resides.

Change-Id: I42373b0302e953f8166c62e7c8422f2481322240
parent 340a59c7
Loading
Loading
Loading
Loading
+17 −0
Original line number Diff line number Diff line
@@ -1231,3 +1231,20 @@ redirects:
  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
+15 −1
Original line number Diff line number Diff line
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:
@@ -7,7 +19,9 @@ toc:
  - 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
+183 −0
Original line number Diff line number Diff line
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 &lt;packageName&gt; 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>
+39 −39
Original line number Diff line number Diff line
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

@@ -44,7 +44,7 @@ page.image=images/cards/card-n-changes_2x.png
<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>
@@ -52,7 +52,7 @@ page.image=images/cards/card-n-changes_2x.png


<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.
@@ -67,7 +67,7 @@ page.image=images/cards/card-n-changes_2x.png
<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.
@@ -78,14 +78,14 @@ 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
@@ -105,7 +105,7 @@ certain implicit intents.
</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
@@ -128,7 +128,7 @@ certain implicit intents.
<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
@@ -154,12 +154,12 @@ certain implicit intents.
</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
@@ -169,12 +169,12 @@ certain implicit intents.
  <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
@@ -193,14 +193,14 @@ certain implicit intents.
<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>
@@ -232,7 +232,7 @@ certain implicit intents.
    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
@@ -255,7 +255,7 @@ certain implicit intents.
<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.
@@ -272,7 +272,7 @@ see <a href="{@docRoot}training/secure-file-sharing/index.html">Sharing Files</a
<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
@@ -283,7 +283,7 @@ see <a href="{@docRoot}training/secure-file-sharing/index.html">Sharing Files</a
<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=
@@ -294,16 +294,16 @@ see <a href="{@docRoot}training/secure-file-sharing/index.html">Sharing Files</a
<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>


@@ -323,7 +323,7 @@ see <a href="{@docRoot}training/secure-file-sharing/index.html">Sharing Files</a
  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
@@ -365,7 +365,7 @@ see <a href="{@docRoot}training/secure-file-sharing/index.html">Sharing Files</a
<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
@@ -378,13 +378,13 @@ see <a href="{@docRoot}training/secure-file-sharing/index.html">Sharing Files</a
<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>
@@ -595,7 +595,7 @@ see <a href="{@docRoot}training/secure-file-sharing/index.html">Sharing Files</a
<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>

@@ -626,7 +626,7 @@ java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so"
<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>

@@ -692,7 +692,7 @@ JavaVM::AttachCurrentThread from &lt;jni.h&gt;.

<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
@@ -749,7 +749,7 @@ JavaVM::AttachCurrentThread from &lt;jni.h&gt;.
  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
@@ -765,7 +765,7 @@ JavaVM::AttachCurrentThread from &lt;jni.h&gt;.
  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
@@ -785,14 +785,14 @@ JavaVM::AttachCurrentThread from &lt;jni.h&gt;.
</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>
@@ -811,7 +811,7 @@ be available at runtime. You do so by using {@code @Retention(RetentionPolicy.RU
<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.
@@ -830,7 +830,7 @@ however, they may still respond poorly to configuration changes.
</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
@@ -839,7 +839,7 @@ the app from Recents.

<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.
@@ -860,7 +860,7 @@ as {@code RuntimeExceptions}, instead of silently logging or suppressing them.
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>
@@ -881,7 +881,7 @@ to a window. This behavior fixes the following bugs:
</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
Loading