今天用的是Android10真机，需要的权限都申请了，还是遇到了这个问题。

W/System.err: java.io.FileNotFoundException: /storage/emulated/0/xxx.cfg: open failed: EACCES (Permission denied)

Android Q最大的变化莫过于是对用户隐私权的进一步保护，其中有一个feature更是让Android用户（尤其是国内用户）拍手称快，这就是分区存储(Scoped Storage, 也有翻译为存储沙盘化的)。截止目前，Google已经发布了Android Q的第4个beta版本(QPP4)，想必许多开发者已经开始适配（踩坑）了。最近为了不在年底的时候手忙脚乱，本人也在开始准备Q的适配了。目前关于Scoped Storage适配的文章已经不少了，但个人觉得大多都讲得太泛，缺乏实际的操作指南，看完之后还是有些云里雾里。于是，笔者决定结合现有的文章，自己以实际行动踩坑，总结一些实际的适配技巧。
  本文也不打算写成一篇大而全的适配指南，只是为了补充现有适配文章的一些不足，讲一些个人经实践验证过的Scoped Storage适配技巧。
  关于Scoped Storage在Android Q上的所有行为都是在AndroidStudio上的模拟器上验证的，模拟器系统版本为QPP4。

关于Scoped Storage

关于Scoped Storage在开始之前，先简单说说Scoped Storage的理解。要理解Google引入这个feature的原因，你只需要随便找一台Android手机，打开文件管理器：

image

Google想必也是听到了用户们的抱怨，下决心要好好管一管这个事了，引入了Scoped Storage来防止App们到处建文件夹的行为，而且态度还挺强硬，不管你targetSDK调不调到29，反正只要运行在Q上，Scoped Storage就会强制适用。所以在第二个beta版本发布后，很多用户发现不少APP包括微信的媒体选择器都挂了。但这没持续多久，Google就心软了，在beta3时又放宽了适用策略，表示给大家一些适配的时间，但是明年Android R发布时就不给机会了，一律强制适用。

到目前为止，Scoped Storage的适用策略如下：

• targetSDK = 29, 默认开启Scoped Storage, 但可通过在manifest里添加requestLegacyExternalStorage = true关闭;
• targetSDK < 29, 默认不开启Scoped Storage, 但可通过在manifest里添加requestLegacyExternalStorage = false打开;

有两点要注意：

1. 当你的targetSDK < 29，并且想通过requestLegacyExternalStorage来打开Scoped Storage策略时，你需要把compileSdkVersion上调到29, 否则会编译失败。另外，可在运行时通过Environment.isExternalStorageLegacy()判断Scoped Storage策略是否打开。
2. 当修改了requestLegacyExternalStorage属性的值，必须要卸载掉旧APK，重新安装才会生效。

接下来我们通过实际的例子来对比Scoped Storage策略适用前后的一些行为变化。

适配心得

1. getExternalStorageDirectory(), getExternalStoragePublicDirectory()读写权限变化

在之前，只要你有外部存储权限，你可以通过以下的操作，在内部储存肆意构建自己的目录结构：

    File dir = new File(Environment.getExternalStorageDirectory(), "my_dir");
    if(!dir.exists()){
        dir.mkdir();
    }

但是Scoped Storage引入后，你会发现以上代码根本不起作用了，这样APP就无法再乱建文件夹啦。

2. Java File API, BitmapFactory.decodeFile()无法读写app-specific目录之外的地方

• app-specific目录：即通过context. getExternalFilesDir()返回的目录，一般为/storage/emulated/0/Android/data/<package name>/files/, 这是属于APP的私有目录，在该目录下的读写是不需要申请权限的，当APP卸载时，系统会清理该目录。值得一提的是，在Q之前，其他拥有外部存储权限的APP其实也是可以读写该目录的，但从Q开始，这个行为被禁止了。

当你获取到一个app-specific目录之外的文件路径时，你也许会这么这么做： 将文件路径传给FileOutputStream或者FileWriter，然后开始读写操作；又或者该文件是张图片，你通过BitmapFactory.decodeFile()来获取到Bitmap对象。

比如我在项目中曾见过这种做法：通过MediaStore API中的DATA字段获取到图片的路径，接着就通过BitmapFactory.decodeFile()获取Bitmap对象。

只要你获得了外部存储权限， 这么做没问题。但Scoped Storage适用之后， 这些行为也被禁止了。谷歌推荐采用FileDescriptor的方式，如下：

    ContentResolver cr = context.getContentResolver();
    ParcelFileDescriptor fd = cr.openFileDescriptor(captureUri, "r");

    //接下来就可以读写了
    FileInputStream istream = new FileInputStream(fd.getFileDescriptor());//读
    FileOutputStream ostream = new FileOutputStream(fd.getFileDescriptor());//写

    //对于图片的情况，可以这么做
    Bitmap bitmap = BitmapFactory.decodeFileDescriptor(fd.getFileDescriptor());

顺便提一下，关于Media.DATA， 在Scoped Storage的官方介绍页面里也有这么一句话：

Don't load media files using the deprecated DATA columns.

想必大家也注意到了，以上操作都必须是在获取了文件Uri的前提下才能进行，文件Uri的获取方式很多，这里不展开讨论。你只需要知道，你无法再通过文件路径跟app-specific目录外的文件打交道了。

3. APP产生的文件只能通过MediaStore API写入磁盘

前面也提到了，你无法直接通过文件路径来读写app-specific目录外的位置了。你也许会说那我往app-specific里存不就完事了吗，更不用申请存储权限， 还不怕被其他应用窥探到文件内容。是的，谷歌确实推荐这么做，但并不是所有的数据都适合放在这里。假如你的APP是图像或视频类应用，使用过程中产生的图片视频就不适合放在app-specific里，首先是这个目录路径太深，用户不好查找，其次是这一类数据用户不希望随应用卸载而被删掉。所以必须要寻求放在app-specific目录之外的地方。但正如前面所说，你必须要有Uri才能读写，这个时候你就得用到MediaStore API了，下面以创建图片为例:

    ContentValues contentValues = new ContentValues();
    contentValues.put(MediaStore.Images.Media.DISPLAY_NAME, fileName);
    contentValues.put(MediaStore.Images.Media.DATE_TAKEN, System.currentTimeMillis());
    contentValues.put(MediaStore.Images.Media.MIME_TYPE, "image/jpeg");
    Uri uri = context.getContentResolver().insert(MediaStore.Images.Media.EXTERNAL_CONTENT_URI, contentValues);

那么这个时候你就有了一个Uri了，接着就可以按照上述所提到的使用FileDescriptor的方式去写文件了。不过这也有个问题，你往MediaStore里插入一条记录后，对应Uri就可能被其他应用检索到，但又可能找不到这条记录对应的那个文件（因为此时你的文件可能还没真正写入），这个问题Google也给了一个解决方案。

再看另外一个更为常见的例子—调用相机拍摄并存储照片，这个操作在Android Developer上的training中提供了最佳实践，这个例子中将照片存在了app-specific目录，但在实际业务中我们更可能是放在app-specific目录之外，只要你有外部存储权限，这是可以做到的，但是在Scoped Storage策略下，你必须得通过MediaStore API来产生照片的Uri了，然后通过以下语句传给Intent takePictureIntent.putExtra(MediaStore.EXTRA_OUTPUT, photoURI);

那么接下来你可能会有两个问题：

• 问题1

上面通过MediaStore创建Uri的时候，我们没有指定文件路径(MediaStore.Images.Media.DATA)，那文件最终会存到哪？

系统会按分类自动帮你存入到相应的文件夹下，默认在Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_XXXX)返回的路径下，比如图片就是Environment.DIRECTORY_PICTURES， 音频文件就是Environment. DIRECTORY_MUSIC……

• 问题2

这样的话那我的APP产生的图片岂不是跟其他APP的图片放在通过文件夹下，这样不是也很混乱吗？ 不用担心，你可以通过Media.RELATIVE_PATH建立自己的二级目录，假如上面的图片我想放到Pictures/MY_PIC/目录下，只需要这么做：

contentValues.put(MediaStore.Images.Media.RELATIVE_PATH, Environment.DIRECTORY_PICTURES + "/MY_PIC");

图片也不一定只能存到Pictures中，也可以放到DCIM目录中，也通过上述字段来实现，但如果你这么做的话:

contentValues.put(MediaStore.Images.Media.RELATIVE_PATH, Environment. DIRECTORY_MOVIES);

你会收到如下提示：

Primary directory Movies not allowed for content://media/external/images/media; allowed directories are [DCIM, Pictures]

后言

以上便是本人对Scoped Storage的一些适配心得，希望能够对大家有所帮助。如有错误，欢迎指正。另外，在Android Q的正式版发布时以上的行为可能还会发生变化。 关于Scoped Storage更全面的信息，建议大家阅读参考链接。