关于Android Q分区存储的一些适配心得

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手机，打开文件管理器：

现在大家明白了吧？在Q以前，任何一个APP, 一旦拿到了外部权限（ WRITE_EXTERNAL_STORAGE ）后，就可以在你的内部存储的根目录下肆意建立文件夹了，这导致几乎每个Android用户的内部存储活像一个垃圾桶，想必大多数人都体验过在这一堆文件夹中定位自己的某一个文档的痛苦吧。

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

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

requestLegacyExternalStorage = true
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]
复制代码