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 做的比原生系统好，但是国产的做法是不通用的

@201341 既然是好好用个浏览器，那么几乎只有这些选择：

mozilla firefox
google chrome
microsoft edge
chromium stable 的第三方编译版本

买蓝绿机实在是楼主自己挖坑了。

总的说来 Nexus6 还是流畅的的。

可以的，副作用是充电速度可能慢(最大充电速度不超过 45W 的程度)，如果开着这台电脑烤机可能会发现电量往下掉(充电速度不如耗电速度)。

实际上这批电脑用 Nexus5x 及之后的亲儿子， Google wifi ，任天堂 Switch 等使用了 type-C 标准的(无论有没有提供 PD 输出)供电的充电器也是可以充电的，就是更慢，因为这批充电器的最大功率只有 15~18W 的程度。

@FifiLyu
是的， wifi 热点造成的 SAR(就算是开到 30dbm)，要远远小于身边的电脑 /拿在手上的手机

@sgissb1
1 ，禁止分享(每台机器都绑定 MAC)；需要的话部署 radius 服务器配置 802.1x ，不过这样成本就高了，还有漫游问题(WAP-EAP 在没有 FT 的时候漫游速度很差， PSK 模式还过得去，然而开了 FT 又会有潜在的兼容问题)。
2 ，内网地址不够则用 VLAN 等方法配多个子网
3 ，内网隔离需要的时候才用
4 ，说到底还是要 5G ， MU-MIMO
5 ，随身 wifi 这种东西因为靠方法 1 解决不了，要么考虑通过行政禁止，要么考虑域

GFLOPS 性能只有 adreno 430/530 一半的 Intel CPU 自带显卡大概能跑到 13M/s 左右

adreno 430 6.9M/s
adreno 530 8.7M/s

@zjcqoo
chrome 56 实验室里开启 webgl 2.0

只有换 ac ，或者集中清理发射器。