解读

面试官抛出此题，表面问“限制”，实则考察候选人对车载场景特殊性的系统级理解：

1. 安全红线——车规级功能安全（ISO 26262）与信息安全（R155/R156）双重要求；
2. 资源天花板——车机 SoC 算力、内存、电池、4G/5G 模组均远弱于手机，且需优先保障仪表、ADAS 等实时任务；
3. 法规合规——中国《汽车数据安全管理若干规定》要求“默认不收集、车内处理、脱敏上传”，后台网络请求直接触碰合规高压线；
4. 用户体验——冷启动 2 s 内必须出 Launcher，后台服务抢占 CPU 导致导航丢帧，直接引发 OEM 验收失败。
   答不到“功能安全”与“国标合规”，会被视为仅懂手机开发。

知识点

1. 车载硬件拓扑：MCU+SoC 异构，Android 跑在信息娱乐 SoC，与仪表、车控 MCU 通过 CAN/LIN 总线耦合；后台服务占用 CPU 可能拖慢 CAN 报文调度，带来 ASIL-B 级随机失效风险。
2. 电源策略：12V 铅酸电池在熄火后由 BCM 统一休眠，Android 系统需进入 Suspend-to-RAM，任何持锁后台服务都会阻止 ECU 掉电，导致 24 h 内亏电，4S 店需免费救援，OEM 按台罚款 5000 元。
3. 网络合规：国家平台《新能源汽车运行安全监测》要求行驶数据“每 30 s 上传一次”且必须走 T-Box 专用通道；Android 应用若私自通过 Wi-Fi/蜂窝发数据，既挤占 T-Box 带宽，又可能上传未经脱敏的 GPS、VIN，触发工信部通报下架。
4. 性能模型：车载 Launcher 默认 60 fps，但 SoC GPU 浮点性能仅为骁龙 660 级别，后台服务一旦触发 GC 抖动，Navigation Map 渲染帧率掉到 35 fps，整车 DVP 实验被判不合格。
5. 系统裁剪：国内主流座舱 ROM 砍掉 Doze、App Standby 逻辑，改用 OEM 自定义的 CarService 强制冻结名单；后台服务若不在白名单，首次启动就会被 AMS 直接 kill，应用开发者无法申诉。
6. 安全沙箱：车机 SELinux 采用 strict 策略，禁止 untrusted_app 创建 RAW socket；后台网络请求若尝试走非主流端口，立即触发 audit avc denied，日志被 OEM 每日回传云端作为安全评分依据。

答案

车载 Android 应用必须严格控制后台服务与网络请求，核心原因可归纳为“安全、合规、资源、体验”四条高压线：

1. 功能安全：车机 SoC 与 MCU 共享同一电源域，后台服务持续持 WakeLock 会阻止整车进入休眠，导致 12 V 蓄电池亏电，引发车辆无法启动的严重安全事故；同时 CPU 抢占可能延迟 CAN 报文，违反 ISO 26262 的 ASIL-B 实时性要求。
2. 法规合规：中国《汽车数据安全管理若干规定》及《个人信息保护法》要求“车内处理、默认不收集、脱敏上传”，后台网络请求若私自采集车速、VIN、GPS 并外发，直接触碰数据出境与隐私合规红线，应用会被工信部通报、强制下架，并影响整车销售资质。
3. 资源硬限制：座舱 SoC 算力仅为同期手机 60%，内存普遍 4–6 GB，且需优先保障仪表、AR-HUD、ADAS 高优进程；后台服务占用 CPU/GC 导致导航丢帧，整车 DVP 实验 60 fps 不达标，OEM 将拒绝验收。
4. 电源与网络通道：熄火后整车由 BCM 统一休眠，Android 深度睡眠电流需 <2 mA；任何后台网络请求都会唤醒蜂窝模组，峰值电流升至 200 mA，24 h 内可耗尽电瓶。此外，国家平台规定行驶数据必须通过 T-Box 统一通道上传，Android 应用私自走 Wi-Fi/蜂窝既挤占带宽，又可能上传未加密数据，带来双重违规。
   因此，车载应用应遵循 OEM 的 CarService 电源策略：

• 后台任务统一迁移至可感知车辆电源状态的 CarUserService，熄火后 5 s 内释放 WakeLock；
• 网络请求集中到 OEM 白名单 CDN 域名，采用批量压缩上传，频率不超过 15 min/次，且数据需经过国密 SM4 加密与脱敏；
• 使用 WorkManager 约束条件“NETWORK_TYPE unmetered & battery not low”，并结合 VehicleProperty.POWER_STATE 动态取消任务；
• 禁止在后台创建常驻 Service，改用系统级 JobScheduler 或 OEM 提供的 CarAPI 进行托管，确保整车电源、性能、合规三维安全。

拓展思考

1. 如何证明你的后台策略不会导致亏电？
   可基于 OEM 提供的 Power Test Case：在 25 ℃ 环境下熄火静置 24 h，用电流钳测量整车暗电流，若 >2 mA 即不合格；需在代码中注入 android.car.power.CarPowerManager 回调，打印释放 WakeLock 与 Modem 休眠时间点，与 BCM 日志交叉验证。
2. 如果业务方坚持“实时上传驾驶行为数据”，如何平衡合规与实时性？
   采用“边缘计算+T-Box 透传”双通道方案：Android 端仅做特征提取，数据缓存在加密环形缓冲区，待车辆上电后通过 CarAPI 判断 T-Box 通道空闲，一次性打包经国密 SM2 签名后上传，既满足 30 s 国家平台要求，又避免 Android 后台网络唤醒。
3. 面对不同 OEM 的冻结白名单策略，如何设计可插拔的电源适配层？
   在 Gradle 层定义 flavor dimension：carA、carB，分别实现 IOemPowerAdapter 接口，内部封装各家 CarService AIDL 调用；构建流水线通过 buildVariant 自动打包，保证一套代码兼容多家车机电源模型，降低维护成本。