android 6.0和7.0开发中应该注意的问题

做android开发的小伙伴们，是不是经常对android不同的版本的api搞得昏天黑地的，今天就说说android开发中6.0和7.0在开发中应该注意的一些地方1，6.0版本对安全新进行的改进，特别是针对权限的问题，我们知道以前使用权限只要在mainfest中注册就好，但是在6.0的时候光光是注册还是不够的，因为现在这个权限是询问的，除非在安装的时候让我们的用户自己手动的去设置这些权限，不过这个是不可能的，那么这个要怎么办呢这时我们就要用到动态的申请权限的问题，注意不管你在gradle中targetSdkVersion的版本

if (ContextCompat.checkSelfPermission(MainActivity.this, Manifest.permission.WRITE_EXTERNAL_STORAGE)!= PackageManager.PERMISSION_GRANTED) {//申请WRITE_EXTERNAL_STORAGE权限ActivityCompat.requestPermissions(MainActivity.this, new String[]{Manifest.permission.WRITE_EXTERNAL_STORAGE},6);}else {

//你的逻辑代码

}

@Overridepublic void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {super.onRequestPermissionsResult(requestCode, permissions, grantResults);if (requestCode == 6) {if (grantResults[0] == PackageManager.PERMISSION_GRANTED) {//逻辑代码} else {Toast.makeText(this, "请在应用管理中打开“读写手机存储”访问权限！", Toast.LENGTH_LONG).show();finish();}}}

当然上面的是原始的写法，大家也可以去网上找一些框架

2,7.0的问题

前两天开发时发现更新时不能掉用系统的安装，用7.0以下的手机发现没有问题

从Android 7.0开始，一个应用提供自身文件给其它应用使用时，如果给出一个file://格式的URI的话，应用会抛出FileUriExposedException。这是由于谷歌认为目标app可能不具有文件权限，会造成潜在的问题。所以让这一行为快速失败。详见这里。这里讨论两种解决方式。1 FileProvider方式这是谷歌官方推荐的解决方案。即使用FileProvider来生成一个content://格式的URI。具体实现方式如下：manifest声明 在manifest中声明一个provider。name（即类名）为android.support.v4.content.FileProvider。

<manifest>...<application>...<providerandroid:name="android.support.v4.content.FileProvider"android:authorities="com.mydomain.fileprovider"android:exported="false"android:grantUriPermissions="true"><meta-dataandroid:name="android.support.FILE_PROVIDER_PATHS"android:resource="@xml/file_paths" /></provider>...</application></manifest>

1234567891011121314151612345678910111213141516其中authorities可以自定义。为了避免和其它app冲突，最好带上自己app的包名。file_paths.xml中编写该Provider对外提供文件的目录。文件放置在res/xml/下。 2.编写file_paths.xml 文件格式如下：

<paths xmlns:android="http://schemas.android.com/apk/res/android"><files-path name="my_images" path="images/"/>...</paths>

12341234内部的element可以是files-path，cache-path，external-path，external-files-path，external-cache-path，分别对应Context.getFilesDir()，Context.getCacheDir()，Environment.getExternalStorageDirectory()，Context.getExternalFilesDir()，Context.getExternalCacheDir()等几个方法。后来翻看源码发现还有一个没有写进文档的，但是也可以使用的element，是root-path，直接对应文件系统根目录。不过既然没有写进文档中，其实还是有将来移除的可能的。使用的话需要注意一下风险。3.在Java代码当中使用 以分享一个图片为例：

File file = ...;    //要分享的图片文件Uri uri = FileProvider.getUriForFile(context, "com.mydomain.fileprovider", file);    //第二个参数是manifest中定义的`authorities`Intent intent = new Intent(Intent.ACTION_SEND);intent.setType("image/*");intent.putExtra(Intent.EXTRA_TITLE, title);intent.putExtra(Intent.EXTRA_TEXT, text);intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);    //这一步很重要。给目标应用一个临时的授权。startActivity(intent);    //或者其它最终处理方式

12345678123456782 VmPolicy方式以上方法固然是推荐使用的，正确的方法。但是我在实际开发中遇到这样的问题。某些应用（此处点名新浪微博）根本无法理解一个指向文件的content://格式的URI。新浪微博接收到这类URI之后，无法加载图片，并会在点击发送微博时崩溃。 另一方面，新浪微博对权限管理的处理采取了一种比较流氓的方式。它会在启动时申请文件读写权限，而如果拒绝该权限的话，居然就直接退出了。我反正是不信什么需要文件权限来放缓存放数据的说辞。放缓存放数据有着一堆不需要权限的目录可用。但是这样一来，我们其实是不需要担心传递一个file://格式URI过去而对方没有权限的。 话说回来，如何解决这一问题呢？我在调研的时候观察到严格模式的一个方法：StrictMode.VmPolicy.Builder.detectFileUriExposure()。顾名思义，调用这个方法就会检测FileUriExposure这件事。这个方法其实从API18就有了，是不是有可能在API24变成了默认选项呢？ 在Application.onCreate加入如下代码，置入一个不设防的VmPolicy：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {StrictMode.VmPolicy.Builder builder = new StrictMode.VmPolicy.Builder();StrictMode.setVmPolicy(builder.build());}

12341234再用旧的方式直接把file://格式的URI发送出去。居然成功了，没有再抛出FileUriExposedException。