安卓 7.1 的系统，权限管理的最佳方案？？

[qceytzn]

之前一直是 xposed 框架配合 xprivacy 、 boot manager 和阻止运行，几乎可以收拾所有的流氓，再配合应用变量之类的就能玩出花样，现在升级到 7.1 了， xposed 没的玩了，权限管理就是个大问题了，各位是怎么解决的呢？

[crs0910]

冰箱 绿色守护 黑域 系统自带权限管理

[qceytzn]

@crs0910 冻结的那几个好解决，主要是权限管理， xprivacy 还能给流氓返回一个贾信息，系统自带的真的是弱爆了...

[watermeter]

app ops

[Sharuru]

黑域 with AppOps
前者自动休眠、后者管理权限。

[28661]

黑域+AppOps

[AsherG]

同楼上，黑域+app ops

[qceytzn]

@watermeter play 里有好几个 app ops ，你们用的是哪个？

[qceytzn]

@AsherG
@28661
@Sharuru play 里有好几个 app ops ，你们用的是哪个？

[Jaspr]

Qixingchen 的 App Ops

[AsherG]

@qceytzn #8 https://play.google.com/store/apps/details?id=rikka.appops

[woyaojizhu8]

@Jaspr
@AsherG
@28661
@Sharuru
@honeycomb
我看到 app ops 的权限管理和应用本身的权限列表还是不完全一致，这其中有什么规律呢？比如应用权限列表里有“检索正在运行的应用”这一项，而 appops 里没有，是不是就没有办法禁止该应用检索正在运行的应用了呢？

[simple4wan]

发现国产魅族机器 自带的管理不错的 有效杀掉全家桶

[honeycomb]

@qceytzn 自然是 7.x 能用的 appops
一共有两个：

Qixingchen 的是 rikka.appops ，是一个带内购的软件
还有一个是全部开源的 com.zzzmode.appopsx ，代码在 https://github.com/8enet/AppOpsX

都是很好的 appops wrapper ，而且两者在更新的过程中明显有互相借鉴


@woyaojizhu8
关于权限有三个不等同的概念：

一个是 Android.permission 命名空间的对象，它和 API 的关系更多是，如果需要运行某一命名空间的指定 API ，则必须要在应用的元文件里申明对应的 Android.permission.[]项目：

二个是 4.3 开始出现的 AppOps 里的各种 OP ，具体涉及的 API 里会加入 AppOps 的代码，在运行期间检查是否获得了这个 OP 的使用许可。如果是通过 Runtime Permission 设定的新版应用，则抛出违例，如果是旧版应用，或直接通过 AppOps 设定，则“ Silently fail ”------这是对付流氓软件的办法

三个是 6.0 开始出现的 Runtime Permission 里的权限

Runtime Permission 直接依赖于 AppOps ，所以单个 Runtime Permission 对应一个或多个 OP 项目。

[qceytzn]

@honeycomb AppOpsX 这个软件要不是你推荐我还真不知道，在 play 上搜“ App Ops ”是找不到这个软件的，因为其名字里没有空格。这会试用下来，感觉不错，个人更喜欢这样的软件，比 App Ops 用的还顺手一点，推荐！

[woyaojizhu8]

@honeycomb
再请教一下：
1.如果是旧版应用，则“ Silently fail ”？那旧版应用都获得不了权限了？这与实际使用体验不符吧。
2.xprivacy 对.so 很无力，在很多情况下无法限制其行为，那 AppOps 有这个问题吗？
3.AppOps 能限制应用获取信息到何种程度呢？其程度与 xprivacy 相差大吗？ 比如本机 wifi 模块 mac 、、 android id 等能唯一确定设备的信息，连接的 wifi ssid 等能用于定位的信息， AppOps 能全部封堵住应用对这些信息的获取吗？ 还有已经安装的应用列表、正在运行的程序等信息， AppOps 能限制吗？
xprivacy 稳定版已经两年多没更新了，期间好像一直没出现如 xprivacy 那样强大的权限管理工具，感觉 android 上的权限管理不容乐观啊。

[honeycomb]

@woyaojizhu8
1 ，这里 Silently fail 表示应用会拿到一个 null 或者空值之类的返回，这么做是尽可能为了不让应用崩溃
2 ， appops 是直接插到它所管辖的具体 API 的源代码里的，应该是有用的。但是如果某个 API 事实上涉及到了某个 OP ，但没有插桩的话，那就管不着。
3 ，自己试试看不就知道了， AppOps 只要有 adb 就能用。还可以看 AppOpsManager.java 的源代码。

本机 wifi 模块 mac ： 在稍微新一些的 Android 就默认已经拿不到了， 7.0 的话连 /proc 的很多东西都不让看
android id 不行
已经安装的应用列表不行
正在运行的程序等信息(新版的)默认就阻止了

[honeycomb]

ssid 是这样，正连接着的热点的 ssid/bssid 不能阻止获取(iOS 也是一样)，但未连接的 ssid/bssid 受到位置权限保护。

[qceytzn]

@honeycomb 上面帖子里说的“ android id 不行 ”是指“ AppOps 不能阻止程序拿到系统的 android id ”？下面的几句话的意思是“ AppOps 不能阻止程序拿到已经安装的应用列表”、“ AppOps 不能阻止程序拿到正在连接着的热点的 ssid/bssid ”这样的意思吗？

除了安卓 id 之外，还有个更重要的 IMEI 以及手机的品牌和型号， 7.1 的系统本身以及 AppOps 能阻止程序拿到吗？

[woyaojizhu8]

@honeycomb
我看了安卓关于 runtime permission 的文档，还有其他一些介绍文章，再进行了一些实践，这是我的理解：
runtime permission 需要请求的权限（也就是危险权限）包含于 Android.permission 的权限，而且是以权限组的形式请求的；
AppOps 的权限和 Android.permission 权限互相之间没有包含关系；
runtime permission 需要请求的权限是 AppOps 和 Android.permission 交集的子集；
这三种权限的设定值是相互独立的，在权限检查时是“与”的关系。也就是说，一个应用想获取 imei ，必须在 mainfest 里有读取手机身份的权限，而且获得了 runtime permission 的电话权限，并且 app ops 里的“读取手机状态和身份”权限也允许了。
你说“ Runtime Permission 直接依赖于 AppOps ，所以单个 Runtime Permission 对应一个或多个 OP 项目。”可能在代码实现上是这样，但从我的实践来看这两种权限系统的设定值还是相互独立的。

[woyaojizhu8]

@honeycomb “某个 API 事实上涉及到了某个 OP ，但没有插桩”是一种怎样的情况？什么是“事实上涉及到”？为什么这种情况下只能拦截 java 代码，无法拦截原生库？