android 发展到现在,文件系统方面的隐私保护已经相对之前好很多了,应用列表的可见已经成为了最薄弱的隐私洼地。虽然可以通过 zygisk + hide-my-applist 来隐藏列表,但毕竟涉及 hook/反 hook ,猫捉老鼠的游戏无穷无尽。如果在 rom 里面实现就没有 zygisk 的问题,也解决了目前安卓最大痛点。
我之前修改过一个冷门 rom 的 framework/base/services/core/java/com/android/server/pm/AppsFilterBase.java , 通过读取 DeviceConfig 里面自定义两个 uid 列表字段,很粗暴地实现了类似 hide-my-applist 的的功能。然后自己编译 rom 。代码很糙没脸提交上游,而且上游是个很小众的 rom 影响力有限。后来上游停更,android 大版本升级了,我就懒得换 rom 再编译了,毕竟编译太花时间精力。
这应该不是小众需求吧,为啥就没有 rom 做这个呢,反而是 fake signature 之类的不痛不痒的功能大家争相集成?
1
UTC0700 6 天前
期待声音被听见
|
2
Donaldo 6 天前
因为很多工具软件有这个需求,而且又有模块可以解决。。
|
3
yyzh 6 天前 via Android
|
5
yyzh 6 天前 via Android
@s82kd92l 好吧...查了一下官方标准的话要用新版 api 写的才会限制...
https://developer.android.com/training/package-visibility |
6
ysc3839 5 天前 via Android
我个人猜测是因为 AOSP 本身就有类似功能。
当 app target api 大于等于 Android 11 的时候,就会限制读取应用列表。 而当 target api 为 Android 10 或更低时,在 Java 端限制读取应用列表,解决不了直接读 /data/data/<包名> 进行探测的问题。如果对应包名的应用存在,会返回 Permission denied 而不是 No such file or directory 。虽然说上述方法只能探测不能直接拿到完整列表,但问题还是存在。 当 app target api 大于等于 Android 11 的时候,上述探测问题也是修复了的,也就是说 Google 是故意给老应用留了漏洞,那问题就变成取舍问题了,Google 为什么要故意这么做?是不是有什么真实数据支撑?我估计即使某人想让第三方系统做出修改,也拿不出说服力高于 Google 的依据,结果就不了了之了。 |