Android7.0 Change of behavior

I'm just a Google Porter ...

Behavior changes the content of this article

2. Performance improvements
   1. Low power consumption mode
   2. Background optimization
4. Permission changes
6. Sharing files between apps
8. Barrier-free Improvement
   1. Screen Zoom
   2. Setting visual settings in the wizard
10. NDK app link to platform library
12. Android for work
14. annotation retention
16. Other important notes

See Also

1. Android N API Overview

In addition to providing many new features and functionality, Android N also makes various changes to system and API behavior. This article highlights some of the important changes you should be aware of and consider when developing your application.

If you've previously published an Android app, be aware that your app may be affected by these platform changes.

Battery and memory

Android N includes system behavior changes designed to extend device battery life and reduce RAM usage. These changes may affect your app's access to system resources and how your system interacts with other apps through a specific implicit Intent.

Low power consumption mode

Android 6.0 (API level 23) introduces a low-power mode that delays CPU and network activity when the user device is unplugged, in a stationary state, and the screen is turned off, prolonging battery life. Android N further enhances the low-power mode by applying some CPU and network restrictions when the device is unplugged and the screen is off, but not necessarily at rest (for example, when a user is out of the hand-held device in his pocket).

Figure 1. How low power consumption mode applies the first-level system activity limit to extend the battery life of the illustration.

When the device is charging and the screen is off for a certain amount of time, the device enters low-power mode and applies the first part of the limit: Turn off app network access, postpone jobs, and synchronize. If the device is stationary for a certain amount of time after entering low-power mode, the system will PowerManager.WakeLock apply the AlarmManager remaining low-power mode limits to the alarm, GPS, and Wi-Fi scanning. The system wakes up the device to provide a short maintenance window, whether the application part or all low power mode limits, during which the application can access the network and perform any deferred jobs/synchronizations.

Figure 2. How low-power mode applies a diagram of the second-level system activity limit after the device has reached a standstill for a certain amount of time.

Note that when you activate the screen or plug-in the device, the system exits low-power mode and cancels these processing restrictions. This new behavior does not affect the recommendations and best practices for adapting your app to older versions of low power consumption models introduced in Android 6.0 (API level 23), such as low power consumption mode and application Standby mode optimization. You should still follow these recommendations, such as using Google Cloud Messaging (GCM) to send and receive messages, and start scheduling update plans to accommodate the new low-power mode behavior.

Project Svelte: Background optimization

Android N removed three implicit broadcasts to help optimize memory usage and power consumption. This change is necessary because implicit broadcasts frequently start applications that are registered to listen for these broadcasts in the background. Removing these broadcasts can significantly improve device performance and user experience.

Mobile devices experience frequent connection changes, such as when switching between Wi-Fi and mobile data. Currently, you can listen to implicit CONNECTIVITY_ACTION broadcasts by registering a receiver in the app manifest to enable the app to monitor these changes. Because many applications register to receive this broadcast, a single network switchover can cause all apps to wake up and process the broadcast at the same time.

Similarly, an app can register to receive implicit ACTION_NEW_PICTURE and ACTION_NEW_VIDEO broadcast from other apps, such as a camera. When a user takes a photo using the camera app, the apps are awakened to process the broadcast.

To mitigate these problems, Android N applies the following optimizations:

• Apps that are developed for Android N will not receive CONNECTIVITY_ACTION broadcasts, even if they already have a manifest entry to request notification of these events. Apps that run in the foreground BroadcastReceiver can still listen in the main thread if they are receiving notifications using a request CONNECTIVITY_CHANGE .
• Apps cannot be sent or ACTION_NEW_PICTURE received or ACTION_NEW_VIDEO broadcast. This optimization affects all applications, not just Android N.

If your app uses any Intent, you still need to remove their dependencies as soon as possible to properly fit the Android N device. The Android framework provides multiple solutions to mitigate the need for these implicit broadcasts. For example, JobScheduler The API provides a robust mechanism to schedule network operations that meet specified conditions, such as connecting to an infinite traffic network. You can even use it JobScheduler to adapt to changes in the content provider.

For more information about background optimizations in Android N and how to overwrite apps, see background optimizations.

Permission changes

Android N has made some permission changes that may affect your app.

System Permissions Change

To improve the security of private files, the application Private directory for Android N or later is restricted access ( 0700 ). This setting prevents the metadata disclosure of private files, such as their size or presence. This permission change has multiple side effects:

• File permissions for private files should no longer be relaxed by the owner, and MODE_WORLD_READABLE such attempts to use and/or MODE_WORLD_WRITEABLE are triggered SecurityException .

  Note: so far, this limitation has not yet been fully implemented. Apps may still use native APIs or File APIs to modify their private directory permissions. However, we strongly oppose the privilege of relaxing a private directory.

• transfer package domain   file://   The URI may leave an unreachable path to the receiver. Therefore, try to pass   file://   URI will trigger   fileuriexposedexception . The recommended way to share private file content is to use   fileprovider .
• DownloadManager Private stored files are no longer shared by file name. Legacy apps may have inaccessible COLUMN_LOCAL_FILENAME paths when they visit. Apps that target Android N or later are COLUMN_LOCAL_FILENAME triggered when they try to access it SecurityException . DownloadManager.Request.setDestinationInExternalFilesDir() Legacy apps that use or DownloadManager.Request.setDestinationInExternalPublicDir() set the download location to a common location can still access COLUMN_LOCAL_FILENAME paths in, but we strongly oppose using this approach. DownloadManager the preferred way to access the files that are exposed is to use ContentResolver.openFileDescriptor() .

Sharing files between apps

For Android N-oriented apps, the Android framework enforces an StrictMode API policy that prohibits exposing file:// URIs to your app. If a Intent that contains a file URI leaves your app, the app fails with an FileUriExposedException exception.

To share files between apps, you should send a content:// URI and grant the URI temporary access permissions. The simplest way to make this authorization is to use FileProvider a class. For more information about permissions and shared files, see share files.

Barrier-free Improvement

Android N made some changes to improve the usability of the platform for poor eyesight or visually impaired users. These changes generally do not require changes to your app code, but you should carefully review and test these features with your app to assess their potential impact on the user experience.

Screen Zoom

Android N enables the user to set the display size to enlarge or reduce all elements on the screen, thereby enhancing the accessibility of the device to visually impaired users. The user cannot scale the screen below the minimum screen width of SW320DP, which is the width of the Nexus 4 and the width of the regular medium-sized phone.

Figure 3. The right-hand screen shows the effect of a device running an Android N system image that increases the size of the display.

When device density changes, the system notifies the running app as follows:

• If the application is for an API level 23 or earlier system, all of its background processes are automatically terminated. This means that if a user switches away from such an app, turns on the Settings screen and changes the display size setting, the system terminates the app as if it were running out of memory. If the app has any foreground processes, the system notifies them of the configuration changes as described in processing a run-time change, as if the device's screen orientation changes.
• If the app is for Android N, all of its processes (foreground and background) will receive notifications about configuration changes, as described in handling runtime changes.

Most apps do not need to make any changes to support this feature, but only if these apps follow Android best practices. Specific items to check for:

• sw320dp Test your app on a screen-wide device and make sure it runs well.
• Updates any density-related cache information, such as cached bitmaps or resources loaded from the network, when the device configuration changes. Check for configuration changes when the app resumes running from a paused state.

  Note: If you want to cache configuration-related data, it is also best to include related metadata, such as the screen size or pixel density for that data. Saving these metadata makes it easier for you to decide whether you need to refresh the cached data after you configure the changes.

• Avoid specifying dimensions in pixel units, because pixels do not scale with screen density. Instead, specify the dimensions using the density-independent pixel ( dp ) units.

Setting visual settings in the wizard

Android N adds "Vision Settings" to the "Welcome" screen, where users can set the following accessibility settings on the new device: magnification gesture,Font Size,Display size , and TalkBack. This change enhances the visibility of errors related to different screen settings. To evaluate the impact of this feature, you should test the app in a state where these settings are enabled. You can find these settings in Settings > Accessibility .

NDK app link to platform library

Android N has made some namespace changes to prevent the non-public API from loading. If you use the NDK, you can only use the exposed APIs provided by the Android platform. Using the non-public API on the next officially released Android version will cause the app to crash.

To remind you that a non-public API is used, an app running on an Android N device generates an error in the log message output when an app calls a non-public API. This error also appears as a message on the device screen to help enhance your awareness of this situation. You should check your app's code to remove the use of NonPublic platform APIs and test your app thoroughly using a preview device or simulator.

If your app relies on a platform library, see the NDK documentation for a typical fix that replaces the generic private API with exposing API equivalents. You can also link to the platform library without implementing the app, especially if the library used by the app is part of the platform (for example libpng ), but it's not part of the NDK. In this case, make sure that your APK contains all the. So files that you intend to link to.

Note: Some third-party libraries may be linked to non-public APIs. If your app uses these libraries, a crash may occur when your app runs on the next officially released version of Android.

Apps should not rely on or use native libraries that are not part of the NDK, as these libraries may change or migrate from one Android version to another. For example, switching from OpenSSL to Boringssl is a change of this kind. In addition, different devices may offer different levels of compatibility because there is no compatibility requirement for platform libraries that are not part of the NDK. If you must access a non-NDK library on an older device, load it according to the Android API level.

To help you diagnose such problems, here are some Java and NDK errors you might encounter when you try to develop your app using Android N:

Java Error Example:

Java.lang.UnsatisfiedLinkError:dlopen failed:library "/system/lib/libcutils.so" is not accessible for the    Namespace "Classloader-namespace"

NDK Error Example:

Dlopen failed:cannot Locate symbol "__system_property_get" referenced by ...

Here are some typical fixes for applications that encounter this type of error:

• You can use standard JNI functions instead of GETJAVAVM and getjnienv in libandroid_runtime.so:

  ANDROIDRUNTIME::GETJAVAVM, GETJAVAVM from <jni.h>androidruntime::getjnienv, javavm::getenv OrJavaVM:: Attachcurrentthread from <jni.h>.

•   alternative __system_property_get   to replace with   property_get   symbol. To do this, use __system_property_get   and the following include functions:

   #include    <SYS/SYSTEM_PROPERTIES.H>  

• You should use the local version of the app to replace libcrypto.so the SSL_ctrl symbols in use. For example, you should .so statically link in a file libcyrpto.a , or include your own dynamic from Boringssl or OpenSSL in your app libcrypto.so .

Android for work

Android N contains changes to apps that target Android for work, including changes to certificate installation, password reset, level two user management, and device identifier access. If you are developing an app for the Android for work environment, you should review these changes carefully and modify your app accordingly.

• You must install the Licensing certificate installer before DPC can set it up. For profile and device owner apps that target the N SDK, you should DevicePolicyManager.setCertInstallerPackage() Install the authorization Certificate installer before the device policy controller (DPC) call. If you have not already installed this installer, the system is raised IllegalArgumentException .
• The Reset password limit for device Administrators now also applies to the profile owner. Device administrators can no longer use DevicePolicyManager.resetPassword() to purge or change passwords that have been set. The device administrator can still set the password, but only if the device does not have a password, PIN, or pattern.
• The device owner and profile owner can manage the account even if a limit is set. And, even with DISALLOW_MODIFY_ACCOUNTS User restrictions, the device owner and profile owner can still invoke the account Management API.
• Device owners make it easier to manage level two users. When the device is running in device owner mode, the system automatically sets DISALLOW_ADD_USER the limit. This prevents users from creating unmanaged level two users. In addition CreateUser() , and createAndInitializeUser() methods have been deprecated and replaced by DevicePolicyManager.createAndManageUser() methods.
• The device owner can access the device identifier. The device owner can use DevicePolicyManagewr.getWifiMacAddress() the Wi-Fi MAC address to access the device. If Wi-Fi is never enabled on the device, this method returns a null value.
• The work mode setting Controls access to the work app. When working mode is off, the system initiator indicates that they are not available by making the work app appear dimmed. Enabling work mode restores normal behavior again.

For more information about the changes that you make to Android for work in Android N, see android for job update.

annotation retention

Android N fixes an error when annotation visibility is ignored. This issue enables runtime access annotations that should not be allowed. These annotations include:

• VISIBILITY_BUILD: should only be visible at compile time.
• VISIBILITY_SYSTEM: The runtime should be visible, but only for the base system.

If your app relies on this behavior, add a retention policy that must be available at run time in the annotations. You can do this by using it @Retention(RetentionPolicy.RUNTIME) .

Other important notes

• If an app is running on Android N, but is developed for a lower API level, the system terminates the app process when the user changes the display size. The app must be able to handle this scenario properly. Otherwise, the app crashes when the user resumes running the app from a recent usage record.

  You should test your app to make sure that this behavior does not occur. To perform this test, you can manually terminate the app with DDMS to cause the same crash.

  Applications that target N and later are not automatically terminated when density changes, but these applications may still respond negatively to configuration changes.

• Apps on Android N should be able to handle configuration changes normally and not crash on subsequent startup. You can change the font size (Setting > Display > fontsize) And then resume running the app from the most recent usage record to verify the app behavior.
• Due to an error in previous versions of Android, the system failed to report a TCP socket write operation on the main thread as a strict mode violation. Android N Fixed this error. The application that renders this behavior is raised android.os.NetworkOnMainThreadException . In general, we do not recommend that network operations be performed on the main thread, as these operations are usually likely to lead to high tail latencies for ANR and stutter.
• Debug.startMethodTracing() The method family now defaults to storing the output in a package-specific directory on your shared storage, not the top of the SD card. This means that the app no longer needs to request WRITE_EXTERNAL_STORAGE permission to use these APIs.
• Many platform APIs now start checking in   binder   the heavy load sent between transactions, the system will now   transactiontoolargeexceptions   again as  , runtimeexceptions   , and no longer just silently record or suppress them. A common example is the   activity.onsaveinstancestate ()   stores too much data, causing   activitythread.stopinfo raises   when your app targets Android N; .
•   view   publish   runnable   task, and   view   is not attached to the window, the system will use   view   is   runnable   task queued;   view   before attaching to the window, runnable   task does not execute. This behavior fixes the following error:
  • If an application is from a window UI that is not expected Other threads of the thread are published to   view , then runnable   The thread that may be running the error as a result.
  •  , runnable   The task is published from another thread that is not a loop route, the app may expose   runnable   task.
• If an app with DELETE_PACKAGES permission on Android N tries to delete a package, but another app already has the package installed, the system may require user confirmation. In this case, the application PackageInstaller.uninstall() 's return status at the time of invocation should be STATUS_PENDING_USER_ACTION .

Android7.0 Change of behavior