16、安全性与隐私：人脸数据存储位置、Android TEE与生物识别、隐私政策合规要求
聊到人脸识别，大家最关心的问题其实就一个：我的脸到底存哪儿了？ 会不会被App偷偷上传？会不会被黑客一把薅走？
嗯，这个问题问得好。我当年刚接触Android生物识别时，也一度以为人脸数据是存在某个云端数据库里的。后来踩了几个坑，翻了几遍源码，才真正搞明白——Android的人脸数据，压根儿就不在普通世界里待着。
人脸数据到底存哪儿？
说白了，你的人脸模板（不是照片，是数学特征）是存在设备本地的。而且不是普通的本地存储，是存在一个叫 TEE 的安全环境里。
我习惯把TEE理解成「手机里的保险柜」。普通App、普通系统服务，甚至Root后的超级用户，都拿不到里面的东西。为什么？因为TEE有自己独立的CPU、内存和存储空间，和主系统（REE）是物理隔离的。
关键点：人脸模板永远不会离开TEE。App拿到的只是一个「匹配结果」——是或否，而不是你的脸。
我在项目中遇到过一件事：有个产品经理问我，能不能把人脸数据备份到云端，方便用户换机时直接迁移。我当时就拒绝了——技术上做不到，合规上更不允许。 人脸数据一旦出了TEE，安全模型就崩塌了。
Android TEE 与生物识别的协作流程
Android的生物识别框架，其实是一个分层架构。我画了张图，帮你理清这个流程：
你看，从App到TEE，中间经过了框架层和HAL层。每一层都只做自己该做的事，人脸模板始终在最底层。App连模板的毛都摸不到。
我曾经踩过的坑：TEE通信超时
有一次我在做人脸解锁的自动化测试，发现偶尔会出现认证失败的情况。查了半天，最后定位到是 TEE 通信超时。
原因很简单：TEE是个独立系统，它有自己的调度策略。如果主系统频繁发起认证请求，TEE可能来不及处理，直接返回超时。解决方案是加一个重试机制，并且控制请求频率。
避坑指南：我曾经在代码里写了个死循环不断调 authenticate()，结果把TEE搞崩了，手机直接重启。后来学乖了——每次认证之间至少间隔500ms。
隐私政策合规要求
技术搞定了，合规这块也不能马虎。我见过不少App因为隐私政策写得含糊，被下架甚至罚款的。
Android 官方对生物识别数据有明确要求：
- 必须明确告知用户：人脸数据仅存储在本地，不会上传云端
- 必须获得用户明确同意：不能默认勾选，不能捆绑在其他权限里
- 必须提供关闭途径：用户随时可以删除已录入的人脸数据
- 不得用于其他目的：不能拿人脸数据做用户画像、广告推荐
我习惯在隐私政策里单独开一节，叫「生物识别信息处理说明」。里面写清楚：
1. 收集方式：通过设备摄像头采集人脸图像，仅用于生成数学特征模板
2. 存储位置：模板存储在设备TEE安全环境中，App无法访问
3. 处理目的：仅用于用户身份认证
4. 保留期限：用户删除人脸模板后立即销毁
5. 共享情况：不与任何第三方共享嗯，这里要注意一点：不要写「可能」「也许」「一般情况下」这种模糊词。合规审查最忌讳的就是模棱两可。
数据删除的「软删除」陷阱
我记得有个项目，用户反馈说「我明明删除了人脸数据，为什么设置里还显示已录入？」
查了一下，原来是开发同学用了「软删除」——只是在数据库里标记了一个删除状态，实际模板还在TEE里。这其实是不合规的。用户要求删除，你就得真删。
正确的做法是调用 BiometricManager.removeBiometric() 或者直接让用户去系统设置里删除。App层面不要自己维护一个「删除标记」。
警告：不要试图缓存或备份人脸模板。哪怕是为了「提升用户体验」也不行。一旦被检测到，轻则下架，重则面临法律风险。
总结一下
人脸数据的安全与隐私，说白了就是三件事：
- 存哪儿？ TEE里，App拿不到
- 怎么用？ 只做匹配，不传出去
- 合规吗？ 说清楚，用户同意，能删除
你想想看，如果每个App都老老实实按这个来，用户还有什么好担心的？可惜现实是，总有人想走捷径。嗯，咱们做技术的，守住底线就好。