声明：本文更注重于原理知识的普及，因此文中不会有大量实际代码的展示，如果想从代码层面上了解「应用存储分区」的内容，欢迎阅读我两年前写过的技术文章《Android 10 应用分区存储适配实践》
近日，有网友爆料，称其发现得物App有疑似偷偷调用手机权限删除用户视频的行为。
事件的起因，是该网友在得物App上购买到的商品有问题，于是按流程向平台方反馈，并上传了相关的视频证据。
但没过多久，其手机上就收到了一条系统推送提醒，内容是检测到“得物”删除了视频，已成功拦截，据该网友推测，被删除的正是作为重要维权证据的那条视频。
此事一经曝光，立即在网上掀起了轩然大波。从大量评论跟进的内容上看，网友们最关注的问题集中在：
得物App到底有没有未经用户同意，就删除了用户手机相册中的视频？
随着事情的逐渐发酵，得物App也紧急连发了两条声明，最新的一条声明回应称：删除的是编辑、处理、上传过程中产生的临时缓存文件，是对该临时缓存文件的处理触发了系统拦截通知。
声明发出后，有相当一部分网友采纳了这个说法，毕竟类似的误报之前也已经在其他App上发生过不少了。到这里，事情似乎告一段落了。
但是，这真的可以简单归结为系统拦截通知的误报吗？多年从事Android开发的直觉告诉我，这件事情的背后，肯定还有更加深层的原因。
也是基于这种直觉的驱使，经过了大半个晚上的信息收集、情景模拟以及测试验证，我大致上已经能够梳理出这整件事情的来龙去脉了。
先抛出结论，这其实是一场由「Android系统的历史遗留问题」，「得物App对于适配工作的不作为」以及「系统拦截App删除操作的判定规则」三者共同作用下所引发的「乌龙事件」。
故事，还得先从Android系统的历史遗留问题开始讲起。
Android系统的历史遗留问题
Android 10之前：乱象丛生
在Android 10之前，Android系统对于App的文件存储，既没有强硬的存储规范，也没有可参考的存储建议。
在此混沌的背景下，只要能申请到必要的文件读写权限，每一个App就都可以在手机存储空间的任意位置建立属于自己的目录，访问系统目录或其他App的目录也是完全没有任何限制。
这样做直接导致的结果就是，用户根本无法区分和管理不同App的文件，一打开文件管理器，能看到的除了混乱无序，还是混乱无序。
Android 10：应用分区存储开始实施
也许是Android系统也意识到了这个问题的严重性，所以在Android 10之后大刀阔斧地引入了应用分区存储的概念，也即为每个App划分了一个专有目录，默认情况下，App只能访问这个专有目录下的文件。
如果App尝试访问此目录之外的文件，就会发生错误，即使已经申请了文件读取(READ_EXTERNAL_STORAGE)权限。
而如果App需要访问公有目录（比如系统相册）下的照片、视频、音频等媒体文件，则需要使用另外的MediaStore API来访问。但是对于这个API的使用，Android系统也同样收紧了权限。
比如现在你想要删除公有目录下的某个媒体文件，系统就会向你抛出一个RecoverableSecurityException异常，中断你的删除行为，以告知你正在进行危险的操作，为此你需要再次请求弹出一个系统级的弹窗，告知用户你正在进行删除操作（弹窗上的文字描述不可自定义），在征求用户的同意之后方能删除媒体文件。
立意虽然是好的，但是这个巨大的行为变更，相当于要求App把之前经过数个版本甚至数十个版本才建立的文件目录结构完全推翻，不仅要把之前可能分散各处的文件重新聚拢到App专有目录下，还要成片成片地修改之前的代码实现。如果短期内强硬要求执行，那必然将是怨声载道，哀鸿遍野。
所以，针对那些短期内无法完成迁移工作的App，Android系统又给留了一个后门。开发者们可以通过添加requestLegacyExternalStorage清单属性，允许App适配Android 10的其他变更，但暂时停用分区存储。
表现出来的样子就是App可以沿用之前文件目录结构，暂时不需要做任何改变。
Android 11：强制执行分区存储
但当将App更新到以Android 11为目标平台后，Android系统会忽略该属性，即会强制执行分区存储。
意思很明确：机会呢，我是给过你了，都过了一个版本了你还不改，那就等着App崩溃吧你。
所以呢，只要是以Android 11为目标平台的App，基本上都是已经完成了应用分区存储的适配，现在它能自由操作的，只能自身专有目录下的文件。而对于公有目录下的媒体文件，基本上就只有查看的权力，如果需要修改或者删除，则如上面所说，需要用户授权才能操作，而不能再像之前那样无感知修改和删除了。
得物App对于系统适配工作的不作为
那好，现在由你来猜一下，本轮事件中的当事App「得物」可能处于以上描述的哪一个阶段？
3…2…1！
保留好你的答案，下面我们先用排除法来排除明显错误的选项。
得物App在发布的第二条声明里，还附上了其App发布动态时的文件缓存管理方案示意图，如下：
我们主要关注其步骤2——「复制到临时目录」，这里我们可以看到，得物App是将原视频复制了一份到/pictures/duapp/a.mp4路径下，也就是在文件管理器的Pictures目录下创建了一个名为duapp的临时目录。
Pictures目录是干什么用的？这个目录是用于放置用户可用图片的，属于外部存储公有目录下的预定义子目录之一。
既然得物App可以自由复制文件到公有目录，那么就可以排除第3个选项了，也即得物App并没有以Android 11为目标平台。
剩下2个选项我们也不欲盖弥彰了，直接下载本轮事件曝光之前，得物App最后一个版本的安装包文件(*.apk)一探究竟即可。
从解压缩后的安装包的AndroidManifest.xml清单文件中我们可以看到，该版本的得物App所适配的目标SDK版本为29，也即Android 10，并且添加了requestLegacyExternalStorage属性，也即请求暂时停用分区存储。
所以，正确答案是第2个选项，得物App并没有适配Android 10的应用分区存储变更。
话说，连Google Play都要求上传的App必须适配Android 12了，Android 13也都已经出Beta版了，得物App你这样一直苟在Android 10里真的没问题吗？
系统拦截App删除操作的判定规则
最后，我们还有一个问题没有弄明白，也即：
得物App删除了其放置在公有目录下的临时缓存文件，系统在这个时候拦截了此行为，真的是属于误判吗？
为了还原系统拦截行为的一个合理性，我们需要先理清系统拦截App删除操作的判定规则，为此，我们设立了3个对照组，均以Android 10为目标平台：
建立对照组
-
实验组：添加了
requestLegacyExternalStorage属性，即暂时停用分区存储，直接删除公有目录下的媒体文件 -
对照组1：不添加
requestLegacyExternalStorage属性，即必须得到用户的授权之后才能删除公有目录下的媒体文件 -
对照组2：不添加
requestLegacyExternalStorage属性，只删除其应用专有目录下的媒体文件
用于验证的示例项目，来源于Android开发者官网提供的MediaStore示例，该示例原本的设计是用于演示如何使用MediaStore API来正确显示手机相册中的图片的。
演示的手机选用是Huawei P30 pro，该型号能稳定重现系统拦截操作的推送通知。
结果展示
实验组：固定收到了系统拦截App删除操作的推送提醒。
对照组1：获得用户授权之后能正常删除照片，没有收到系统拦截App删除操作的推送提醒。
对照组2：既不需要授权，也没有收到系统拦截App删除操作的推送提醒。
通过这个对照结果，我们很容易能倒推出系统拦截App删除操作的判定规则：
-
系统认为，对于公有目录下的媒体文件，App只应保有读取的权限，修改、删除该媒体文件都属于越权行为，是有可能侵害到用户重要的个人资产的。
-
确实有需要删除某个公有目录下的媒体文件的，App必须尽到告知用户的义务，并把删除的选择权交给用户，在得到用户授权之后才可以删除。
-
如果App只是修改、删除其专有目录下的媒体文件，系统会认为这是App内部对其缓存文件正常的维护行为，故而不会干涉这类操作。
到这里，我们可以总结一下，这场乌龙事件之所以会发生，根本问题在于，旧系统的遗留问题与新系统的保护措施起了冲突。
得物App使用了不合理的文件缓存管理方案——将临时缓存文件保存到了公有目录下。因此命中到了系统拦截App删除操作的判定规则，进而收到了相关的系统推送提醒。
要真正解决这个问题，需要得物App积极推进对Android 10应用分区存储的适配，将对文件缓存管理迁移到App专有目录下进行，就不会引致此类事件的发生。
——这就是得物App疑偷删用户视频整件事情的始末。
