解读

面试官问的不是“Manifest 里怎么写 uses-feature”，而是“在 Play Console 里怎么把 Wear OS 设备筛出来”。
国内候选人常把“打包 wear.apk”和“在 Console 里做兼容性声明”混为一谈，结果答成“加 uses-feature=android.hardware.type.watch”就结束，直接掉分。
这道题考察三条线：

1. 上传轨道（Release Type）——必须走 Wear OS 专属轨道，而不是默认的手机轨道；
2. 设备目录（Device Catalog）——如何在 Console 里把“形状、屏幕密度、CPU abi、OpenGL 版本”等维度锁到 Wear 机型；
3. 国内多渠道差异——华为、小米、OPPO 手表商店并不直接拉取 Play Console 的兼容性矩阵，面试官想看你是否知道“Play 商店 ≠ 国内手表商店”，避免答成“一招鲜吃遍天”。

知识点

1. Wear OS 应用分发链路
   • 手机端 APK（即 Companion APK）与手表端 APK（Wear APK）通过 Play 的“多 APK 机制”或“App Bundle 的 device-tier”交付；
   • 只有走 Wear OS 轨道，Play 才会把包推送到手表端的 Play Store。
2. Play Console 后台入口
   Release → Production → Create new release → 勾选“Wear OS”轨道 → 上传 AAB/APK → 进入 Device Catalog 页面。
3. Device Catalog 三件套
   • 形状过滤：rect/round/chin；
   • 硬件特征：android.hardware.type.watch、SCREENLAYOUT_SIZE_SMALL、OPENGL ES 2.0+；
   • 排除规则：手动把不支持的设备加入“Excluded devices”列表，可一次性批量导入 CSV。
4. 国内商店差异
   华为手表应用市场读取的是手机端 manifest 里的 uses-feature 与 screenRatio，而不是 Play Console 的矩阵；小米手表商店额外校验 minSdk≤28 且 targetSdk≥30；OPPO 手表强制要求签名带 V2+V3 且包名以“.watch”结尾。面试时主动提到“国内需重新走厂商后台再配一次兼容性”，是加分项。
5. 测试与验证
   Play Console 的“Pre-launch report”对 Wear OS 只跑 5 款谷歌亲儿子表（Tiger、Rohan 等），国内候选人要补充“用 Firebase Test Lab 的 wear 镜像+ADB screenrecord 验证圆形裁剪”，体现实战。

答案

第一步，在 AndroidManifest.xml 中声明硬性条件，确保 Play 识别为手表应用：

<uses-feature android:name="android.hardware.type.watch" android:required="true"/>
<uses-feature android:name="android.hardware.screen.round" android:required="false"/>
<uses-sdk android:minSdkVersion="25" android:targetSdkVersion="33"/>

第二步，登录 Play Console → 选择对应应用 → Release → Production → 点击“Create new release” → 在“Release type”里勾选“Wear OS only”；若使用 App Bundle，可在 device-tier 模块里把 wear 模块标记为 tier=watch。
第三步，上传 AAB/APK 后，进入“Device catalog” → 过滤器选择“Shape: Round & Rect” → 系统会自动列出 200+ Wear 机型；手动把不满足 OpenGL ES 3.0 的低端设备（如 Wear 2100 系列）加入 Excluded 列表，可导出 CSV 批量维护。
第四步，保存并提交，Play 会在 1–2 小时内生成“Wear OS compatibility”报告，若出现“LARGE_SCREEN_UNSUPPORTED”警告，需检查是否误声明了 android:requiresSmallestWidthDp=600。
第五步，国内上架补充：华为需在 AppGallery Connect → 应用信息 →“设备范围”里再选手表型号；小米需在小米开发者后台“穿戴设备适配”里上传圆形截图并声明 chin 区域；OPPO 需单独签名并上传“穿戴专区”。

拓展思考

1. 如果项目采用单一代码仓，手机与手表共用 module，怎样在 Console 里做“分轨不分包”？
   答案：用 Bundle 的 device-tier 功能，把 wear 代码放在 dynamic-feature 模块，并在 Play Console 的“Device targeting”里把 tier=watch 与 tier=phone 分别映射到不同轨道，实现一次上传、多形态交付。
2. 当手表应用依赖心率传感器，而部分国行设备阉割了 SENSOR_TYPE_HEART_RATE，如何在 Console 里动态排除？
   答案：在 Manifest 声明

   <uses-feature android:name="android.hardware.sensor.heartrate" android:required="false"/>
   

   然后在运行时通过 PackageManager.hasSystemFeature 检测，若无则引导用户下载“基础版”；在 Play Console 的 Device Catalog 里用“Sensor availability”过滤条件，把缺失心率传感器的设备批量加入排除列表，降低差评率。
3. 面试官追问：如果谷歌未来把 Wear OS 合并到 Large Screen 轨道，兼容性策略怎么平滑迁移？
   答题思路：提前把 res/layout-w240dp-h240dp 与 sw_dp 限定符拆出来，利用 Bundle 的 screen-density 拆分项，保证迁移时只需在 Console 改“Form factor”标签，无需重新发包；同时把 OpenGL、CPU abi 的排除规则写成 Gradle 脚本，一键生成 CSV，方便后续批量导入新 Console 界面。