为啥不利用修改 apk 的 manifest 来控制软件行为？

现有控制软件行为的方案，绿守 /黑域 /写轮眼 /xposed 无一不是入侵式的，对 root/adb 要求很高效果却不完美，为啥没大神做基于 manifest 编辑+自签名打包来做到免 root 限制流氓呢？

Manifest 就像是 apk 和 android 系统签订的一份合约，其内容完全决定了 android 沙盒如何限制 apk 的行为。Google 目前的做法是让用户无条件接受这份合约（ 6.0 之前）或者只有极小协商空间(就是 6.0 的可选权限)。如果能修改 manifest,用户可以达到这些效果(从简单到难):
1. 修改 targetSdkVersion 很多新系统对流氓的控制，流氓都会通过 target 老旧的 sdk 来应付，如果能自己改 targetSdkVersion，流氓们只能在 8.1 下面乖乖睡觉，在 6.0 下面乖乖把部分敏感权限选择权交给用户
2. 直接删除 /添加权限申明。6.0 下面的权限只有部分是可选的，通过修改 manifest，所有权限用户都能控制
3. 直接修改 /删除四大组件的申明让 broadcastreceiver 再也收不到“开机 /网络变更 /摄像头开启”之类的唤醒，直接禁用 service/content provider，或者使其无法向第三方开放。

如此以来，再也不需要在运行时控制自启动 /切断唤醒路径，因为新合约让流氓无路可走。还有 Oreo 对 bound service/content provider 没有约束的情况，manifest 也可以弥补。只要限制得当，这个沙盒能比 iOS 更加给力。
改完后重新打包，尽量做到每个 apk 单独签名。还有就是最好把 apk 的原始签名加入 manifest 中，这样升级的时候可防止下载到一个已经被人动过手脚的 apk。

如果要做这种修改软件，界面可以像写轮眼那样非常清晰明了。如果能借绿色守护的处方语法就更好了，那样小白就可以利用网上现成的处方来决定哪些权限 /组建可删可改以及怎么改。免 root，流程简单，效果超过现有方案，为啥没人做呢？

honeycomb

2018-01-17 18:03:54 +08:00

改 manifest 有这些问题：

1，破坏了应用的签名，这肯定是不可取的。
有的应用自己还会检查签名，特别是那些特意做了加固的，也就是说，这是一个普遍行为。

2，在 manifest 禁用权限以后，应用使用相关权限控制的 API 时，会抛出 SecurityException，应用基本不可能去 catch 这些东西，意味着这不实用，比 AppOps 返回 null/empty 对象的做法更不实用。

--------------------------------------

关于主题里琐碎的项目：

“如果能自己改 targetSdkVersion，流氓们只能在 8.1 下面乖乖睡觉”
有现成的 workaround，直接把应用在 AppOps 的 RUN_IN_BACKGROUND 改成 ignore 即可。

注:
应用的电池选项里，有时可以直接改这个设置(8.0 和 8.1 的表现不同，8.0 是只需要应用运行过就可以开启这个限制，8.1 需要别的条件，我没看过具体的源代码)
AOSP 上的 8.1 及 pixel 2 代的全部官方 rom 的开发者选项-->background check 可直接改

“直接修改 /删除四大组件的申明让 broadcastreceiver 再也收不到“开机 /网络变更 /摄像头开启”之类的唤醒，直接禁用 service/content provider，或者使其无法向第三方开放。 ”

在 Android 8.0，绝大部分隐式广播已经无法触发系统定义的那些 receiver。
除此以外可以用修改 IFW 配置的方法(如绿色守护的处方特性)，pm disable(MyAndroidTools)来处理它们

“ Oreo 对 bound service/content provider 没有约束”
似乎没什么好办法

Totato5749

2018-01-17 18:04:21 +08:00

太理想了。。。不可能实现的
manifest 如同字面意思，只是清单不是合约，只是告诉了系统 app 的全部功能与要求。

比如将 targetsdk 改为 6.0，那么在 6.0 以上的系统中权限必须是动态申请的，但是 app 原来并不是给 6.0 适配的，根本没有申请权限的代码，这样的 app 是跑不起来的。

楼主可能以为 6.0 以上的申请权限是系统行为？并不是的，这个是需要开发者自己添加代码弹出申请权限对话框并在回调中检查是否获取到对应权限的。所以简单地将 targetsdk 小于 6.0 的 app 改为 targetsdk 为 6.0 会导致应用无法使用

s82kd92l

2018-01-17 18:16:31 +08:00

@honeycomb 那也得 targetSdkVersion>O，限制才有效吧。我自己在用 oreo+appops，可是对于广大非 root 的手机，和那些无法升级到 oreo 的这个是值得一试的方案。

@Totato5749 6.0 的权限除了动态申请，用户也可以在软件管理界面里手动赋予的。

@Leafove @ju5t4fun 这个是个现成的 xposed 签名修改模块，目前用于欺骗 google sdk，应该也能用于欺骗那些做加固自签名校验的:
http://repo.xposed.info/module/com.thermatk.android.xf.fakegapps

s82kd92l

2018-01-17 18:26:55 +08:00

@XinLake 这个不是我们改，而是授之以渔让用户自己改，区别很大的。

指望提高素质是没用的，道德永远没有制度管用。Android 生态最大的问题在于，既没有 apple 的人工审核机制，也不让用户有更多选择权，而是在权限问题上做 all-or-nothing 的一锤子买卖，从而赋予开发者最大的话语权。我这个想法无非是给用户更多权利罢了。

s82kd92l

2018-01-17 18:35:37 +08:00

还想说一点，很多人指责国内 android 环境太差，说国外月亮更圆。然而事实上国外的 app 并没有更安分到哪里去，去搜一搜 android information flow leak 就能知道即使在 google play 上面上架的应用，照样普遍利用 android 不完善机制达到各种泄漏。
国内不好的地方在于没有推送机制所以要各种保活，以至于使用户卡顿。然而就算有了推送机制，有了统一的 app 发布平台，只要开发者有一锤子买卖的权力，那么 android 沙盒照样是漏洞百出，用户隐私依然形同虚设。

honeycomb

2018-01-17 18:52:57 +08:00

@s82kd92l

RUN_IN_BACKGROUND 设置成 ignore 后的限制不受 targetSDK 影响，具体看源代码，最初的 commit 是 dianne hackborn 签署的，这人也是 Android 团队的老人了。

这里的关系是，targetSDK 从 26 开始，应用默认受到这个限制，并且在用户界面没有关闭的选项（ appops 的值为未设置，即 appops get 是获取不到值得）。

有人说 appops 层可以设置为 allow 以关闭，我没有验证过。