两个不痛不痒小建议：
1. getprop 可以用 android.os.SystemProperties#get 替代（避免使用慢到爆炸的 su ），反射或者在单独的 module 中建立 stub 类再 compileOnly 都可以（ android.os.SystemProperties#get 不是不可以使用的 hidden api ）
2. 里面使用的 ShellUtils 看起来是每次都开一个新的 su 进程，又慢又浪费，推荐使用 topjohnwu/libsu （会共用一个进程）

真的强制了用户反而会不开心，因为「让存储分开但是应用的行为不受影响」几乎是一件不可能的事情（

在 Android 10 DP2 的确「强制」了，但是旧应用怎么办呢，只能靠奇奇怪怪的让旧应用们「能用」（跟 Rikka 发明差不多，核心靠挂载，辅以各种特技）。DP2 的方案甚至还包括了「媒体存储返回假路径然后 hook IO 函数们在里面帮你用 content provider 」这样过于夸张的特技。但是，特技满天飞，还是有应用会坏掉。大部分的用户只会因为应用坏了而大叫，不会关心分什么区存储。

所以，从 Android 10 DP3 开始，Google 的方案就从「尝试改变老应用行为」变为「行为跟没存储权限几乎一致，靠 Google Play 对 target API 限制来缓步强制应用们适配」。（ Android 11 最新的 beta 又加入了又给 sdcard 来一层 fuse，在里面悄咪咪变成用媒体存储，为了让没有脑子的人开发人开心真的是操碎了心）

觉得没什么好抱怨的，只在两个版本的系统就尝试了至少两种完全不同的方案并且真的确定已经是够快的了（

核心就是把验证跟干活的部分绑一起写成原生库，怎么做可以随便发挥想象力

顺带一提，签名验证可以做成不走系统 API 直接读 apk 文件的（如何读签名，参考 https://source.android.com/security/apksigning/v2 ），也绑在自己的 native 库里给破解人增加难度

另外，既然是个人作品就别用那些脏脏的奇奇怪怪的加固的东西了（

啊 看错（

让 proguard-rules.pro 变成现场生成的，在 gradle 脚本里大概实现这样的逻辑：
读取 proguard-rules.pro ，加入 printusage 并写到另外的文件，将 proguardFiles 设为这个另外的文件

或许可以（

自己什么都不做的情况下本来就是分开的

问题里有个“等”，发出 sendfile 也是系统调用的声音，只要一行就好了（逃跑

@acess 扯这么多还不是因为用 adb 安装时没有指定 user，所以脑内没有被安装到了所有用户的概念。正常的安装只会安装到一个用户，卸载时也是从一个用户卸载是符合逻辑的。
另外 apk 只存在一份，不同用户不能拥有不同的 apk 。这么做有一定的道理，因为有些东西是能跨用户工作的（

学艺不精才会觉得有问题（

`android:extractNativeLibs="false"` 则 so 不会解压。
AGP 3.6 以上默认 false，会帮你以页对齐且不压缩的形式把 so 塞进 apk，所以运行的时候就可以直接去（

你看你都知道它叫多任务了。在这里，显示的是任务而非应用，比如 Google 文档每个打开文件都是单独的一个任务，在里面加入直接杀掉显然是不合理的（

两个小建议
1. 对齐和元素之间的间隔一定要做对，可以极大减少“不精致感”
2. 参考系统应用是很好的开始

Android 10 可以 requestLegacyExternalStorage
Android 11 有 MANAGE_EXTERNAL_STORAGE 权限，但是要上架 Play 需要审核

1. 一样的巨量修改，已经是和大家差不多形状了

MS 的 AppCenter 目前看来最干净的（

@UserANullPointer 普通应用是没权限取得系统的日志的

@KunMinX 看 FileProvider 里面的 openFile （

@KunMinX 啊 凄惨看错（
不主动去触发扫描也会有扫描的（

@RikkaW
简单的说，已经不是扫描了，而是把文件内容和文件名称喂给媒体存储（

https://www.v2ex.com/t/597899
包含 10 的做法
11 有没有变还没有看

小声一句，A 用 FileProvider 分享给 B，实际进行读写操作的是 A （