docs: Miscellaneous N Preview fixes.

Fixing a bunch of small items in this CL to save time, most of which
don't have bug numbers.

See first comment for doc stage location.

bug: 27536159
bug: 27535355
Change-Id: I95ff33ad9eace0cc9064c31128e412649936f8ad

docs/html/preview/behavior-changes.jd

@@ -88,7 +88,7 @@ page.image=images/cards/card-n-changes_2x.png
   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.
@@ -107,7 +107,7 @@ page.image=images/cards/card-n-changes_2x.png
   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
@@ -345,9 +345,10 @@ page.image=images/cards/card-n-changes_2x.png
   <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>
@@ -370,8 +371,8 @@ java.lang.NoSuchFieldException: No field array in class Ljava/util/ArrayList;
 
     <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>
@@ -428,13 +429,13 @@ java.lang.NoSuchFieldException: No field array in class Ljava/util/ArrayList;
 </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>
 
@@ -446,7 +447,7 @@ dlopen failed: cannot locate symbol "__system_property_get" referenced by ...
 <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 -&gt; GetJavaVM from &lt;jni.h&gt;
 AndroidRuntime::getJNIEnv -&gt; JavaVM::GetEnv or
 JavaVM::AttachCurrentThread from &lt;jni.h&gt;.
@@ -488,18 +489,18 @@ JavaVM::AttachCurrentThread from &lt;jni.h&gt;.
   </li>
 
   <li>Reset password restrictions for device admins now apply to profile
-  owners.Device admins can no longer use
-  <code>DevicePolicyManager.resetPassword()</code>to clear passwords or change
+  owners. Device admins can no longer use
+  <code>DevicePolicyManager.resetPassword()</code> 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.
   </li>
 
   <li>Device and profile owners can manage accounts even if restrictions are
-  set.Device owners and profile owners can call the Account Management APIs
+  set. Device owners and profile owners can call the Account Management APIs
   even if <code>DISALLOW_MODIFY_ACCOUNTS</code> user restrictions are in place.
   </li>
 
-  <li>Device owners can manage secondary users more easily.When a device is
+  <li>Device owners can manage secondary users more easily. When a device is
   running in device owner mode, the <code>DISALLOW_ADD_USER</code> restriction
   is automatically set. This prevents users from creating unmanaged secondary
   users. In addition, the <code>CreateUser()</code> and
@@ -507,13 +508,18 @@ JavaVM::AttachCurrentThread from &lt;jni.h&gt;.
   <code>DevicePolicyManager.createAndManageUser()</code> method replaces them.
   </li>
 
-  <li>Device owners can access device identifiers.A Device owner can access the
+  <li>Device owners can access device identifiers. A Device owner can access the
   Wi-Fi MAC address of a device, using
-  <code>DevicePolicyManagewr.getWifiMacAddress()</code> . If Wi-Fi has never
+  <code>DevicePolicyManagewr.getWifiMacAddress()</code>. If Wi-Fi has never
   been enabled on the device, this method returns a value of {@code null}.
   </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>

docs/html/preview/features/notification-updates.jd

@@ -282,41 +282,25 @@ this.
 
 <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.
+  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, 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.
-</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>

docs/html/preview/features/security-config.jd

@@ -244,12 +244,8 @@ page.keywords=preview,security,network
   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>