13、驾驶模式与状态管理：驾驶模式检测、CarDrivingStateManager、UI模式切换、安全限制策略
各位同学，今天我们来聊聊车载开发中一个非常核心的话题——驾驶模式与状态管理。说实话，这部分内容在普通手机应用开发中几乎不会遇到，但在车机上，它直接决定了你的应用能不能跑、什么时候跑、怎么跑。
我刚开始接触 Automotive 开发时，就踩过一个坑：写了一个视频播放器，在车辆静止时跑得好好的，结果一上路就黑屏了。当时我还以为是代码 bug，查了半天才发现——是驾驶模式检测把我的 UI 给切了。嗯，从那以后，我再也不敢忽视这个模块了。
13.1 驾驶模式检测：系统如何知道你在开车？
车机系统判断驾驶状态，靠的不是 GPS 速度，而是多个传感器融合的结果。说白了，系统会综合车轮转速、方向盘转角、加速度计等数据，来判断车辆是否在行驶中。
在 Android Automotive OS 中，驾驶状态被抽象为三个等级：
| 状态值 | 含义 | 典型场景 |
|---|---|---|
| 0 | 未驾驶（Parked） | 车辆熄火、P挡驻车 |
| 1 | 驾驶中（Moving） | 车辆行驶，速度 > 0 |
| 2 | 未知（Unknown） | 传感器数据不足，或初始化阶段 |
我个人习惯在应用启动时先检查当前驾驶状态，而不是等出问题了再补救。你想想看，如果用户刚上车挂上 D 挡，你的应用还在播放视频，那体验得多糟糕。
13.2 CarDrivingStateManager：驾驶状态的管理者
CarDrivingStateManager 是系统提供的一个系统服务管理器，专门用来获取和监听驾驶状态。它属于 Car API 的一部分，需要通过 Car 连接来获取实例。
我记得第一次用这个 API 时，还犯了个低级错误——直接在 Activity 的 onCreate 里调用了 getDrivingState()，结果返回的一直是 Unknown。后来才意识到，Car 连接是异步的，得等 onConnected 回调之后才能用。
来看一个标准的用法：
// 获取 Car 实例
Car car = Car.createCar(context, new Car.CarServiceLifecycleListener() {
@Override
public void onConnected(Car car) {
// 获取 CarDrivingStateManager
CarDrivingStateManager manager =
(CarDrivingStateManager) car.getCarManager(
android.car.Car.DRIVING_STATE_SERVICE);
// 获取当前驾驶状态
CarDrivingStateEvent event = manager.getCurrentDrivingState();
int state = event.getState(); // 0: Parked, 1: Moving, 2: Unknown
// 注册监听器
manager.registerListener(new CarDrivingStateManager.DrivingStateCallback() {
@Override
public void onDrivingStateChanged(CarDrivingStateEvent event) {
// 驾驶状态发生变化时回调
handleDrivingStateChange(event);
}
});
}
@Override
public void onDisconnected(Car car) {
// 断开连接时的清理工作
}
});
// 绑定 Car 服务
car.connect();这里有个细节要注意：registerListener 注册的回调是在主线程执行的，所以不要在回调里做耗时操作。我曾经在回调里直接弹了一个 Dialog，结果 ANR 了——嗯，血的教训。
13.3 UI模式切换：驾驶时界面该长什么样？
驾驶模式切换，说白了就是系统根据驾驶状态，自动调整 UI 的显示策略。比如车辆行驶时，视频播放器要隐藏、长文本要折叠、操作按钮要放大。
Android Automotive OS 提供了两种 UI 模式：
- Day/Night 模式：根据环境光线自动切换，这个和手机类似
- 驾驶模式：根据驾驶状态切换，这个是车机独有的
我建议你在布局文件中就做好两种状态的适配，而不是在代码里动态隐藏/显示 View。为什么呢？因为布局适配更稳定，不容易出现闪烁或布局错乱。
举个例子，一个视频播放界面，在停车时可以全屏播放，但在行驶中应该只显示音频控制面板：
<!-- layout/activity_video_player.xml -->
<LinearLayout>
<!-- 视频播放器，驾驶时隐藏 -->
<SurfaceView
android:id="@+id/video_surface"
android:visibility="gone"
app:drivingModeVisibility="gone" />
<!-- 音频控制面板，驾驶时显示 -->
<LinearLayout
android:id="@+id/audio_controls"
android:visibility="visible"
app:drivingModeVisibility="visible" />
</LinearLayout>这里用到了 app:drivingModeVisibility 这个自定义属性，它可以在驾驶模式切换时自动改变 View 的可见性。当然，你也可以在代码中监听驾驶状态变化，手动控制 UI 切换。
LocalDrivingState 来响应式地更新 UI。这样代码更简洁，也不容易遗漏状态变化。
13.4 安全限制策略：哪些功能不能碰？
安全限制策略，是 Automotive 开发中最让人头疼的部分之一。系统会限制某些功能在驾驶时使用，比如：
- 视频播放（包括本地和流媒体）
- 长文本阅读（超过一定字数的内容）
- 复杂交互操作（如设置向导、键盘输入）
- 第三方应用启动（某些系统会限制）
为什么会这样？说白了，就是为了让驾驶员集中注意力。你想想看，如果司机在高速上开车时还在刷短视频，那后果不堪设想。
系统通过 TaskView 限制 和 UX 限制 两层机制来实现安全策略：
| 限制类型 | 作用范围 | 典型表现 |
|---|---|---|
| TaskView 限制 | 整个 Activity 或 Task | 驾驶时直接隐藏或替换为安全页面 |
| UX 限制 | 单个 View 或组件 | 按钮变灰、输入框不可编辑 |
我建议你在开发阶段就开启驾驶模式测试，不要等到上线了才发现功能被限制了。怎么测试呢？可以用 adb 命令模拟驾驶状态：
# 模拟停车状态
adb shell dumpsys activity service com.android.car/.drivingstate.CarDrivingStateService \
--set-state 0
# 模拟行驶状态
adb shell dumpsys activity service com.android.car/.drivingstate.CarDrivingStateService \
--set-state 1这个命令我在项目中用了无数次，每次改完 UI 都要跑一遍，确保驾驶时该隐藏的隐藏、该禁用的禁用。
13.5 知识体系总览
下面这张图是我自己整理的驾驶模式与状态管理的整体架构，你可以把它当作一个快速参考：
从这张图可以看出，整个驾驶模式管理是一个从底层传感器到上层应用的完整链路。传感器数据经过系统服务处理后，通过 CarDrivingStateManager 暴露给应用层。应用层再根据驾驶状态，决定 UI 如何切换、哪些功能要限制。
嗯，到这里，驾驶模式与状态管理的内容就讲完了。这部分知识虽然看起来简单，但实际项目中坑不少。我建议你把代码示例跑一遍，再用 adb 命令模拟各种状态，亲自感受一下 UI 切换的效果。只有亲手试过，才能真正理解这些 API 的用法和限制。