Android 7.0 Behavioral changes-developers should focus on (official website simultaneous translation)

Android 7.0 Behavioral changes-developers should focus on (official website simultaneous translation)

Copyright NOTICE: Reprint must indicate this article transferred from Zhangjie's blog: http://blog.yanzhenjie.com

If you want to learn more about Android7.0, you can also see a letter from Android7.0 to the developer (translated by the official website).

If your citation is good enough, you are recommended to read the official website article:
Android 7.0 Behavior Changes

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 leve 23) introduces a low-power mode that delays CPU and network access when the user device is unplugged, in a stationary state, and the screen is turned off, prolonging battery life. While Android 7.0 uses some CPU and network restrictions when the device is unplugged and the screen is off, but not necessarily in a stationary state (such as when a user is out in the car), the low power consumption mode is further enhanced.

How low power consumption mode applies the first-level system activity limit to extend the battery life diagram:

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 work and sync. If the device is in a stationary state after entering a low power consumption mode, the system will PowerManager.WakeLock restrict,,, AlarmManager 闹铃 GPS and apply the low power Wi-Fi扫描 consumption mode. Whether you apply a partial limit or all of the low power mode restrictions, the system wakes up the device to provide a short maintenance window, during which the application can access the network and perform all deferred work/sync.

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 the previous limit. This new behavior does not affect the recommendations and best practices for adapting your app to the old version of the low-power mode released in Android 6.0 (API Leve23), such as low-power mode and the content mentioned in applying standby mode optimizations. You should still follow these recommendations (such as using Google Cloud Messaging (GCM) to send and receive messages) and be compatible with the new low power consumption mode.

Project Svelte: Background optimization

Android 7.0 removes three implicit broadcasts, optimizes memory usage and optimizes 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 Manifest.xml listen to implicit connectivity_action broadcasts by registering one in BroadcastRecevier , allowing the application to monitor these changes. Because many apps 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, applications can register to receive implicit Action_new_picture and Action_new_video broadcasts from other applications, such as cameras. When a user takes a photo using the camera app, the apps are awakened to process the broadcast.

To mitigate the above issues, Android 7.0 uses the following optimizations:

• Apps developed for Android 7.0 do not receive connectivity_action broadcasts, even if they are already registered in the receive Manifest.xml this broadcast BroadcastRecevier because they will not be received. Apps that run in the foreground BroadcastReceiver can still listen in the main thread if they use receive notifications CONNECTIVITY_CHANGE .
• Apps cannot be sent or received ACTION_NEW_PICTURE or ACTION_NEW_VIDEO broadcast. This change will affect all apps, not just apps developed for Android 7.0.

If your app uses any implicit intent, you still need to remove their dependencies as soon as possible to properly fit the Android 7.0 device. The Android framework provides multiple solutions to mitigate the need for these implicit broadcasts. For example, the Jobscheduler 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 Jobscheduler to adapt to Content providers change.

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

Permission changes

Android 7.0 has made some permissions changes that may affect your app.

System Permissions Change

In order to improve the security of private files, the app Private directory for Android 7.0 or later is restricted access (0700). This setting prevents the metadata disclosure of private files, such as their size or presence (status). Changes to this permission policy have multiple side effects:

• File permissions for private files should no longer be relaxed by the owner, and such attempts to use mode_world_readable and mode_world_writeable will trigger SecurityException, which can cause the app to crash.

  Note: So far, this limitation has not been fully implemented. Apps may still use native APIs or the file API to modify their private directory permissions. But Google strongly opposes the privilege of relaxing a private directory.

• Passing the File://URI of the package domain may leave the receiver with inaccessible paths. So passing File://URI will trigger FileUriExposedException . The recommended way to share private file content is to use Fileprovider.

• Downloadmanager no longer shares private stored files by file name. The old app may have inaccessible paths when accessing Column_local_filename. Apps developed for Android 7.0 or later will trigger SecurityException when attempting to access column_local_filename. By using the DownloadManager.Request.setDestinationInExternalFilesDir () or DownloadManager.Request.setDestinationInExternalPublicDir () The old app that sets the download location to a public location can still access the path in Column_local_filename. But Google strongly opposes the use of this approach. The preferred way to access files exposed by Downloadmanager is to use Contentresolver.openfiledescriptor ().

Sharing files between apps

For Android 7.0 apps, the Strictmode API enforced by the Android framework prohibits exposing to your app file://URI . If a intent that contains a file URI is sent to your app, an exception will occur for the app FileUriExposedException .

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

Barrier-free Improvement

Android 7.0 made some changes to improve the usability of the platform for poor eyesight or visually impaired users. These changes normally do not need to change your code, but you need to examine them carefully and test them with your app to assess their potential impact on the user experience.

Screen Zoom

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

Android 7.0 System Image normal size running effect:

Android 7.0 System image increases the effect of displaying dimensions:

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

• If it is an app for an API Leve 23 or earlier system, all of its background processes are automatically terminated. This means that if the user switches away from your app and opens "Settings" To change 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 the run-time changes, just as the device screen orientation changes, so you can look at this hyperlink again.
• If it is an app for Android 7.0, all of its processes (foreground and background) will receive notifications about configuration changes, as described in handling runtime changes.
  Most apps don't need to make any changes to support this feature, but only if these apps follow Android best practices. Specific things to check:
  
  • Test your app on a device with a screen width of sw320dp and make sure it works.
  • Updates any density-related cache information, such as cached bitmaps or resources loaded from the network, when device config changes. Check the change of config when the app resumes running from the 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 allows you to decide whether you need to refresh the cached data after the config change.

  • Avoid specifying dimensions in pixel units, because pixels do not scale with screen density. You should use units such as DP instead.

Visual settings in the Setup Wizard Android 7.0 adds "Vision Settings" to the "Welcome" page, where users can operate ' accessibility settings ' on new devices: ' magnification gesture ', ' Font size ', ' Display size ' and ' TalkBack '. This change increases the visibility of errors associated with different screen settings. To test the impact of this feature, you should test the app in a state where these settings are enabled, and you can find these settings in ' Settings > Accessibility '. NDK app link to platform library Android 7.0 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 7.0 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 the situation. You should check the app code to remove the use of nonpublic APIs and test the app thoroughly using a preview device or simulator. If your app relies on a platform library, see the NDK documentation for fixes that replace the normal private API with the public API equivalent. 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 is 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, it may crash when your app runs on the next officially released version of Android, so you should also check to see if the third-party libraries you use use non-public APIs, such as Baidu maps.

Apps should not rely on or use native libraries that are not part of the NDK, as these libraries may change or change from one version of Android 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:

"/system/lib/libcutils.so"    for"classloader-namespace"

NDK Error Example:

"__system_property_get" referenced by ...

Here are some typical fixes for applications that encounter such errors: * 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>.

• You can use public alternative __system_property_get to replace libcutils.so symbols in use property_get . If you want to do this, use __system_property_get the following include function:

#include <sys/system_properties.h>

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

Android for work

Android 7.0 includes Android for Work changes to application-oriented applications, including changes to certificate installation, password reset, level two user management, and device identifier access. If you are developing an Android for Work app for your environment, you should review these changes carefully and modify your app code accordingly.

• You must install the authorization Certificate installer before DPC can set it up. For 7.0 SDK profile-oriented and device owner apps, 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, device owners and profile owners can still be called 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 the DISALLOW_ADD_USER limit. This prevents users from creating unmanaged level two users. In addition, the method CreateUser() createAndInitializeUser() has been deprecated and replaced by the method DevicePolicyManager.createAndManageUser() .

• The device owner can access the device identifier. The device owner can use DevicePolicyManagewr.getWifiMacAddress() the address of the access device Wi-Fi MAC . 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 made in Android 7.0 Android for Work , see Android for work update.

annotation retention

Android 7.0 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 @retention (Retentionpolicy.runtime).

Other important notes

• If an app developed for a lower API level runs on Android 7.0, the app process will be terminated 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 application via DDMS, which can cause the same crash. Apps developed for Android 7.0 and later are not automatically terminated when screen density changes, but these apps may still respond poorly to configuration changes.

• Apps on Android 7.0 should be able to handle configuration changes normally and not crash on subsequent startup. You can verify app behavior by changing the font size (Setting > Display > Font size) and then resuming the app from the most recently used record.

• Due to an error in previous versions of Android, the system does not strictly check the write operation of a TCP socket on the main thread. Android 7.0 Fixed this system error. Apps that previously had this behavior will be triggered android.os.NetworkOnMainThreadException . In general, it is not recommended to perform network operations on the main thread, as these operations are usually likely to result in ANR and stutter, which should be well known and generally not committed.

• 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 apps no longer need to request WRITE_EXTERNAL_STORAGE permissions to use these APIs.

• Many platform APIs now begin to check the heavy load sent between binder transactions, and the system will now be TransactionTooLargeExceptions RuntimeExceptions thrown again, rather than silently logging or not throwing the error. A common example is storing too much data on activity.onsaveinstancestate (), causing it to ActivityThread.StopInfo be thrown when your app targets Android 7.0 RuntimeException .

• If the app runnable a task to the view post and the view is not attached to the window, the system will queue with view for the runnable task, and the runnable task will not execute until the view is attached to the window. This behavior fixes the following error:

  • If an app is published to view from another thread that is not the expected window UI thread, you Runnable might run an error.
  • If the Runnable task is published from another thread that is not looper thread, the app may expose runnable tasks.

• If an app with delete_packages permission on Android 7.0 tries to delete a package, but another app already has the package installed, the system may require user confirmation. In this case, the application's return status when calling Packageinstaller.uninstall () should be status_pending_user_action.

If you want to learn more about Android7.0, you can also see a letter from Android7.0 to the developer (translated by the official website).

Copyright NOTICE: Reprint must indicate this article transferred from Zhangjie's blog: http://blog.yanzhenjie.com

Android 7.0 Behavioral changes-developers should focus on (official website simultaneous translation)