Merge "docs: Miscellaneous N Preview fixes." into mnc-mr-docs

  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 {@link android.os.PowerManager.WakeLock},

  {@link android.app.AlarmManager} alarms, GPS, and Wi-Fi scans.. Regardless of

  {@link android.app.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.

  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

  <a href=”{@docRoot}/training/monitoring-device-state/doze-standby.html”>

  <a href="{@docRoot}/training/monitoring-device-state/doze-standby.html">

  Optimizing for Doze and App Standby</a>. 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

  <li>The {@code ArrayList} private field array is removed.

    <p>

      If your app, or a library it used, was dependent on a private field of

      the ArrayList class, you may encounter an exception such as:

      the <code>ArrayList</code> class, you may encounter an exception such as:

    </p>

<pre>

<pre class="no-pretty-print">

java.lang.NoSuchFieldException: No field array in class Ljava/util/ArrayList;

</pre>

  </li>

    <p>

      The reason apps use this provider is to take advantage of its

      SecureRandom implementation. If your app was relying on setSeed() to

      derive keys from strings, you must either switch to using SecretKeySpec

      <code>SecureRandom</code> implementation. If your app was relying on <code>setSeed()</code> to

      derive keys from strings, you must either switch to using <code>SecretKeySpec</code>

      to load raw key bytes directly, or use a real key derivation function

      (KDF).

    </p>

</p>

<p>Example Java error:</p>

<pre>

<pre class="no-pretty-print">

java.lang.UnsatisfiedLinkError: dlopen failed: library "/system/lib/libcutils.so"

    is not accessible for the namespace "classloader-namespace"

</pre>

<p>Example NDK error:</p>

<pre>

<pre class="no-pretty-print">

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

</pre>

<ul>

  <li>Use of getJavaVM and getJNIEnv from libandroid_runtime.so can be replaced

  with standard JNI functions:

<pre>

<pre class="no-pretty-print">

AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h>

AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or

JavaVM::AttachCurrentThread from <jni.h>.

  </li>

</ul>

<p>

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

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

</p>

<h2 id="other">Other important points</h2>

<ul>

<h3>Backwards compatibility</h3>

<p>On handhelds, notification groups are available beginning from

Android N. However, on tablets, the notification groups API has been available since

Android 5.0 (API level 21). </p>

<p>All Android Wear devices have this feature, regardless of API level.

 The only action a Wear developer must take is to verify that the app behavior

 corresponds to the <a href="#best-practices">guidelines</a> described above.</p>

<p>

In order to support backwards compatibility, a developer should still post

an

{@link android.app.Notification.InboxStyle InboxStyle} or equivalent

notification representative for the whole

information content of the group. This applies to child notifications in

Android 5.0 (API level 21) and above.

</p>

<p>

For convenience, apps can usually reuse the notification group summary

and define it as an

{@link android.app.Notification.InboxStyle InboxStyle} notification,

with each line corresponding to a child notification.

</p>

<p>In order to support backward compatibility, an app should still have

an {@link android.app.Notification.InboxStyle InboxStyle}

or equivalent notification representative for the whole information

content of the group including the children on Android 5.0 and above.

  Both notification groups and remote input have been a part of the {@link

  android.app.Notification} API since Android 5.0 (API level 21) to support

  Android Wear devices. If you've already built notifications with these APIs,

  the only action you must take is to verify that the app behavior corresponds

  to the guidelines described above, and to consider implementing {@code

  setRemoteInputHistory()}.

</p>

<p>

For convenience, an app can usually reuse the notification group summary and

define it as an {@link android.app.Notification.InboxStyle InboxStyle}

notification, with each line corresponding to one child notification.

  In order to support backward compatibility, the same APIs are available with

  the support library's {@link android.support.v4.app.NotificationCompat}

  class, allowing you to build notifications that works on earlier Android

  versions. On handhelds and tablets, users only see the summary notification,

  so an app should still have an inbox style or an equivalent notification

  representative for the whole information content of the group. As Android

  Wear devices allow users to see all child notifications even on older

  platform levels, you should build child notifications regardless of API

  level.

</p>

<h2 id="custom"> Custom Views</h2>

  protocol instead of HTTPS) to those destinations. This option helps prevent

  accidental regressions in apps due to changes in URLs provided by external

  sources such as backend servers.

</p>

<p>

  See the reference documentation for \

  {@code android.security.NetworkSecurityPolicy} class

  {@code isCleartextTrafficPermitted()} method for more details.

  See {@link android.security.NetworkSecurityPolicy#isCleartextTrafficPermitted

  NetworkSecurityPolicy.isCleartextTrafficPermitted()} for more details.

</p>

<p>