AAOS中MUMD：车载用户权限实时仲裁机制深度解析

1. 项目概述：MUMD不是“多用户管理模块”，而是AAOS里真正管住方向盘的用户中枢

如果你最近在翻Android Automotive OS（AAOS）的源码，尤其是盯着packages/modules/CarUserService、services/car这些目录反复跳转，却总在UserManagerService和CarUserService之间绕晕——那你大概率已经撞上了MUMD这堵墙。它不是文档里轻描淡写的“Multi-User Management Daemon”，更不是Android Framework层那个通用UserManager的简单移植。MUMD（Multi-User Management Daemon）是AAOS中一个独立运行、拥有完整UID、不依赖Zygote启动、直接与HAL层交互的守护进程，它的核心使命只有一个：在车辆启动后3秒内完成主驾用户身份确认，并在后续驾驶全程中，以毫秒级响应速度隔离、冻结、唤醒、销毁用户会话，确保任何非主驾用户的后台服务无法触碰车辆控制权。我第一次在实车logcat里看到MUMD: User 10 is now ACTIVE (driver)这条日志时，手边正连着OBD-II调试器，发现此时CAN总线上的VEHICLE_USER_ID信号值同步更新为0x0A——这说明MUMD不是在“通知”系统用户变了，而是在“驱动”整车状态切换。它和传统Android的用户管理有本质区别：普通Android用户切换是UI层的视觉切换，AAOS里MUMD触发的是物理层的权限熔断。关键词AAOS、MUMD、Android Automotive OS、源码分析、用户管理，在这个上下文中，每一个词都指向一个硬性事实：你面对的不是一个App级功能，而是一套嵌入式实时安全机制。适合谁看？正在做AAOS定制ROM的系统工程师、需要对接车载用户态服务的中间件开发者、以及想搞懂AAOS权限模型底层逻辑的安全研究员。别指望靠查UserManagerAPI文档能理清它，因为MUMD压根不走那条路。

2. MUMD的设计逻辑与架构定位：为什么必须独立成Daemon，而不是Framework Service？

2.1 根本矛盾：汽车场景对“用户切换”的实时性与确定性要求，彻底否定了Zygote模型

先说结论：MUMD之所以被设计成一个独立Daemon，根本原因在于Zygote的fork-on-demand机制在车载场景下是致命缺陷。我们来算一笔账。AAOS要求从车辆上电（IG ON）到主驾用户完成身份认证（如指纹/人脸/蓝牙钥匙匹配），整个流程必须控制在3秒内。而Zygote启动一个新进程的典型耗时是多少？在高通SA8155P平台实测数据如下：

• Zygote预热完成（即zygote64进程已就绪）：约800ms
• fork出新进程（如CarUserService）：平均320ms
• 新进程执行onCreate()并完成Binder注册：再加450ms
• 总计：1570ms（仅单次启动）

这还没算上SystemServer加载UserManagerService、ActivityManagerService等依赖项的时间。一旦涉及多用户切换（比如副驾乘客临时登录查看导航历史），Zygote需要为每个用户fork一套完整的system_server子树，内存开销瞬间飙升，且无法保证所有服务在指定时间点完成状态同步。而MUMD的启动路径完全不同：它由init.rc在early-init阶段就拉起，使用service mumd /system/bin/mumd指令，进程UID固定为1029（AID_MUMD），完全绕过Zygote。我在/system/etc/init/mumd.rc里看到它的关键配置：

service mumd /system/bin/mumd class main user system group system audio camera input bluetooth inet net_bt_admin net_bt capabilities CAP_SYS_ADMIN CAP_SYS_PTRACE CAP_SYS_NICE seclabel u:r:mumd:s0 onrestart write /dev/kmsg "MUMD: restarted due to crash"

注意capabilities字段里的CAP_SYS_ADMIN和CAP_SYS_PTRACE——前者让它能直接操作/sys/class/leds/控制座舱氛围灯状态（用于用户切换时的视觉反馈），后者让它能attach到任意用户进程进行内存快照分析（用于检测恶意进程越权访问车辆控制API）。这种能力，Zygote孵化出的Java进程永远不可能获得。所以MUMD不是“为了模块化而模块化”，它是AAOS把用户管理从“应用生命周期管理”降维打击为“系统资源仲裁器”的必然选择。

2.2 架构分层：MUMD如何成为AAOS权限模型的“宪法法院”

AAOS的权限模型不是简单的Android Manifest声明+Runtime Permission，而是一个三层嵌套结构：

• L1 应用层：普通App通过CarUserManager调用switchUser()，但该调用只是向MUMD发送一个Binder请求，不触发任何实际状态变更；
• L2 框架层：CarUserService作为MUMD的代理，负责将用户切换事件广播给CarPropertyService、CarAudioService等，但它没有决策权，只做状态同步；
• L3 内核层：MUMD直接读取/dev/hw_random生成会话密钥，并通过ioctl调用VHAL（Vehicle HAL）的setUserStatus()接口，强制刷新VEHICLE_USER_ID属性。这才是真正的“开关”。

我在hardware/interfaces/automotive/vehicle/2.0/IVehicle.hal里找到了这个关键接口定义：

// IVehicle.hal interface IVehicle { setUserStatus(@UserStatus int status, @UserId int userId) generates (Result result); };

其中@UserStatus枚举值包括USER_STATUS_DRIVER_ACTIVE、USER_STATUS_PASSENGER_IDLE等，而@UserId就是Linux UID。MUMD拿到这个UID后，会立即执行三件事：

1. 调用libvhal的setUserStatus()，更新VHAL状态；
2. 向/dev/cpuctl/top-app/tasks写入当前UID，将其CPU调度优先级提升至最高；
3. 通过netlinksocket向carwatchdogd发送信号，要求其监控该UID下所有进程的/proc/[pid]/status中的CapEff字段，防止权限逃逸。

这套机制让MUMD成了AAOS里事实上的“宪法法院”：它不处理具体业务（比如显示哪个用户的联系人），但它裁定哪些UID有资格调用车辆控制API。当CarAudioService收到播放指令时，它第一件事不是去解码音频，而是通过Binder向MUMD查询当前VEHICLE_USER_ID是否等于调用方UID——如果否，直接返回PERMISSION_DENIED，连日志都不打。这种设计，把安全边界从“代码逻辑层”前移到了“进程创建层”，这才是AAOS用户管理的真正护城河。

2.3 与传统Android用户管理的本质差异：不是“多用户”，而是“多角色实时仲裁”

很多人误以为AAOS的MUMD是Android多用户功能的车载版，这是个危险的认知偏差。Android原生的多用户（如平板上的访客模式）核心目标是数据隔离：不同用户的应用数据存放在/data/user/0/、/data/user/10/等独立目录，共享同一套系统服务。而MUMD的目标是权限动态仲裁：它允许同一时刻多个用户进程存在（比如主驾在导航，副驾在听音乐），但必须确保只有USER_STATUS_DRIVER_ACTIVE对应的UID能调用VehicleProperty.VEHICLE_SPEED、VehicleProperty.STEERING_WHEEL_ANGLE等敏感属性。我在packages/services/Car/service/src/com/android/car/CarUserService.java里追踪到关键逻辑：

// CarUserService.java private void onUserSwitched(int newUserId) { // 注意：这里只是通知，不执行切换 mCarUserManager.notifyUserSwitched(newUserId); // 真正的切换发生在MUMD收到VHAL回调后 }

而MUMD的切换逻辑在system/sepolicy/private/mumd.te里被严格约束：

# mumd.te allow mumd appdomain:process { sigchld sigkill sigstop }; allow mumd vehicle_hal:fd use; allow mumd sysfs:file { read write open }; # 关键限制：禁止MUMD访问任何应用数据目录 deny mumd app_data_file:dir { search getattr }; deny mumd app_data_file:file { read write open };

这意味着MUMD连/data/data/目录的search权限都没有，它根本不知道微信装在哪个用户下，它只关心“此刻谁握着方向盘”。这种设计彻底规避了传统多用户模型中“用户A的应用偷偷读取用户B的GPS缓存”这类漏洞。所以准确地说，MUMD不是“Multi-User Management Daemon”，而是“Multi-Role Real-time Arbitration Daemon”——它管理的不是静态的“用户”，而是动态的“驾驶角色”。

3. MUMD核心源码解析与实操要点：从init.rc到VHAL回调的全链路拆解

3.1 启动入口与进程初始化：为什么mumd二进制必须静态链接libc++

MUMD的源码位于system/mumd/目录，其主入口函数main()在system/mumd/main.cpp中。与普通Android Native进程不同，它的编译规则在system/mumd/Android.bp里被强制指定：

cc_binary { name: "mumd", srcs: [ "main.cpp", "MumDService.cpp", "VhalClient.cpp", ], static_libs: [ "libbase", "liblog", "libutils", "libc++_static", // 强制静态链接！ ], shared_libs: [ "libbinder", "libhwbinder", "libvehiclehal", ], }

为什么要静态链接libc++_static？因为在车载启动早期，/system/lib64/libc++.so可能尚未挂载或未完成符号解析。我遇到过一次实车启动失败，logcat显示dlopen failed: library "libc++.so" not found，根源就是动态链接导致mumd在early-init阶段加载失败。静态链接后，mumd二进制大小从1.2MB涨到3.8MB，但换来的是启动确定性。main()函数的核心逻辑只有三行：

int main(int argc, char** argv) { // 1. 初始化SELinux上下文，确保seclabel u:r:mumd:s0生效 setcon("u:r:mumd:s0"); // 2. 创建MumDService单例，它持有VHAL连接和用户状态机 auto service = std::make_unique<MumDService>(); // 3. 进入主循环，监听VHAL事件和Binder请求 service->run(); return 0; }

这里的关键是setcon()调用——它不是可选的，而是强制要求。因为MUMD需要CAP_SYS_ADMIN能力来操作硬件，而SELinux策略规定只有u:r:mumd:s0上下文才能获得该capability。如果跳过这步，ioctl调用VHAL时会直接返回EPERM。我在调试时曾注释掉这行，结果mumd进程能起来，但所有VHAL通信都失败，花了两天才定位到这个细节。

3.2 用户状态机实现：DriverActive、PassengerIdle、GuestLocked三个状态的转换条件

MUMD内部维护一个有限状态机（FSM），定义在system/mumd/MumDService.h中：

enum class UserState { GUEST_LOCKED, // 无有效用户，车辆处于锁车状态 PASSENGER_IDLE, // 副驾用户已登录，但未激活驾驶权限 DRIVER_ACTIVE, // 主驾用户已认证，拥有全部车辆控制权 };

状态转换不是由App触发，而是由VHAL的onPropertyEvent()回调驱动。VhalClient.cpp里注册了事件监听：

void VhalClient::onPropertyEvent(const std::vector<VehiclePropValue>& values) { for (const auto& value : values) { if (value.prop == VehicleProperty::VEHICLE_USER_ID) { handleUserIdChange(value.int32Values[0]); } else if (value.prop == VehicleProperty::DOOR_STATE) { handleDoorStateChange(value.int32Values[0]); } } }

handleUserIdChange()是核心，它根据VEHICLE_USER_ID的值和当前车门状态决定状态跃迁：

注意authenticateDriver()的实现：它不是简单地设置状态，而是启动一个硬件级认证流程。在MumDService.cpp里，它会：

1. 向/dev/tpm0发送PCR Extend指令，将当前VEHICLE_USER_ID哈希值写入TPM芯片；
2. 通过ioctl调用VHAL的setUserStatus(DRIVER_ACTIVE)；
3. 向/sys/class/leds/seatbelt/status写入1，点亮主驾安全带指示灯；
4. 通过uevent向init发送change@/devices/virtual/input/input0事件，触发inputflinger重新映射按键。

这一整套动作必须在100ms内完成，否则VHAL会判定认证超时。我在高通平台实测，第1步TPM操作平均耗时42ms，第2步VHAL调用31ms，第3步LED控制8ms，第4步uevent 12ms，总和93ms——刚好卡在安全阈值内。这就是为什么MUMD必须是Native进程：Java层的GC停顿会让这个时间不可控。

3.3 Binder接口设计：CarUserService如何成为MUMD的“外交官”

MUMD本身不提供Binder接口给App调用，所有跨进程通信都通过CarUserService中转。CarUserService的ICarUserService.aidl定义了两个关键方法：

interface ICarUserService { void switchUser(int userId); int getCurrentUserId(); }

但switchUser()的实现非常微妙：

// CarUserService.java @Override public void switchUser(int userId) { // 1. 先检查调用方是否有INTERACT_ACROSS_USERS_FULL权限 mContext.enforceCallingPermission( android.Manifest.permission.INTERACT_ACROSS_USERS_FULL, "switchUser() from " + mContext.getPackageName()); // 2. 发送Broadcast到MUMD的私有Action Intent intent = new Intent("com.android.car.mumd.SWITCH_USER"); intent.putExtra("user_id", userId); intent.setPackage("android.car"); mContext.sendBroadcast(intent, "android.permission.INTERACT_ACROSS_USERS_FULL"); }

看到没？它没调用Binder，而是发了一个Broadcast。这是因为MUMD作为Native Daemon，不支持AIDL Binder通信（它没有Binder线程池）。CarUserService在onReceive()里捕获这个Broadcast后，才通过native方法调用MUMD的C++接口：

// native_mumd.cpp extern "C" { JNIEXPORT void JNICALL Java_com_android_car_CarUserService_nativeSwitchUser(JNIEnv *env, jclass clazz, jint userId) { // 调用MUMD的C API mumd_switch_user(userId); } }

而mumd_switch_user()在system/mumd/MumDService.cpp里只是一个代理：

void mumd_switch_user(int userId) { // 获取全局MumDService实例 auto* service = MumDService::getInstance(); if (service) { // 在MUMD主线程中异步执行，避免阻塞Java线程 service->post([userId]() { service->handleUserSwitchRequest(userId); }); } }

这种设计保证了Java层的调用不会因Native层阻塞而ANR，同时又让MUMD保持了对状态变更的绝对控制权。我在调试时发现，如果App直接调用switchUser(10)，但此时主驾门是关闭的，MUMD会忽略该请求，并在logcat输出MUMD: Ignored switch request for user 10, driver door closed——它不报错，只是静默丢弃，因为状态变更必须由硬件事件驱动，而非软件指令。

4. 实操过程与核心环节实现：从源码编译到实车验证的完整闭环

4.1 编译MUMD模块的隐藏依赖与常见错误

编译system/mumd/模块看似简单，但实际踩坑无数。最典型的错误是undefined reference to 'android::hardware::automotive::vehicle::V2_0::IVehicle::getService'，这表示libvehiclehal链接失败。根本原因在于AAOS的HAL版本管理机制：V2_0、V2_1等版本号不是软链接，而是由hidl-gen在编译时生成的硬编码头文件。解决方案是强制指定HAL版本：

# 在device/qcom/common/BoardConfig.mk中添加 BOARD_VEHICLE_HAL_VERSION := 2.1 # 然后清理并重编 m clean && m mumd

另一个致命问题是libbinder版本冲突。AAOS使用libbinder_ndk而非libbinder，因为VHAL要求NDK ABI兼容。如果忘记在Android.bp里声明：

shared_libs: [ "libbinder_ndk", // 必须是这个，不是libbinder "libhwbinder", "libvehiclehal", ],

编译会通过，但mumd运行时会崩溃在sp<IBinder> binder = defaultServiceManager()->getService(...)这行，logcat显示FATAL EXCEPTION: main Process: mumd, PID: 1234 java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "_ZN7android6Parcel10writeInt32Ei"。这是因为libbinder和libbinder_ndk的ABI不兼容。我为此重刷了三次车机固件，最终在system/core/libbinder_ndk/Android.bp里确认了正确的库名。

4.2 调试MUMD的三大黄金工具：logcat过滤、VHAL模拟器、strace跟踪

调试MUMD不能只靠logcat | grep mumd，必须组合使用三类工具：

第一，精准logcat过滤
MUMD的日志标签是MUMD，但默认级别是INFO，大量无关信息会淹没关键日志。启用详细日志需修改system/mumd/MumDService.cpp：

// 在构造函数中添加 android::base::SetMinimumLogSeverity(android::base::DEBUG); // 然后在关键路径加ALOGD ALOGD("MUMD: State transition %s -> %s", stateToString(mCurrentState).c_str(), stateToString(newState).c_str());

编译后，用以下命令过滤：

adb logcat -b main -b system -b events | grep -E "(MUMD|VHAL|CARUSER)"

第二，VHAL模拟器实战
没有实车时，用hardware/interfaces/automotive/vehicle/2.0/default/VehicleHalManager.cpp自带的模拟器：

# 启动模拟VHAL adb shell /system/bin/hw/android.hardware.automotive.vehicle@2.0-impl # 然后手动触发用户ID变更 adb shell "echo 10 > /sys/class/vehicle/vehicle_user_id"

此时mumd会立刻响应，logcat出现MUMD: User 10 is now ACTIVE (driver)。这是验证状态机逻辑最高效的方式。

第三，strace跟踪系统调用
MUMD的ioctl调用是黑盒，用strace抓取：

adb shell strace -p $(pidof mumd) -e trace=ioctl,open,write,read -f -s 256

输出示例：

[pid 1234] ioctl(3, VIDIOC_QUERYCAP or 0x80685600, 0x7ffcd12340) = 0 [pid 1234] write(4, "DRIVER_ACTIVE\0", 14) = 14 [pid 1234] ioctl(5, _IOC(_IOC_WRITE, 'V', 1, 0x10), 0x7ffcd12350) = 0

其中ioctl(5, ...)就是调用VHAL的setUserStatus()，参数0x7ffcd12350指向一个VehiclePropValue结构体。通过分析这个结构体，你能确认MUMD传递给VHAL的参数是否正确。

4.3 实车验证的五个必测场景与预期结果

在实车上验证MUMD，不能只测“能切换”，要覆盖边界场景：

我实测S5时发现，高通平台默认max_connections为5，当第6个用户连接时，VHAL会拒绝新连接，导致MUMD的VhalClient析构异常。修复方案是在hardware/interfaces/automotive/vehicle/2.0/default/VehicleHalManager.cpp里修改：

// 原代码 mMaxConnections = 5; // 改为 mMaxConnections = 20; // 根据车型配置

然后重新编译libvehiclehal和mumd。这个参数在AAOS文档里完全没提，是实车压力测试暴露的硬伤。

5. 常见问题与排查技巧实录：那些官方文档绝不会告诉你的坑

5.1 “MUMD进程启动失败，logcat无任何输出”——SELinux上下文未生效的静默失败

这是新手最常遇到的问题。现象是adb shell ps | grep mumd看不到进程，logcat | grep mumd空空如也。你以为是编译错了，其实根源在SELinux。init启动mumd时，如果setcon("u:r:mumd:s0")失败，进程会立即退出，但init不会记录错误——因为它认为这是进程自己的事。排查步骤：

1. 先确认mumd二进制的SELinux上下文：

   adb shell ls -Z /system/bin/mumd # 正确输出：u:object_r:mumd_file:s0 /system/bin/mumd # 错误输出：u:object_r:system_file:s0 /system/bin/mumd

2. 如果是system_file，说明sepolicy没编译进去：

   # 检查sepolicy是否包含mumd.te adb shell cat /sepolicy | grep mumd # 应该输出多行，包括allow mumd ...

3. 强制恢复上下文：

   adb shell restorecon -v /system/bin/mumd

提示：restorecon必须在adb root后执行，普通adb shell权限不够。我第一次遇到这个问题时，折腾了六小时，最后发现是make sepolicy没执行，out/target/product/xxx/obj/ETC/sepolicy.recovery_intermediates/目录下根本没有mumd.te的编译产物。

5.2 “VHAL回调不触发，MUMD始终停留在GUEST_LOCKED”——车门传感器HAL未正确注册

MUMD依赖DOOR_STATE属性变化来启动认证流程，但如果车门传感器的HAL没注册，onPropertyEvent()永远不会被调用。验证方法：

# 查看VHAL注册的属性列表 adb shell dumpsys vehicle | grep DOOR_STATE # 正确输出：PROPERTY_DOOR_STATE (int32) [0, 1, 2] # 错误输出：无此行

如果没输出，说明IVehicle的getProperties()没返回DOOR_STATE。根因通常是hardware/interfaces/automotive/vehicle/2.0/default/VehicleHalManager.cpp里的initialize()函数漏掉了：

// 必须添加这行 mSupportedProperties.insert(VehicleProperty::DOOR_STATE);

更隐蔽的坑是DOOR_STATE的areaId配置错误。AAOS要求主驾门的areaId必须是0x01，副驾是0x02，但有些OEM把主驾设成了0x00，导致MUMD的handleDoorStateChange()里判断失效：

// MumDService.cpp if (areaId == 0x01 && newState == DOOR_OPEN) { // 启动主驾认证 } else if (areaId == 0x02 && newState == DOOR_OPEN) { // 启动副驾认证 }

areaId=0x00时，两个分支都不进，MUMD就卡死了。解决方案是让VHAL团队修正areaId，或者在MUMD里加兜底逻辑：

// 临时修复 if (areaId == 0x00) areaId = 0x01; // 强制视为主驾

5.3 “用户切换后，CarAudioService仍播放副驾音乐”——Binder服务注册时机错位

这个Bug极其难复现，只在冷启动后首次切换时出现。现象是MUMD日志显示User 10 is now ACTIVE (driver)，但CarAudioService的onUserSwitched()没被调用。根源在于CarUserService的onBootPhase()执行顺序：

// CarUserService.java @Override public void onBootPhase(int phase) { if (phase == SystemService.PHASE_SYSTEM_SERVICES_READY) { // 此时CarAudioService可能还没注册Binder mCarAudioService = ICarAudioService.Stub.asInterface( ServiceManager.getService("car_audio")); } }

但CarAudioService的publishBinderService()在PHASE_ACTIVITY_MANAGER_READY才执行，比PHASE_SYSTEM_SERVICES_READY晚一个阶段。解决方案是延迟绑定：

// 改为在PHASE_THIRD_PARTY_APPS_CAN_START时绑定 if (phase == SystemService.PHASE_THIRD_PARTY_APPS_CAN_START) { // 使用Handler.postDelayed重试 mHandler.postDelayed(() -> { try { mCarAudioService = ICarAudioService.Stub.asInterface( ServiceManager.getService("car_audio")); } catch (Exception e) { mHandler.postDelayed(this::retryBind, 100); } }, 100); }

这个100ms的延迟，是我在实车测试中找到的最小可靠值——小于80ms，CarAudioService可能还没完成Binder注册；大于120ms，用户会觉得切换卡顿。

5.4 “TPM PCR Extend失败，认证超时”——硬件随机数生成器未就绪

MUMD在authenticateDriver()里调用/dev/tpm0，但某些车机平台TPM驱动加载慢于mumd启动。现象是logcat | grep tpm显示tpm_tis_spi spi0.0: TPM not ready。临时解决方案是加启动等待：

// MumDService.cpp bool waitForTpmReady() { for (int i = 0; i < 10; i++) { int fd = open("/dev/tpm0", O_RDWR); if (fd >= 0) { close(fd); return true; } usleep(100000); // 等100ms } return false; } // 在main()里调用 if (!waitForTpmReady()) { ALOGE("TPM not ready after 1s, exiting"); return -1; }

但治本之策是修改init.rc，让mumd在tpm服务之后启动：

# init.rc service tpm /system/bin/hw/android.hardware.tpm@1.0-impl class main user system group system service mumd /system/bin/mumd class main user system group system onrestart restart tpm # 关键：依赖tpm

这样init会确保tpm服务先于mumd启动，无需轮询等待。

5.5 “多用户并发时，MUMD CPU飙升至100%”——VHAL事件队列溢出未处理

当大量用户快速切换时，VHAL的onPropertyEvent()回调会堆积，而MUMD的handleUserIdChange()如果处理慢，事件队列就会溢出。现象是top显示mumdCPU 100%，logcat疯狂刷VHAL: Event queue full。根本原因是VhalClient的onPropertyEvent()是同步调用，如果handleUserIdChange()里做了耗时操作（比如读取/data/misc/car/下的大文件），就会阻塞整个VHAL事件循环。解决方案是解耦：

// VhalClient.cpp void VhalClient::onPropertyEvent(...) { // 不直接处理，而是投递到MUMD的事件队列 mMumDService->postEvent(std::move(values)); } // MumDService.cpp void MumDService::postEvent(std::vector<VehiclePropValue> values) { // 用std::queue缓存，主线程循环消费 std::lock_guard<std::mutex> lock(mEventQueueMutex); mEventQueue.push(std::move(values)); }

然后在MumDService::run()的主循环里：

while (true) { // 1. 处理事件队列 processEventQueue(); // 2. 处理Binder请求 processBinderRequests(); // 3. 睡眠1ms，避免忙等 usleep(1000); }

这个1ms的usleep是关键，它让MUMD从“实时抢占”降为“准实时”，CPU占用从100%降到5%，同时切换延迟仍在80ms内。这是我在某德系车企项目里总结出的黄金参数——太短，CPU高；太长，延迟超标。

注意：usleep(1000)不能写成std::this_thread::sleep_for(1ms)，因为后者在某些Android NDK版本里有精度问题，实测误差达5ms，导致延迟超标。必须用usleep这个C标准库函数，它是内核级精确睡眠。

6. MUMD的演进趋势与工程实践建议：从AAOS 13到14的架构收敛

6.1 AAOS 14的MUMD重构：从Native Daemon回归Framework Service的悖论

AAOS 14（代号Vanilla）的system/mumd/目录消失了，取而代之的是packages/services/Car/service/src/com/android/car/mumd/下的Java实现。初看是倒退，实则是架构收敛。新MUMD不再直接调用VHAL，而是通过`Vehicle