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

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

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

苹果这些年来对 iOS 的隐私改进就是在告诉你：不应且不可获取持久的设备唯一标识符。
绝大多数情况下， IDFA 足够使用，何况还有 app ID 与 Vendor ID 。

@SoloCompany

一个是前面所说的 CC 线上拉电阻的原因跑不到，另一个原因是我希望能换成 type-C 的地方尽量都换成 type-C

12.9 寸 iPad 是因为它支持 PD 协议，尽管 iPad 一侧的接口不是 type-C 。
Lightning 的 8 个引脚里，两个差分信号对只用掉了 4 个(这意味着 Lightning 设计上其实可以兼容 USB3.1 Gen1 模式)，电源和地再用掉两个，还有两个引脚足够 CC 使用了。所以 iPad 可以兼容 PD 协议。

iPad 的 PD 的最高功率模式和 Macbook 一样是 14.5V*2A 。
使用 2A 是因为 Lightning 引脚定义使得它无法接受更高的电流。
而 Macbook pro 则因为使用了 type-C 接口，就能使用高达 4.35A(87W)的电流。

@SoloCompany

2.4A 应该是苹果的一个私有(通过 D+/D-的电压协商)做法，不适用于 Type-A 转 type-C 的情况

Type-A 转 type-C 的情况下会因为 CC 线上拉电阻的原因，被充电设备只能接受最大 1.5A 的电流，因为这种转接线要考虑到大多数 Type-A 母口无法提供 3A 的输出能力，不允许把 CC 线的上拉电阻设定到 3A 档所使用的区间。

退一步说 2.4A 也比 3A 小。

@SoloCompany

A 口在不使用私有供电协议的前提下最高只能提供 7.5W(CDP/DCP 的 5V 1.5A)的充电功率，实践中有的设备可以使用 2.4A 的电流。
而 C 口仅是默认的标准就有 7.5W(5V 1.5A)与 15W(5V 3A)，一般都会支持到后者。

以下设备至少都能支持 C 口的 5V 3A 模式或更高功率的 PD
Nexus 5x/6p
Pixel, Pixel XL(PD), Pixel C
Moto Z
Nintento Switch(PD)
Google Wifi
Macbook 12/pro 2016 为代表的笔电

说到底是我在找迁移到仅使用 type-C 接口+"type-C 头转旧式 USB 母口(如 hub)"转接线的方案

@SoloCompany
可以猜得出来，就我而言充电宝到目前只有三个选择：

1 ： anker 一个 type-C + type-A （非 QC3.0 ）的 20000mah

2 ，紫米的 45 瓦 PD

3 ，索尼最近推出的双 type-C 口（仅提供 type-C 标准供电）

另外还知道两个支持 PD 的型号，但太大了（接近 100wh ）

@SoloCompany

我有一把 type-C 接口的设备（ pixel 之类的谷歌亲儿子等，或者是 ipad pro 那样不用 type-C 但也支持 PD 的，加上它们都没有用到 QC 那样的私有快冲协议），两个 type-C 口确实不够用。

相比来说，大功率 PD 倒还是不必要的。

sdcardfs 是三星开发的
AOSP 目前也加入了它的源代码，准备替换 FUSE

https://www.xda-developers.com/diving-into-sdcardfs-how-googles-fuse-replacement-will-reduce-io-overhead/

整个吊销过程是步进的。

发公告当天仅是不信任 notbefore 那天之后的证书，在之后的版本中逐渐屏蔽其它 wosign 证书的信任。

@WINGO
拿 15w 的去冲比较可能观察到充电比不过耗电。

@SoloCompany
可惜找不到超过两个 type-C 口的充电器。
Oricon 有一个似乎停产的版本，但是只有 5V3A ，没有 PD ，插头插到插座时还会出火花

@unijiang
当然行

@qceytzn 要绕过它的反欺诈系统，没什么好办法。

@dot
还好支付宝微信微博 SSO 一个都不用

@happyzed

“好多 app store 就没有严格审核。”
所以你压根不考虑 Play Store 上几乎没有审核？
app store 一个主要绕过措施，是上线的时候使用一个伪装的界面，通过后再改头换面。而在 play store

“我所强调的是总体来说安卓的权限机制还是比 ios 健全。”
建议看一遍这些(虽然我觉得你在撒谎)：

iOS 的安全白皮书
https://www.apple.com/business/docs/iOS_Security_Guide.pdf
AOSP 的 Security 页面
https://source.android.com/security/

@happyzed

”难道 google 连 app 引导用户授权这种业务需求都要管吗？我不信 ios 没有这种情况。“

要管的，不管就会出现滥用。而在管着的 iOS 上可以认为不会出现这些问题：
1 ，“不给权限就不允许”的情况。
2 ，暴露了设备不需要的设备识别码的情况(不考虑使用了苹果所禁止的私有 api 的情况)。

具体：

1 ，
这里权限指的是比较广义的非必要权限：

比方说，定位权限对于一个地图应用是非必要的，因为用户可能仅为了查看地图。
在这种情况下，以下的做法是好的：

应用启动时索取定位权限--->用户不同意--->应用以不提供定位能力，但可以查看地图的方式运行，此时应用具备提供地图的能力

如果用户想用定位了，点击定位按钮，应用提示用户授权定位权限--->如果这个时候用户不同意，应用则拒绝提供定位，因为此时应用自身就没有定位的能力。

2 ，
在 iOS 上，应用找不到任何一个(1)在刷机之后还能保留的，或(2)不同 Vendor 之间共享的设备识别码。
不同应用之间可以通过 Vendor Id 共享设备识别码。
微信公众号的 openId 也有类似的设计。

在 Android 上，应用可以获得以下的识别码：
1 ， SSAID(即 Android Id ，刷机后重置，同一设备的不同账户的 SSAID 不同)
2 ， Build.SERIAL(不随刷机改变)
3 ， IMEI/MEID(不随刷机改变)
4 ， ICCID(随 sim 卡改变)

其中 1 是可以跨应用共享的，即所有应用读到的 SSAID 是相同的
其中 2 读取时不要任何权限，且是 Android CDD 规定的
其中获得 3/4 需要电话权限---->这就是国产应用几乎都要电话权限，稍微坏一点的，不给电话权限就退出的原因。

3/4 的问题可以通过 AppOps 给应用返回 null 进行缓解，但是目前不能解决 1/2 的问题。

而正确的做法是， 1~4 它们一个都不应该使用。 SSAID 应该降级成一个对每个应用独立，在卸载之前不改变的值(这样的角色目前由 Instance ID 承担)。

当然对于涉及钱的应用，使用 IMEI/ICCID 还是有一定合理性的。


而谷歌官方对这些识别码的使用并没有加上任何的强制限制
https://developer.android.com/training/articles/user-data-ids.html#version_specific_details_identifiers_in_m

反倒是在 Instance App 上，做出了不允许获取全部 1~4 的强制限制。
除此以外 Instance App 还不允许访问 /sdcard 。

具体的法律是这个：
http://www.npc.gov.cn/npc/xinwen/2015-12/28/content_1957457.htm

@happyzed

Android 的权限机制有这些问题：

1 ，可以被滥用(应用程序知道没有非必要权限时，便自行退出要挟用户授权)。而无论是 Android 团队还是 Google Play 对这件事都不作为。在 iOS 上，因为上架审查，不会出现这个问题。

这个问题可以部分通过 AppOps 来缓解。

2 ， iOS 可以限制应用在后台运行(后台刷新)。 Android 采用的办法是 6.0 加入的一系列电量管理措施。

这个问题可以部分通过 AppOps 来缓解。


@MushishiXian
据说 UC 连 force stop 都能抵抗

@jiangzhuo 进程可以缓存在后台但不可以运行

@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 项目。

@woyaojizhu8

“耗电主要还是由于应用在后台做一些对用户无益的事”
所以问题出在应用方，从 Android 6 开始出现的 Doze/App Standby 就是用来解决这件事的
它们的作用大致上是关闭屏幕后应用在某种程度上不能运行后台任务 /联网。

以上措施可以绕过，最简单的办法是把应用想时刻运行 service 的进程变更至前台，并利用漏洞(修复于 7.1)隐藏本应出现的持续通知。

"最好的方法当然还是规范化推送，建立一个本地的统一的推送框架"
已经有 GCM 了。 play 的政策也为必要时绕过 doze 等通过间断休眠达到的自动电量管理提供了许可。因此不需要第三方推送服务。苹果乃至小米的做法也证明了系统唯一推送服务是对所有人都有好处的。

“应用在后台只有最基本的推送消息功能”
这个特性依赖于系统的实现，国产 rom 做的比原生系统好，但是国产的做法是不通用的