@fairyStage

nlpcollectorwakelock 通常是因为连接不到 Google 的位置服务导致的，但是 Google 自己也挖过坑

微信的通知声音走的不是通知声音，而是走音频播放的，为了迫使它符合系统的设定，需要迫使它通过 GCM 接收通知。

只需要 Android TV 即可，如海外版本的小米机顶盒。

synology(群晖)

自配可以考虑
Windows Server 2012r2/2016+储存池
freeNAS
unraid

硬件方面用 HP MicroServer Gen8 的有很多

@popok 然而快捷支付没有强制性的两步验证，是不可靠的

类似的，亚马逊等特定平台可以在仅知道卡号但不知道 CVC 的情况下扣钱。

需要的话可以联系银行禁用卡的快捷支付能力。
这个特性最早只有招商银行提供，现在有更多的银行（建设银行，工商银行等）也支持禁用快捷支付了

@tomczhen
在组策略里可以设置成用户确认后才开始安装，是一个缓解办法。

Google play music

因为此类分身的实现是通过无数的动态加载实现的，并非 Android for work/knox 那样的（实际上增加了一个受控账户）原生做法

@stewforani
现在还有新的 argon2 算法

“为什么这种情况下只能拦截 java 代码，无法拦截原生库？”
我显然不是这个意思，我说得是 AppOps 无论通过 java 代码调用 API ，还是通过原生代码调用 API ，它都能拦截。因为 AppOps 自身就是某个 API 的一部分。

“某个 API 事实上涉及到了某个 OP ，但没有插桩”是一种怎样的情况？什么是“事实上涉及到”？
举例：
1 ，很多信息可以从 proc 文件系统读到，但是 AppOps 不负责 proc 。比如在 Android 7.0 以前，可以从 proc 读取到设备无线网卡 /蓝牙的 MAC(7.0 开始通过新增的 SELinux 规则予以阻止了)，而 MAC 受到的保护应当至少是和 IMEI(由电话权限保护)同级的。 AppOps 从来都不能保护 MAC 。类似地还有 android.os.Build.SERIAL 全局常量， CDD 直接规定这个值必须是可见的。

2 ， Android 提供了 API ，让应用可以读取到当前已经连接到的 Wifi 热点的 SSID 与 BSSID 。显然这个 API 可以用来获取粗略定位信息，但它不受到 AppOps 保护。
AppOps 确实保护了读取周围未连接的 wifi 热点 /蓝牙信标的信息。

以上两者都是“事实上涉及到且没有插桩”的情况，其中 1 是不属于 AppOps 这三个机制保护，其中 2 是应该受到它们的保护但 Android 有意地没有做

@woyaojizhu8

是的， AppOps 的设定与 Runtime Permission 的设定是分离的，即应用进行某个操作，需要两者都允许。
而这就是一些流氓应用的滥用行为可以通过 AppOps 阻止的原因：
它只检查了 Runtime Permission ，但没有考虑 AppOps ，而 AppOps 层面恰好可以设置让 API 返回空值的(将某个 OP 设置为 ignore ，这个做法是针对 target API level 低于 Android 6.0 的旧版应用设计的)。

Runtime Permission 的具体实现是 AppOps 。
有一些不属于 Runtime Permission 的，但又是系统在默认情况下就允许用户修改的权限设置，如“修改系统设置”，“在其它应用前面显示”等实际上就是直接在修改 AppOps 设定。

AppOps 的权限和 Android.permission 权限的区别应该是这样的：

如果应用没有声明 Android.permission 里的对象，那么它在试图使用这个对象制约的 API 时候会抛出 SecurityException 异常。

对于 target API 是 Android 6.0 及以上的应用，如果出现了在 Android.permission 声明但没有获得 Runtime Permission 时，直接调用对应的 API 也会抛出 SecurityException 。系统为应用提供了 API ，应用可以在任何时候检查自身是否获得了 Runtime Permission 的授权。不给权限就关闭的流氓做法就是靠这个机制实现的。

对于 target API 低于 Android 6.0 的应用，如果出现在 Android.permission 声明但没有获得 Runtime Permission 时，直接调用对应的 API 则会通过“ silent fail ”的形式达到阻止的目的：不会抛出 SecurityException ，但 API 返回的数据是空的(null ，或者是内容为空的对象)。

silent fail 对于用户来说是一件好事(特别是当我们没有一个迫使开发商不能作出“不给权限就关闭”行为的应用商店时)，这个时候应用难以知道自己是否获得了权限，如此可以增加其滥用权限机制的困难程度。

17 楼，用的是 Google 内地的服务器

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 ）