@dotswing 成， 1060/1050 就可以啦

@woyaojizhu8

谢谢，原来 AOSP 有这个改动，看样子它比较可能会出现在 Android O 。

对应的 code review
https://android-review.googlesource.com/#/c/276118/

7.1 的代码好几个月前(Pixel 发售以前)就已经固定了， 7.1.2 都快要正式了。所以这个改动肯定会用于新版本的 API level 。

即:
The Build.SERIAL value is set to 'undefined' for apps targeting high enough SDK
对于编译时指定足够高的 API Level(或许是 Android O 可能会使用的 26)的应用， Build.SERIAL 常量返回 undefined

然后使用受到电话权限保护的 Build.getSerial()接口替代它。

“有没有办法让 Build.SERIAL 对目标 SDK 较低的应用也失效呢”
看上去它是在 SELinux 动了手脚， AppOps 不像是能保护到它。如果 Build.SERIAL 是一个接口的话就会做成返回 null/空字符串的形式，但它是个常量就很难说了

网易邮箱只有在简版时提供全程 HTTPS

@viator42
只要愿意，目前可以上 1080ti

@kulove 这个不过是广告联盟+跨设备追踪而已。

装上内容拦截器（ ublock origin ， privacy badger 等）就可以解决问题了

@zzcchh 音频视频分离与 DASH 有关， YouTube 能自动按照带宽调整清晰度也和 DASH 有关

不提供 H.265 ，但在可行的平台上提供封装成 webm 的 VP9 编码的视频，如果不支持，则回退到 H.264 。

H.265 的专利费用非常可观，在主推 VP9 且 VP9 已经很流行的情况下，不支持 H.265 符合 YouTube 的利益。

@di94sh 前段时间不小心压坏了一块硬盘的 SATA 接口，连着数据线一起报废了

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