@Kevinssolo 那就剩下 system.settings 那个数据库了。

keystore 或许也可能有留存，具体看一下它的 API 文档。在 iOS 经常用类似的 keychain 存留半永久识别码。

@lgpqdwjh qc20 我用着感觉还不错，飞机火车地铁上的神器

因为它是改动到不能用 android 商标的 android 衍生版。
看楼主描述比小米还要过分。

@LittleYangYang 这年头还没在 Windows 上适配 hidpi 的软件真的是过时了，何况 windows 兼容选项还能给软件设定一个增强的兼容模式

@PasDajavu v2 里面挺喜欢戴尔那个 24 寸的 4k 屏（ p2415q ）

其它的 4k 屏都可以。

楼主要是觉得值得，买苹果官网上那个售价 10000 的 LG 5k 屏（ tb3 接口，同时能向 mbp 供电）都可以。

用 loading cache ？设定好阈值后，读写过程中会自动 evict 旧数据

@gdtv 可以尝试防盗纱窗（就是楼上说的金刚网）

这两个地方：

/sdcard 分区
settings 数据库

这两个地方国产软件一般都会以类似动物撒尿留记号的方式滥用

@binxin 苹果的双重验证和旧的“两步验证”是略微不同的两步验证的实现，两者的备用方案的设置有所不同。

双重验证好像不提供恢复密钥这个手段

抵制淘口令，从楼主做起：没链接就算了

@fengleidongxi 不用永久识别码不意味着不能追踪到设备，比如：

阿里系应用 /SDK 存在 sdcard，settings 数据库的 utdid 之类

@madNeal 简单地说应用通过手机上的各种信号，在后台（不一定是应用提供商自身，通常是提供广告服务的）推断出你的身份，然后让电销联系你。

这点在 Android 上相对容易，因为 Android 上很容易获取到设备的永久唯一识别码，iOS 上则拿不到

@madNeal 跨应用用户追踪是目前非常普遍，甚至老套的技术了

@orangeade

AppOps 大部分的责任是充当 运行时权限机制 对付低 targetSDK 的应用
另一部分责任是对付所有用户可以改动的非运行时权限，且也不是 normal 权限的部分

@Jimjay
问题是在这两个方面：

Google 的责任：
1 运行时权限机制 设计成允许应用检测到的结果决定自身是否运行，但没有提供任何救济措施。
苹果的 app store 的上架审核能保证不会出现如此情况。

2 Android 暴露了一些不应该暴露的接口，比如我们最常诟病的手机权限涉及的 getDeviceId()，用以获取 IMEI。
在 iOS 上，这些永久识别码根本就是没有的。

应用开发者的责任：
它们区别对待了两个平台，既然在 iOS 端不能拿到永久识别码，在 Android 连尝试去拿也不可以（有些人不要拿“监管要求”来做挡箭牌）。

好在至少还有显式调用 AppOps 的办法，目前尚可以用来解决不给权限不运行的问题

@yidinghe 比较现实的方案是数据库自带支持的内存表或者 redis，既然要放内存一定会考虑断电导致的可靠性问题

一部分原因是高通的手表 AP 还是 28nm，功耗不低，下一代尚未发布。

@awpsawps12
谴责受害人

@wclebb 本来想用 honeypot，手滑写成了 honeycomb