Android 的 Health Connect API 统一健康数据，厂商买账吗

Android 的 Health Connect API 统一健康数据，厂商买账吗

Google Fit 的葬礼与 Health Connect 的诞生

Google 在健康数据这件事上的反复无常，Android 开发者早就见怪不怪了。先是用 Google Fit 统一步数、心率和卡路里，折腾了七八年，突然在 2022 年宣布： Fit 那套 API 不行了，我们要搞一个真正的健康数据中间层。到了 2024 年，Google 直接给 Fit API 判了死刑，2025 年 6 月 30 日之后，com.google.android.gms:play-services-fitness 这个库就会彻底停止服务。你应用里如果还在调用 HistoryApi.readData() 读用户的历史步数，到时候不是返回空集合，是直接抛异常告诉你服务已停用。

这种"先拉你上车，再拆你轮子"的操作，Google 干得实在太多。当年 Google+ API 也是这个路数，后来 Hangouts API 也这么死过。Health Connect 的出现，本质上不是 Google 突然开窍了，而是发现自己在可穿戴领域快被苹果甩得连尾灯都看不见，Samsung 又根本不听号令，才不得不推的一个补丁式方案。

但问题在于，这个补丁打得太晚了。Apple 的 HealthKit 从 2014 年 iOS 8 就开始布局，到今天已经十年。十年里 Apple Watch 从第一代卖到了 Ultra 2，HealthKit 的数据模型、权限体系、后台同步机制全部跑通。Google 这边呢？Android Wear 改名叫 Wear OS，又收购了 Fitbit，结果健康数据还是散落在 Google Fit、Samsung Health、各种第三方运动 App 和 OEM 厂商的自研服务里。Health Connect 说是要统一，实际上是在为 Google 过去十年的生态混乱买单。

Android 14 的系统级特权：是整合，还是绑架

Health Connect 最开始是以独立 APK 的形式存在的，包名 com.google.android.apps.healthdata，在 Android 13 及以下的设备上，用户得自己去 Play Store 下载安装。这种安装率可想而知，普通用户根本不知道有这么个东西，开发者接入以后发现设备上没有 Health Connect，还得引导用户去装一个看似无关的系统组件。体验割裂得一塌糊涂。

到了 Android 14，Google 直接把 Health Connect 做成了系统组件，API 级别从 androidx.health.connect 的客户端库升级成了平台级权限框架。你在 Android 14 的设备上调用健康数据相关接口，不再需要检查某个 APK 是否安装，而是通过 android.health.connect.HealthConnectManager 这个系统服务来交互。权限也从普通的 Play Services 权限变成了平台签名的健康权限，比如 android.permission.health.READ_HEART_RATE、android.permission.health.WRITE_NUTRITION。

听起来像是终于上正席了，但实际上这是 Google 在用自己的系统分发优势强行推标准。Android 14 的权限管理把 Health Connect 嵌进了系统设置里，用户授权不是在应用内弹一个运行时权限对话框，而是被强制跳转到系统的 Health Connect 权限页面，让用户手动勾选"允许应用读取心率""允许应用读取睡眠数据"。这步跳转至少打断两次用户操作，转化率直接崩盘。

更微妙的是，Google 把 Health Connect 塞进系统框架的同时，也在收紧对健康类应用的管控。Google Play 现在要求所有申请健康数据权限的应用必须通过特定的敏感权限审核，声明隐私政策、数据加密措施、用户同意流程，稍有瑕疵就拒审。这套组合拳下来，表面看是 Google 在保护用户隐私，实际上是抬高了第三方健康应用的准入门槛。小团队做一个简单的血压记录工具，现在光是过 Play Store 的健康类审核就要折腾几个礼拜。而 Google 自家的 Fitbit 和 Pixel Watch 呢？它们天然拥有系统级通道的便利。

Samsung 的算盘：阳奉阴违的统一

要说 Android 阵营里谁的健康生态最扎实，非 Samsung 莫属。Galaxy Watch 系列在全球智能手表市场的份额稳居第二，Samsung Health 的活跃用户数以亿计。Samsung 有自己的 Exynos wearable 芯片、BioActive 传感器阵列、完整的睡眠和血压算法体系。Health Connect 想要真正统一 Android 健康数据，Samsung 的态度是决定性的。

Samsung 确实在公开场合给足了 Google 面子。2022 年底，Samsung 宣布与 Google 合作，在 One UI 5.1 中增加了对 Health Connect 的支持。Samsung Health 应用里也出现了一个开关，允许用户把步数、心率、睡眠等数据同步到 Health Connect。但这里面的门道很深。Samsung 同步过去的往往是"二手数据"，时间粒度、数据精度都经过了一层裁剪，而且最关键的锻炼详情——比如 Galaxy Watch 用自身 GPS 记录的跑步轨迹、泳池游泳的划水次数——根本不会暴露给 Health Connect。

Samsung 的底层逻辑很清晰：健康数据是 Galaxy 生态的护城河。用户买了 Galaxy Watch，被锁在 Samsung Health 的闭环里，数据分析、健康建议、挑战活动全部在 Samsung 的服务器上跑。如果把这些核心数据无条件开放给 Health Connect，第三方应用就能轻易地撬走用户，Samsung 还怎么卖它的 Galaxy Watch 和 Health Premium 订阅？

所以现在的局面极其荒谬：Health Connect 号称统一，但 Android 阵营最大的健康数据来源 Samsung Health，实际上只是象征性地扔过来一些步数总和。用户在 Samsung Health 里跑了五公里，第三方应用通过 Health Connect 可能只能看到一个总距离和平均心率，拿不到 GPS 路径，也拿不到分段配速。这种"接入"与其说是开放，不如说是敷衍。

国内厂商的态度就更直接。小米运动健康、华为运动健康、OPPO 健康，这些 App 压根就没有集成 Health Connect 的打算。它们连 Google Mobile Services 都不一定完整依赖，怎么可能把用户的心电图和血氧数据交给 Google 定义的中转站。Health Connect 所谓的统一，在 Android 最大的几个市场里根本就行不通。

权限与审批：比运行时权限更反人类的体验

作为开发者，接入 Health Connect 的过程足够让人脱层皮。首先要面对的是 Google Play 的健康类应用审批。你要提交详细的隐私政策，证明你处理心率、月经、血糖等敏感数据时符合当地法规，还要说明数据是否会被用于广告。很多独立开发者在这个阶段就被卡死了——不是技术不行，是法务和合规成本扛不住。

通过审核之后，真正的折磨才开始。Android 14 的 Health Connect 权限不是普通的 ActivityCompat.requestPermissions() 能搞定的。你需要在 AndroidManifest.xml 里声明细到变态的权限，比如读睡眠要 android.permission.health.READ_SLEEP，写体重要 android.permission.health.WRITE_BODY_WEIGHT。这些权限属于特殊权限组，应用安装时不会自动授予，用户必须进入系统设置 > 隐私 > Health Connect > 你的应用，一个一个手动打开。

更离谱的是后台读取。Health Connect 对后台访问的限制极其严格。如果你的应用需要在后台同步数据，比如一个睡眠监测应用想在用户睡醒后自动拉取昨晚的睡眠阶段，你必须申请 android.permission.health.READ_HEALTH_DATA_IN_BACKGROUND 这个权限。而这个权限的审批更加苛刻，Play Store 会要求你证明为什么不能在用户打开应用时再读数据。结果就是，大多数 Health Connect 应用只能做成"用户主动打开才同步"的半残形态。

还有那个权限变更机制。如果用户在系统设置里关掉了一个数据类型的权限，你的应用不会收到实时的 onPermissionsChange 回调，下次读取时才会发现权限没了，然后抛出一个 SecurityException。这种时序设计让开发者很难做好优雅的降级处理。Google 的文档里轻飘飘地写着"请妥善处理权限变更"，但实际代码里你要写一堆防御性判断，因为用户随时可能在系统设置里把你某个数据通道掐掉。

数据模型的纸面繁荣

Health Connect 的 API 设计看起来确实很全面。它定义了 ExerciseSessionRecord、HeartRateRecord、SleepStageRecord、NutritionRecord 等一大堆数据类型，还支持时间区间的聚合查询，比如查询某段时间内的总步数、平均心率、最大摄氧量。Google 的文档里把这些模型画成了一张庞大的 UML 图，仿佛 Android 上的健康数据终于有了一套完美的通用语言。

但用起来完全是另一回事。首先是数据类型的缺失。Health Connect 直到最近的版本才勉强支持体温、血糖和血压，而且血压记录还不支持多次测量的详细元数据。对于做深度健康分析的应用来说，这些数据远远不够。Apple HealthKit 早就支持心电图（ECG）的原始波形数据、环境音量、紫外线指数、甚至刷牙记录，Health Connect 在这些细分类型上依然空白。

其次是数据精度问题。Health Connect 为了兼容各种来源的设备，对数据单位和时间戳做了大量归一化处理。比如心率数据，Galaxy Watch 可能每秒钟采样一次