Improvement analysis of Android 7.0 version affecting development

This paper summarizes and analyzes the improvements that affect the development of Android 7.0. Share with you for your reference, as follows:

Low power consumption mode

It will limit alarm, GPS and Wi Fi scanning. Refer to optimizing for doze and app standby to use GCM to send and receive messages

Background optimization

Android n has deleted three implicit broadcasts, which will frequently start applications registered to listen to these broadcasts in the background. Deleting these broadcasts can significantly improve device performance and user experience

The broadcast of the main thread listening for network changes is changed to: connectivity_ CHANGE。 Action cannot be sent or accepted for all applications_ NEW_ Picture or action_ NEW_ VIDEO .

You can use the jobscheduler API. For more information, refer to background optimization

System permission change

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

The file permissions of private files should no longer be relaxed by the owner to use mode_ WORLD_ Readable and mode_ WORLD_ Such attempts made by writeable will trigger a SecurityException and cause the app to crash.

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

Deliver packages outside the domain file://URI The receiver may be left with an inaccessible path. So pass file://URI Fileuriexposedexception will be triggered. The recommended way to share private file content is to use fileprovider.

Downloadmanager no longer shares privately stored files by file name. The old app is accessing the column_ LOCAL_ An inaccessible path may appear when using filename. Applications developed for Android 7.0 or later are trying to access column_ LOCAL_ SecurityException is triggered when filename is. Old apps that set the download location to a public location by using downloadmanager. Request. Setdestinationinexternalfilesdir()) or downloadmanager. Request. Setdestinationinexternalpublicdir()) can still access the column_ LOCAL_ The path in filename, but Google strongly opposes this method. The preferred way to access files exposed by the downloadmanager is to use contentresolver. Openfiledescriptor()).

Sharing files between applications

For Android 7.0 applications, the strictmode API implemented by the Android framework is prohibited from being disclosed to your app file://URI 。 If an intent containing a file URI is sent outside your app, the app will have a fileuriexposedexception exception.

To share files between apps, you should send an item content://URI And grant temporary access to the URI. The easiest way to do this is to use the fileprovider class. For more information about permissions and sharing files, see sharing files.

Solve the error when installing APK on Android n: android.os.fileuriexposedexception:

Add the following code to androidmanifest.xml

be careful:

Authorities: package name of app. Fileprovider granturipermissions: must be true, which means granting temporary access permission to URI. Exported: must be false @ XML / file in resource:_ Paths is the file we will add next

Create a new XML folder and a new file in the res directory_ XML file of paths (as shown below)

Enter the following

Path: the path that needs temporary authorization to access (. Represents all paths) Name: you name the access path

Last modified code:

Screen zoom

Android 7.0 supports users to set the display size to enlarge or reduce all elements on the screen, so as to improve the accessibility of the device to users with poor vision. Users cannot zoom the screen below the minimum screen width sw320dp, which is the width of the nexus 4 and the width of a regular medium-sized phone.

When the device density changes, the system will notify running applications in the following ways:

1. If it is an application for API leve 23 or lower, the system will automatically terminate all its background processes. In other words, if the user leaves your app after switching and opens "Settings" to change the display size setting, the system will terminate the app as if it was out of memory. If the application has any foreground processes, the system will notify these processes of configuration changes as described in processing runtime changes, just like changing the direction of the device screen. For details, you can take a look at this hyperlink.

2. If it is an app for Android 7.0, all 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 be checked:

① Test your app on a device with a screen width of sw320dp and make sure it works properly.

② When the device config changes, update any density related cache information, such as cache bitmap or resources loaded from the network. When the application resumes running from the suspended state, check the change of config. Note: if you want to cache configuration related data, it is better to also include relevant metadata, such as the screen size or pixel density corresponding to the data. Save these metadata so that you can decide whether to refresh the cached data after config changes.

③ Avoid specifying dimensions in pixel units because pixels do not scale with screen density. Units such as DP should be used instead.

Users can modify the screen width in settings - display - display size, or set the specified width freely in settings - Developer options - minimum width. Developers need to pay special attention to adaptation

NDK platform library

Android n has made some namespace changes to prevent loading non-public APIs, and some common errors will occur

For example, unsatisfiedlinkerror

Typical repair methods:

1. Use standard JNI functions instead of libandroid_ Getjavavm and getjnienv in runtime.so 2. Use public alternative__ system_ property_ Get instead of using property in libcutils.so_ Get symbol 3. Use the local version of the application instead of SSL in libcrypto.so_ CTRL symbol

Annotation retention

Android 7.0 fixes errors when annotation visibility is ignored. This problem will enable runtime access annotations that should not be allowed. These notes include:

VISIBILITY_ Build: should only be visible at compile time. VISIBILITY_ System: it shall be visible during operation, but only for basic system. If your app relies on this behavior, please add a retention policy that must be available at runtime to the annotation. You can do this by using @ retention (retentionpolicy. Runtime).

Other important notes

1. If an app developed for a lower API level runs on Android 7.0, the system will terminate the app process when the user changes the display size. App must be able to handle this scenario normally. Otherwise, when the user resumes running the app from the recent usage record, the app will crash. You should test the application to ensure that this behavior does not occur. To perform this test, you can manually terminate the application through DDMS, which can cause the same crash. When the screen density changes, the system will not automatically terminate the app developed for Android 7.0 and later; However, these apps may still respond poorly to configuration changes.

2. The application on Android 7.0 should be able to handle configuration changes normally and will not crash during subsequent startup. You can verify app behavior by changing the font size (setting > display > font size) and then resuming running the app from the recent usage record.

3. Due to an error in the previous Android version, the system did not strictly check the write operation of a TCP socket on the main thread. Android 7.0 fixes this system error. Apps with this behavior will cause android.os.networkonmainthreadexception. In general, it is not recommended to perform network operations on the main thread, because these operations may lead to anr and Caton. This should be well known in and generally will not be committed.

4. The debug. Startmethodtracing () method family now stores the output in the package specific directory on your shared storage space by default, rather than the top level of the SD card. This means that the application no longer needs to request write_ EXTERNAL_ These APIs can be used with storage permission.

5. Many platform APIs now begin to check the large load sent between binder transactions. The system will now raise transactiontoolargeexceptions again as runtimeexceptions instead of just silently recording or not throwing this error. A common example is that too much data is stored on activity. Onsaveinstancestate()), which causes activitythread.stopinfo to cause a runtimeException when your app is facing Android 7.0.

6. If the application posts a runnable task to the view and the view is not attached to the window, the system will queue the runnable task with the view; The runnable task will not execute until the view is attached to the window. This behavior fixes the following errors:

① If an app is published to the view from another thread that is not the expected window UI thread, runnable may run incorrectly.

② If the runnable task is published from another thread that is not a looper thread, the application may expose the runnable task.

7. If delete is available on Android 7.0_ If an application with the permissions of packages attempts to delete a package, but another application has already installed the package, the system may ask the user to confirm. In this case, the return status of the application when calling packageinstaller. Uninstall()) should be status_ PENDING_ USER_ ACTION。

More readers interested in Android related content can view the special topics of this site: introduction and advanced tutorial of Android development, summary of Android debugging skills and common problem solving methods, summary of Android basic component usage, summary of Android view skills, summary of Android layout skills and summary of Android control usage

I hope this article will help you in Android programming.