关于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的适用策略以下：

• 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更全面的信息，建议你们阅读参考连接。

参考连接

0. segmentfault.com/a/119000001…
1. developer.android.com/preview/pri…