解读

面试官问的是“发布形态”，而不是“能否共用代码”。国内主流渠道（华为应用市场、OPPO 软件商店、小米应用商店、腾讯应用宝等）以及 Google Play 中国区，对 Wear OS 包体的上架策略与手机包体是解耦的。也就是说，系统层面允许一个手机 APK 里顺带塞一个 wear 模块，但国内商店几乎清一色要求手表包独立上架，且审核标准、签名证书、包名、隐私检测、权限声明、性能基线都要单独过。若候选人只回答“可以放在手机 APK 里”会被判为对国内政策不熟；若只回答“必须独立”却不提 multi-APK、versionCode 区间、签名一致性，又显得太浅。因此，要把技术可行性与国内现实政策分开讲，再给出落地套路。

知识点

1. 技术维度

   • 原生方案：AndroidManifest 中 targetDeviceId = "wear" + 手机模块 res/xml/wearable_app_desc.xml 描述，打包成单一 APK（legacy 方案）。
   • 多 APK 方案：同一应用列表下上传 phone APK（versionCode 1-1023）与 wear APK（versionCode 1024-2047），共享 packageName、签名证书，商店自动分发给对应设备。
   • App Bundle 方案：wear 模块作为 dynamic feature，上传 AAB，Google Play 自动拆包；国内商店暂不支持 AAB，需主动拆成独立 APK。
   • 签名一致性：手机与手表包必须使用同一证书，否则 CompanionDeviceManager 无法静默升级，且国内商店会拒绝“同包名不同签名”的上传。

2. 国内政策维度

   • 华为、小米、OPPO、vivo 的手表审核后台与手机后台分离，必须新建“穿戴应用”类目，独立填写隐私问卷、权限说明、硬件能力（GPS、心率、LTE）证明。
   • 国内要求 wear APK 最低 targetSdkVersion 与手机端保持一致，且必须适配圆形表盘、磁吸充电、低电量广播、后台运动权限等特殊检测项。
   • 工信部隐私抽检：手表包若与手机包共用云侧账号，需在独立上架的《隐私政策》里再次声明“与手机端共享用户标识符”，否则会被下架。

3. 分发与更新维度

   • Google Play：支持 multi-APK 与 AAB，用户用手机浏览详情页时自动推送手表侧安装，体验无缝。
   • 国内：用户必须在手表应用市场二次点击确认，无法像 Google Play 那样静默推送；若手机端内置“换机同步”SDK，仍需走手表市场客户端下载，不能通过自家服务器直链。

答案

技术上既可以把 Wear 模块作为手机 APK 的附属（单一 APK 或多 APK 共用包名），也可以完全独立发布；但在国内现实场景下，所有主流渠道都要求 Wear 包独立上架、独立审核、独立隐私合规报告，且 versionCode、签名证书必须与手机端保持一致，以便后续账号互通和静默升级。因此，落地做法是：

1. 共用一套代码仓库，wear 模块通过 productFlavor 隔离；
2. 构建时打出两个 APK（phone / wear），wear 端 versionCode 区间 1024-2047；
3. 上传国内商店时，手机端走“手机应用”入口，手表端走“穿戴应用”入口，分别填写审核资料；
4. 签名使用同一证书，确保 CompanionDeviceManager 升级通道可用；
5. 若需要海外同步上架，再用同一 AAB 提交 Google Play，实现一套代码、两种分发形态。

拓展思考

1. 折叠屏与 Wear 双端场景：如果手机端适配了折叠屏，wear 端作为远程遥控器，需要额外声明 <uses-feature android:name="android.hardware.type.watch" android:required="true"/>，避免折叠屏设备误装手表包。
2. 隐私沙盒影响：Android 14 限制后台启动 Activity，手表端通过 DataLayer 唤醒手机端支付页面时，需改用 Notification+PendingIntent 方式，否则在独立 wear 包中会被系统拦截。
3. 性能基线：国内小米、华为手表审核要求冷启动 <800 ms、90% 帧率 ≥ 55 fps，需在 wear 包中关闭 Compose 的 debug 模式并启用 R8 fullMode，与手机端配置分离，防止手机端调试开关拖慢手表性能。