简单地拒绝，告诉他，先把以前欠的还了

@bramblex

GJ

@20015jjw

具体就是
@lsmgeb89
说的

我没深究过，但从这个帖子里的说法， Android 组的人似乎在说：

snapdragon 810/808 自带了硬件 AES 模块，但是性能很糟糕，比调用 Armv8 的 AES 指令集还要慢
再加上 5x/6p 用的只是 eMMC5.0 接口，速度比 UFS 低得多，更别提丧心病狂的 A9/A9x 的 PCI-Express

另外考虑 iPhone 6 的 200MB/s+， iPhone 6s 的 400MB/s+的顺序读取速度，可以看到 A?芯片里的硬件 AES 模块有多快了，毕竟从初代 iPhone 开始，苹果就在使用全盘加密了

cardboard ？

如果查不出器官本身有问题，就说明可能是劳累 /紧张 /健康状况不够好所致，想办法调节一下会缓解的。

药还是要吃，就当是安慰剂，安慰剂也有效果的。

@20015jjw 本身 n5 的闪存就不快，也没有专用 dsp 处理 aes 加密解密， armv7 又不像 armv8 有专用的 aes 指令集。
长期不用导致速度慢可能和数据储存长期不动地存放在闪存下，导致浮动栅里电子流失（但远不至于丢失数据的程度），需要花费更多时间读出来。而经过使用后，数据会被刷新 /被损耗平均算法移动过位置，便会活起来

@morethansean

6p 据说也有类似的内存泄漏的情况(隔两三天要重启云云)
只能说是希望下周的 6.0.1 能改进
如果做不到的话就要等不一定存在的 6.0.2 ，甚至明年春夏天的 6.1

nexus5 从 5.0 开始就有内存泄漏，泄到 5.1.1 也不知道有没有全好(nexus 6 在 5.0~5.1.1 的过程中内存泄漏不明显)

@zander
因为 iOS 上没给设备标识信息，也没给定位信息
所以 Android 上也不能试图要求这两个对应权限

@troywinter 谢谢

@wohenyingyu01 troywinter 说的应该才是正确答案

@wohenyingyu01
Android SDK 自带的模拟器，如果使用 x86 镜像，且要使用虚拟化技术加速运行的话，确实无法使用 AMD 的处理器，因为它需要额外装一个叫 Intel HAXM 软件，这个软件只支持英特尔的处理器。

@TVBG
除非它特定地不向这个用户提供服务(比如支付宝说它关门了)，否则最终总是搞不过用户侧的，手机在用户这边呢。

@TVBG

“不能全由着用户来”
------Xposed 伺候之

“不能全由着用户来”
------各种反向工程伺候之(到这种程度是用来打病毒了)

还有一种灰色的情况
“不能全由着用户来”
------abcde 破解版，去 XX ，去 YY ，去 ZZ ，整合 /sdcard 目录下文件到应用自身目录....

@gmsh
这个坑是 Android6 引入的：

1 ，******.PHONE 是一个权限组，下属了一些 dangerous 权限

对于 dangerous 权限来说，授权相当于是整个权限组打包授权的
比方说，
在 manifest 同时声明 READ_EXTERNAL_STORAGE 与 WRITE_EXTERNAL_STORAGE
允许了 READ_EXTERNAL_STORAGE 后，
应用也会获得 WRITE_EXTERNAL_STORAGE 权限

2 ， Android 的人认为 PHONE 这个权限组只应该用于和打电话有关的项目，但没有为此实施强制措施。
“支付宝要 PHONE 权限组主要是为了看 IMEI/MEID(而不是为了看)”是我的猜测

在没有
directly call phone numbers
权限前，应用要拨号必须给系统拨号器发 Intent ，跳转到系统拨号器并由其负责拨打电话

有这个权限时则可以直接拨打电话

所以，
“意思是不是将来自动更新后，加上 Read call log ， Reroute outgoing calls ，用户也是不知道的”
------是的，你说的对的



另外还有一个比较有趣的地方：
a ，没有声明拍照权限时，可以发送 Intent 让默认的拍照应用拍照，再让本应用接收
b ，如果声明拍照权限，且用户许可时，应用自身可以调用 camera API 拍照
c ，如果声明拍照权限，且用户拒绝时，应用不能做到 a 或 b


@athanos
估计就算到这个地步，支付宝会仅在自己的主页发布应用，也不会退一步。

@ssynhtn
"本来就是这样的。软件想干什么不能由着你来。
你不喜欢它可以不用，或者举报它看 Google 会不会下架它。"


事实是这样按优先级排列的

1 ，首先满足一些最低限度的(安全 /隐私方面的)标准
2 ，用户决定软件不能干什么
3 ，软件想干什么就能干什么

@mcone

“对于 play 这种店家，估计对 play 最新版淘宝安装后自动下载可执行代码什么的，应该也会睁一只眼闭一只眼吧。普通开发者就别想有这待遇了……”
前一次下架说明还是能下架的，但待遇不同

所以多管齐下治理支付宝还是有意义，既然已经有不同待遇了，再不举报，又有谁能把它 take down?

@yaoppp

solid explorer 和支付宝试图索要 android.permission.PHONE 的目的都是起到唯一硬件识别码的 IMEI/MEID 。
但是永久地唯一识别硬件是不可接受的，意味着 solid explorer 的做法也是不可接受的。
这一点和陌陌的封禁设备是类似的道理。
(参考 iOS 近几年的做法， iOS 设备在重置之后，仅使用公开 API 的情况下应用无法判断是不是同一设备。)

现在的 Android6.0 还有两个漏洞：
1 ，在 /proc 目录里还是可以看到映射的 Wi-Fi/蓝牙 MAC(Google 说会在下个版本关闭)
2 ，还是可以获取设备序列号，(SerialNumber ，位数不定，有的 Android 设备有，有的没有，似乎是一个字符串)

@mcone
玩家没有动力举报

这事还是要随手举报一下的， Google 是否响应管不着，但是不使用救济手段则是用户自己的损失了。

@yaoppp

Android6 的新权限机制允许应用查询自身有没有获得某个 dangerous 权限，这个机制本身允许应用发现权限被拒绝后，拒绝运行，这一点在 Android 的官方文档里也有涉及。

但是在 b.android.com 和 developer preview 的 bug 汇报页面上， Google 的员工有提到过 PHONE 这个权限组只应用于打电话相关。

这个接口是 Google 故意给的
它允许 Android 应用在 API Level 23 或以上时，检查 dangerous 权限是否被拒绝

现时点能用的办法是通过 Xposed(Xprivacy 伪造数据，或者写一个新的插件屏让检测权限的 API 总是返回 true)