Experienced driver talks about racing technology: Android 7.0 adaptation experience

Android 7.0 has been released for more than a month. While bringing some new features to users, it also brings new challenges to developers. In the past few days, I have adapted my application to Android 7.0, and encountered many problems and stepped into some pitfalls. Here I would like to share some of my experience in Android 7.0 adaptation with you, so that your application can run on Android 7.0 one day earlier.

Permission changes

As Android versions get higher and higher, Android's privacy protection is getting stronger and stronger. From the dynamic permission control (Runtime Permissions) introduced in Android 6.0 to the "private directory restricted access" and "Strict Mode API policy" in Android 7.0. These changes not only bring a more secure operating system to users, but also bring some new tasks to developers. How to make your APP adapt to these changes instead of cash is the responsibility of every Android developer.

Directory access is restricted

iOS has always done a good job in protecting access to directories and files, such as the iOS sandbox mechanism. However, Android's protection in this regard is somewhat weak. In Android, applications can read and write any directory and file in the phone's storage, which also brings many security issues. Now Android is also working hard to solve this problem.

In order to improve the security of private files in Android 7.0, access to private directories of apps targeting Android N or higher versions will be restricted. Developers need to pay attention to the following changes to this permission:

• The file permissions of private files are no longer delegated to all applications. Operations performed using MODE_WORLD_READABLE or MODE_WORLD_WRITEABLE will trigger a SecurityException.

Response strategy: This permission change means that you can no longer access data on the phone storage through the File API. Some file browsers based on the File API will also be greatly affected. Are you shocked to see this? However, so far, this restriction has not been fully implemented. Applications may still use native APIs or File APIs to modify their private directory permissions. However, Android officials strongly oppose relaxing the permissions of private directories. It can be seen that retracting access to private files is the future development trend of Android.

• Passing a file:// URI to another application may cause the recipient to be unable to access the path. Therefore, in Android 7.0, attempting to pass a file:// URI will trigger a FileUriExposedException.

Solution: You can solve this problem by using FileProvider.

• DownloadManager no longer shares privately stored files by file name. COLUMN_LOCAL_FILENAME is marked as deprecated in Android 7.0. Older apps may encounter inaccessible paths when accessing COLUMN_LOCAL_FILENAME. Apps targeting Android N or higher will trigger a SecurityException when trying to access COLUMN_LOCAL_FILENAME.

Solution: You can access files exposed by DownloadManager through ContentResolver.openFileDescriptor().

Share files between apps

On Android 7.0, the Android framework enforces the StrictMode API policy to prohibit exposing file:// URIs outside your app. If an Intent containing a file:// URI leaves your app, the app fails with a FileUriExposedException, such as calling the system camera to take a photo or cropping a photo.

Solution: To share files between apps, you can send a Uri of type content:// URI and grant temporary access to the URI. The simplest way to grant this permission is to use the FileProvider class. For more information about permissions and sharing files, see Sharing Files.

Call the system camera to take photos and crop photos on Android 7.0

Call the system camera to take pictures

Before Android 7.0, if you want to call the system camera to take a photo, you can use the following code:

 File file=new File(Environment.getExternalStorageDirectory(), "/temp/" +System.currentTimeMillis() + ".jpg" ); 
 
 if (!file.getParentFile().exists())file.getParentFile().mkdirs(); 
 
 Uri imageUri = Uri.fromFile(file); 
 
 Intent intent = new Intent(); 
 
 intent.setAction(MediaStore.ACTION_IMAGE_CAPTURE); //Set Action to take photo 
 
 intent.putExtra(MediaStore.EXTRA_OUTPUT, imageUri); //Save the captured photo to the specified URI 
 
 startActivityForResult(intent,1006);

Using the above method to call the system camera on Android 7.0 will throw the following exception:

 android.os.FileUriExposedException: file:////storage/emulated/0/ temp /1474956193735.jpg exposed beyond app through Intent.getData() at android.os.StrictMode.onFileUriExposed(StrictMode.java:1799) at android.net.Uri.checkFileUriExposed(Uri.java:2346) at android.content.Intent.prepareToLeaveProcess(Intent.java:8933) at android.content.Intent.prepareToLeaveProcess(Intent.java:8894) at android.app.Instrumentation.execStartActivity(Instrumentation.java:1517) at android.app.Activity.startActivityForResult(Activity.java:4223)... at android.app.Activity.startActivityForResult(Activity.java:4182)

This is because Android 7.0 implements the "StrictMode API policy ban", but don't worry, as mentioned above, you can use FileProvider to solve this problem. Now let's solve this problem step by step.

Using FileProvider

The general steps to use FileProvider are as follows:

Step 1: Register the provider in the manifest file

 <provider 
 
    android: name = "android.support.v4.content.FileProvider"   
 
    android:authorities= "com.jph.takephoto.fileprovider"   
 
    android:grantUriPermissions= "true"   
 
    android:exported= "false" > 
 
 <meta-data 
 
        android: name = "android.support.FILE_PROVIDER_PATHS"   
 
        android:resource= "@xml/file_paths" /> 
 
 </provider>

Tips: exported: must be false. If it is true, a security exception will be reported. grantUriPermissions: true means granting temporary access rights to the URI.

Step 2: Specify the shared directory

In order to specify the shared directory, we need to create an XML directory under the resource (res) directory, and then create a resource file named "file_paths" (the name can be any, as long as it is consistent with the resource referenced by the provider registered in the manifest), the content of which is as follows:

 <?xml version= "1.0" encoding= "utf-8" ?> 
 
 <resources> 
 
 <paths> 
 
        <external-path path= ""   name = "camera_photos" /> 
 
 </paths> 
 
 </resources>

• Represents the root directory: Context.getFilesDir()
• Represents the root directory: Environment.getExternalStorageDirectory()
• Represents the root directory: getCacheDir()

Tips: path="" in the above code has a special meaning. It refers to the root directory, which means you can share any file in the root directory and its subdirectories with other applications. If you set path to path="pictures", it means the pictures directory under the root directory (eg:/storage/emulated/0/pictures). If you share files outside the pictures directory with other applications, it will not work.

Step 3: Use FileProvider

After completing the above preparations, we can now use FileProvider.

Taking the example of calling the system camera to take a photo, we need to modify the above photo code to the following:

 File file=new File(Environment.getExternalStorageDirectory(), "/temp/" +System.currentTimeMillis() + ".jpg" ); 
 
 if (!file.getParentFile().exists())file.getParentFile().mkdirs(); 
 
 Uri imageUri = FileProvider.getUriForFile(context, "com.jph.takephoto.fileprovider" , file); //Create a content type Uri through FileProvider 
 
 Intent intent = new Intent(); 
 
 intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION); //Add this sentence to indicate that the target application is temporarily authorized to use the file represented by the Uri 
 
 intent.setAction(MediaStore.ACTION_IMAGE_CAPTURE); //Set Action to take photo 
 
 intent.putExtra(MediaStore.EXTRA_OUTPUT, imageUri); //Save the captured photo to the specified URI 
 
 startActivityForResult(intent,1006);

There are two main changes in the above code:

1. The previous Uri with a scheme type of file is changed to a Uri of content type created by FileProvider.
2. Added intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION); to temporarily authorize the target application to use the file represented by the Uri.

Experience: The above code uses the FileProvider Uri getUriForFile (Context context, String authority, File file) static method to obtain Uri. The authority parameter in this method is the android:authorities="com.jph.takephoto.fileprovider" of the provider registered in the manifest file. Friends who are familiar with Web servers such as tomcat and IIS only know that for the security and efficiency of website content, Web servers support setting a virtual directory for website content. In fact, FileProvider also has the same purpose.

Print the Uri obtained by the getUriForFile method as follows:

 content://com.jph.takephoto.fileprovider/camera_photos/ temp /1474960080319.jpg`.

Among them, camera_photos is the name of paths in file_paths.xml.

Because the path specified above is path="", the actual path represented by content://com.jph.takephoto.fileprovider/camera_photos/ is the root directory, that is: /storage/emulated/0/.

The real path represented by content://com.jph.takephoto.fileprovider/camera_photos/temp/1474960080319.jpg is: /storage/emulated/0/temp/1474960080319.jpg.

In addition, I recommend that you use the open source tool library TakePhoto. TakePhoto is an open source tool library for acquiring photos (taking photos or selecting from albums or files), cropping pictures, and compressing pictures on Android devices.

Crop photos

Before Android 7.0, you can crop photos using the following methods:

 File file=new File(Environment.getExternalStorageDirectory(), "/temp/" +System.currentTimeMillis() + ".jpg" ); 
 
 if (!file.getParentFile().exists())file.getParentFile().mkdirs(); 
 
 Uri outputUri = Uri.fromFile(file); 
 
 Uri imageUri=Uri.fromFile(new File( "/storage/emulated/0/temp/1474960080319.jpg" )); 
 
 Intent intent = new Intent( "com.android.camera.action.CROP" ); 
 
 intent.setDataAndType(imageUri, "image/*" ); 
 
 intent.putExtra( "crop" , "true" ); 
 
 intent.putExtra( "aspectX" , 1); 
 
 intent.putExtra( "aspectY" , 1); 
 
 intent.putExtra( "scale" , true ); 
 
 intent.putExtra(MediaStore.EXTRA_OUTPUT, outputUri); 
 
 intent.putExtra( "outputFormat" , Bitmap.CompressFormat.JPEG.toString()); 
 
 intent.putExtra( "noFaceDetection" , true ); // no face detection 
 
 startActivityForResult(intent,1008);

Just like taking photos, the above code will also cause android.os.FileUriExposedException on Android 7.0. The solution is to use FileProvider as mentioned above.

Then, change the above code to the following:

 File file=new File(Environment.getExternalStorageDirectory(), "/temp/" +System.currentTimeMillis() + ".jpg" );if (!file.getParentFile().exists())file.getParentFile().mkdirs();Uri outputUri = FileProvider.getUriForFile(context, "com.jph.takephoto.fileprovider" ,file);Uri imageUri=FileProvider.getUriForFile(context, "com.jph.takephoto.fileprovider" , new File( "/storage/emulated/0/temp/1474960080319.jpg" );//Create a UriIntent of content type through FileProvider intent = new Intent( "com.android.camera.action.CROP" );intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);intent.setDataAndType(imageUri, "image/*" );intent.putExtra( "crop" , "true" );intent.putExtra( "aspectX" , 1);intent.putExtra( "aspectY" , 1);intent.putExtra( "scale" , true );intent.putExtra(MediaStore.EXTRA_OUTPUT, outputUri);intent.putExtra( "outputFormat" , Bitmap.CompressFormat.JPEG.toString());intent.putExtra( "noFaceDetection" , true ); // no face detectionstartActivityForResult(intent,1008);

In addition, for cropping photos, I recommend that you use the open source tool library TakePhoto. TakePhoto is an open source tool library for acquiring photos (taking photos or selecting from albums or files), cropping pictures, and compressing pictures on Android devices.

Battery and memory

Android 6.0 (API level 23) introduced Low Power Mode, and Android 7.0 made further optimizations in battery and memory to reduce the power consumption and memory usage of Android applications. Some changes in rules brought about by these optimizations may affect your application's access to system resources and the way your system interacts with other applications through specific implicit intents. So developers need to pay special attention to these changes.

Doze

In Doze, when the user's device is not plugged in, is stationary, and the screen is off, the mode postpones CPU and network activity to extend battery life. Android 7.0 further enhances Doze by applying some CPU and network restrictions when the device is not plugged in and the screen is off, but not necessarily stationary (for example, when the user is out and about with a handheld device in their pocket).

In other words, Android 7.0 will limit the application's use of the CPU and network when the phone screen is turned off.

The specific rules are as follows:

1. When the device is charging and the screen has been off for a certain amount of time, the device enters Doze and applies the first set of restrictions: turning off app network access, deferring jobs, and syncing.
2. If the device is stationary for a certain amount of time after entering Doze, the system applies the remaining Doze restrictions for PowerManager.WakeLock, AlarmManager alarms, GPS, and Wi-Fi scanning. Whether some or all Doze restrictions are applied, the system wakes the device for a brief maintenance window during which apps can access the network and perform any deferred work/sync.

Background optimization

As we all know, there are some implicit broadcasts in Android. These implicit broadcasts can be used to perform some specific functions, such as automatically downloading update packages when the mobile network becomes WiFi. However, these implicit broadcasts will frequently start applications that have registered to listen to these broadcasts in the background, resulting in a large consumption of power. To alleviate this problem and improve device performance and user experience, three implicit broadcasts have been deleted in Android 7.0 to help optimize memory usage and power consumption.

Android 7.0 applies the following optimizations:

1. On Android 7.0, apps will not receive CONNECTIVITY_ACTION broadcasts, even if you have requested notifications for these events in your manifest. However, apps running in the foreground can still listen for CONNECTIVITY_CHANGE in the main thread if they request notifications using BroadcastReceiver.
2. On Android 7.0, apps cannot send or receive broadcasts of type ACTION_NEW_PICTURE or ACTION_NEW_VIDEO.

Solution: The Android framework provides several solutions to alleviate the need for these implicit broadcasts. For example, the JobScheduler API provides a robust and reliable mechanism to schedule network operations to be performed when specified conditions are met (such as connecting to a wireless network). You can even use the JobScheduler API to adapt to content provider changes.

In addition, if you want to know more about background optimization, you can refer to Background Optimization.

Mobile devices experience frequent connectivity changes, such as when switching between Wi-Fi and mobile data. Apps can now monitor these changes by registering a receiver in the app manifest to listen for the implicit CONNECTIVITY_ACTION broadcast. Since many apps register to receive this broadcast, a single network switch can cause all apps to wake up and handle the broadcast simultaneously.