From b0fbda45e565898168b2c1ae359da54ecd8f8712 Mon Sep 17 00:00:00 2001 From: Andrew Solovay Date: Tue, 8 Mar 2016 18:19:09 -0800 Subject: [PATCH] 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 | 36 +++++++++------ .../preview/features/notification-updates.jd | 46 ++++++------------- docs/html/preview/features/security-config.jd | 8 +--- 3 files changed, 38 insertions(+), 52 deletions(-) diff --git a/docs/html/preview/behavior-changes.jd b/docs/html/preview/behavior-changes.jd index 5c42772241bbb..6873c92ce977d 100644 --- a/docs/html/preview/behavior-changes.jd +++ b/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 - + 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 @@ -345,9 +345,10 @@ page.image=images/cards/card-n-changes_2x.png
  • The {@code ArrayList} private field array is removed.

    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 ArrayList class, you may encounter an exception such as:

    -
    +
+
     java.lang.NoSuchFieldException: No field array in class Ljava/util/ArrayList;
    • @@ -370,8 +371,8 @@ java.lang.NoSuchFieldException: No field array in class Ljava/util/ArrayList;

    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 + SecureRandom implementation. If your app was relying on setSeed() to + derive keys from strings, you must either switch to using SecretKeySpec to load raw key bytes directly, or use a real key derivation function (KDF).

    @@ -428,13 +429,13 @@ java.lang.NoSuchFieldException: No field array in class Ljava/util/ArrayList;

    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 ...
 
    
 
@@ -446,7 +447,7 @@ dlopen failed: cannot locate symbol "__system_property_get" referenced by ...
 
      
   
    • 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>.
@@ -488,18 +489,18 @@ JavaVM::AttachCurrentThread from <jni.h>.
   
      • 
 
   
    • Reset password restrictions for device admins now apply to profile
-  owners.Device admins can no longer use
-  DevicePolicyManager.resetPassword()to clear passwords or change
+  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
+  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
+  
    • 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
@@ -507,13 +508,18 @@ JavaVM::AttachCurrentThread from <jni.h>.
   DevicePolicyManager.createAndManageUser() method replaces them.
   
      • 
 
-  
    • Device owners can access device identifiers.A Device owner can access the
+  
    • 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
+  DevicePolicyManagewr.getWifiMacAddress(). If Wi-Fi has never
   been enabled on the device, this method returns a value of {@code null}.
   
      • 
 
    
 
+
    
+  For more information about changes to Android for Work in Android N, see
+  Android for Work Updates.
+
    
+
 
    Other important points
    
 
 
      
diff --git a/docs/html/preview/features/notification-updates.jd b/docs/html/preview/features/notification-updates.jd
index e96fb700da286..fa86ed200a8de 100644
--- a/docs/html/preview/features/notification-updates.jd
+++ b/docs/html/preview/features/notification-updates.jd
@@ -282,41 +282,25 @@ this.
 
 
      Backwards compatibility
      
 
-
      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). 
      
-
-
      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 guidelines described above.
      
-
 
      
-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()}.
 
      
 
 
      
-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.
-
      
-
-
-
      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.
-
      
-
-
      
-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.
 
      
 
 
       Custom Views
      
diff --git a/docs/html/preview/features/security-config.jd b/docs/html/preview/features/security-config.jd
index 1e9a90e9c9e1d..34860bf81a7e5 100644
--- a/docs/html/preview/features/security-config.jd
+++ b/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.
-
      
-
-
      
-  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.