Android Automotive OS与普通Android有何核心区别？

Question

**常见技术问题：** 在开发车载应用时，为何直接将手机端Android APK安装到Android Automotive OS（AAOS）设备上会启动失败或被系统拒绝？根本原因是否仅在于``这类声明？实际上，AAOS与普通Android存在更深层架构差异：它移除了WebView、Google Mobile Services（GMS）及大部分用户级系统UI（如Launcher、通知栏），强制采用CarAppService框架和CarLibrary API进行HMI交互；权限模型强化了车辆功能访问控制（如`CAR_CONTROL_*`权限需预授权）；且系统服务层（如CarService）替代了传统AMS/PMS，应用生命周期由车载环境（如驾驶状态）动态管控。这些设计使AAOS并非“带车机UI的Android”，而是一个面向功能安全、低延迟、多用户隔离的垂直操作系统——这正是跨平台移植失败的核心根源。

Answer 1

```html

一、表层现象：安装失败的直观表现

• APK 安装成功但图标不显示（Launcher Activity 被系统过滤）
• 点击图标无响应，Logcat 显示 ActivityNotFoundException 或 SecurityException: Permission denied
• adb install 返回 INSTALL_FAILED_INVALID_APK 或 INSTALL_FAILED_DUPLICATE_PERMISSION
• 应用进程启动后秒退，dumpsys activity 显示未注册至 CarAppService

二、配置层根因：Manifest 声明缺失只是“冰山一角”

仅添加 <uses-feature android:name="android.hardware.type.automotive" android:required="true"/> 并不足以适配 AAOS。该声明仅用于包管理器（PMS）的静态过滤，而 AAOS 的运行时约束远超此范围：

约束维度	Android Mobile	AAOS（Android 13+）
Launcher Activity 类型	任意 LAUNCHER Intent-Filter	必须继承 CarAppActivity，且声明 android.car.cluster 或 android.car.media category
WebView 支持	默认集成 System WebView	完全移除 WebViewProvider；调用 WebView.newInstance() 直接抛出 UnsupportedOperationException

三、架构层差异：从通用 OS 到垂直车载操作系统

AAOS 并非 Android 的“皮肤定制版”，而是重构级演进：

graph TD
  A[Android Mobile] -->|AMS/PMS/NotificationManager| B[用户中心服务栈]
  C[AAOS] -->|CarService/CarInputService/CarPropertyService| D[车辆功能中心服务栈]
  D --> E[强制多用户隔离：Driver/Passenger Profile]
  D --> F[驾驶状态感知：DrivingStateService 动态冻结/恢复 Activity]
  D --> G[CAR_* 权限模型：需 OEM 在 device policy 中预授权，非 runtime request]

四、运行时约束：生命周期与安全模型深度耦合

• 应用无法自主进入前台：必须通过 CarAppService 绑定并响应 onAppFocusChanged() 回调
• 所有车辆控制操作（如空调、车窗）需声明 android.permission.CAR_CONTROL_CLIMATE 等权限，并在 car_app_desc.xml 中显式声明能力契约
• 后台服务受严格限制：startForegroundService() 在驾驶状态下被拦截，须使用 CarServiceHelperService 代理
• GMS 依赖（如 Firebase Auth、Play Core）全部不可用；AAOS 提供替代方案：CarTrustAgent、OemCarService

五、工程化解决方案：面向 AAOS 的重构路径

1. 模块解耦：将 UI、业务、车辆控制逻辑拆分为 app-mobile / app-auto / core-lib 三层
2. CarLibrary 集成：引入 androidx.car.app:app:1.4.0，重写入口 Activity 为 CarAppActivity
3. 权限与能力声明：在 res/xml/car_app_desc.xml 中定义支持的 car capability（如 media, navigation）
4. 构建差异化：使用 Gradle flavor autoRelease 启用 android.car SDK 编译，禁用 WebView/GMS 依赖
5. 仿真验证：基于 Android Studio 的 Automotive Emulator + CarServiceStub 进行驾驶态/停车态生命周期测试

六、关键代码示例：AAOS 入口 Activity 正确写法

// ✅ 正确：AAOS 兼容入口
public class CarMainActivity extends CarAppActivity {
    @Override
    public void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        // 必须通过 CarContext 获取车辆服务
        CarContext carContext = getCarContext();
        CarPropertyManager propertyMgr = carContext.getCarService(CarPropertyManager.class);
        // ❌ 错误：直接 new Intent(Intent.ACTION_VIEW, uri) 将被拦截
        // ✅ 正确：使用 CarAppService 启动导航等场景化任务
        carContext.startCarApp(new Intent(CarIntent.ACTION_NAVIGATE));
    }
}

七、OEM 协同要点：不可绕过的系统级依赖

即使代码完全合规，仍需 OEM 层配合：

• 设备 manifest 中必须声明 <feature name="android.hardware.type.automotive" />
• OEM 必须预置 CarService 实现，并在 /system/etc/permissions/ 下提供 privapp-permissions-com.yourpkg.xml 授权 CAR_* 权限
• 应用签名需匹配 OEM 白名单（部分 Tier1 要求 SHA-256 签名哈希预注册）
• 若使用 CarHardwareManager 访问 CAN 总线，需 OEM 提供 HAL 接口实现（hardware/interfaces/automotive/can/）

```