网络热传App鉴定 |「得物」疑私删用户视频?从技术角度还原事件始末

声明:本文更注重于原理知识的普及,因此文中不会有大量实际代码的展示,如果想从代码层面上了解「应用存储分区」的内容,欢迎阅读我两年前写过的技术文章《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删除操作的判定规则:

  1. 系统认为,对于公有目录下的媒体文件,App只应保有读取的权限,修改、删除该媒体文件都属于越权行为,是有可能侵害到用户重要的个人资产的。

  2. 确实有需要删除某个公有目录下的媒体文件的,App必须尽到告知用户的义务,并把删除的选择权交给用户,在得到用户授权之后才可以删除。

  3. 如果App只是修改、删除其专有目录下的媒体文件,系统会认为这是App内部对其缓存文件正常的维护行为,故而不会干涉这类操作。

到这里,我们可以总结一下,这场乌龙事件之所以会发生,根本问题在于,旧系统的遗留问题与新系统的保护措施起了冲突

得物App使用了不合理的文件缓存管理方案——将临时缓存文件保存到了公有目录下。因此命中到了系统拦截App删除操作的判定规则,进而收到了相关的系统推送提醒。

要真正解决这个问题,需要得物App积极推进对Android 10应用分区存储的适配,将对文件缓存管理迁移到App专有目录下进行,就不会引致此类事件的发生。

——这就是得物App疑偷删用户视频整件事情的始末。

少侠,请留步!若本文对你有所帮助或启发,还请:

  1. 点赞👍🏻,让更多的人能看到!
  2. 收藏⭐️,好文值得反复品味!
  3. 关注➕,不错过每一次更文!

===> 技术号:「星际码仔」💪

你的支持是我继续创作的动力,感谢!🙏

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,772评论 6 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,458评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,610评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,640评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,657评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,590评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,962评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,631评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,870评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,611评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,704评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,386评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,969评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,944评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,179评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,742评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,440评论 2 342

推荐阅读更多精彩内容

  • Android Q 越来越近了,最近 Google 又发布了 Android Q Beta 的第五个版本,眼瞅着这...
    hljstardust阅读 4,972评论 0 3
  • 一、简历准备 1、个人技能 (1)自定义控件、UI设计、常用动画特效 自定义控件 ①为什么要自定义控件? Andr...
    lucas777阅读 5,186评论 2 54
  • 本文档基于谷歌Android 11 Developer Preview 4(DP4)版本的变更输出,后续Beta版...
    爱码士平头哥阅读 9,988评论 0 6
  • 1、什么是ANR 如何避免它? 这个对话框称作应 用程序无响应(ANR:Application NotRespon...
    _Rice_阅读 2,049评论 0 3
  • ONE YEAR 我的 android 开发一年总结。 2017年6月21号,是我在华中科技大学的毕业典礼的日子,...
    chendroid阅读 987评论 4 10