# 【移远产品体验官】Quectel Pi M2 导航投屏实战：从 BLE 摘要到 LIVI 无线 Android Auto，蓝牙连上后还差哪几步？

JJJ · 2026 年10 月 28 日 09:48

**# 【移远产品体验官】Quectel Pi M2 导航投屏实战：从 BLE 摘要到 LIVI 无线 Android Auto，蓝牙连上后 # 【移远产品体验官】Quectel Pi M2 导航投屏实战：从 BLE 摘要到 LIVI 无线 Android Auto，蓝牙连上后还差哪几步？

> 体验平台：Quectel Pi M2（RK3576），Debian 13.7 / aarch64。

> 接收端：LIVI 9.4.0 Linux ARM64 AppImage。

> 记录日期：2026-10-25。

> 当前阶段：LIVI 图形界面、helper 与普通蓝牙连接已验证；Android Auto 导航画面尚未完成现场验收。

我参与移远产品体验官计划后，一直想把 M2 和安卓手机连起来：消息能在小屏幕上看，音乐能控制，来电能提示，导航也能放到板子连接的显示屏上。最开始做的是 BLE 伴侣应用，后来需求逐渐明确——我想要的是手机负责导航计算，M2 负责显示和交互，体验接近车载中控。

真正开始调试后，最让人困惑的并不是某条复杂协议，而是一个很日常的现象：手机显示蓝牙已连接，M2 屏幕也显示已连接，手机却始终没有 Android Auto 的连接或授权提示。

这篇记录围绕这个问题展开。已经拿到证据的部分写清楚；只有猜测的地方保留为排查项。LIVI 的界面跑起来，不等于 Android Auto 已经连接；普通蓝牙配对成功，也不等于导航画面正在传输。

## 一、先把当前进度摆出来

| 环节 | 当前结果 | 证据或限制 |

| — | — | — |

| M2 系统与架构 | 已确认 | Debian 13.7，aarch64 |

| 蓝牙硬件与 BlueZ | 已确认可用 | `hci0` 已上电，手机实际出现在已连接设备列表 |

| Wi-Fi AP 与 5 GHz 能力 | 驱动声明支持 | `iw list` 包含 AP、Band 2 与 managed + AP 并发组合 |

| LIVI 图形界面 | 已跑通 | 本地 Wayland 桌面启动，日志出现 `UI started` |

| LIVI 特权 helper | 已跑通启动 | 进程以 root 运行，已出现蓝牙 profile 和本地 socket 初始化日志 |

| 无线 Android Auto 开关 | 找到过明确阻断点 | 最近一次命令核验为 `wirelessAaEnabled=false`、`LIVI_AA_WIRELESS=0` |

| 界面开启后的设置生效情况 | 尚缺新证据 | 后续界面已打开开关，但尚未取得对应的新配置、helper 环境和握手日志 |

| LIVI Wi-Fi AP | 最近一次检查未建立 | 只看到 `wlan0` 为 managed，仍连接调试用手机热点 |

| Android Auto 授权与会话 | 未完成 | 安卓手机尚未弹出连接或授权提示 |

| 高德实际导航画面 | 未验收 | 尚未确认当前手机高德版本在 Android Auto 应用列表中可用 |

| 后台导航、触控、音乐和通话闭环 | 未验收 | 必须在会话建立后逐项测试 |

这里有一个时间顺序需要特别说明：`false / 0` 是最后一次通过命令确认的状态；随后界面开关已经打开，但没有新的运行时输出。因此，不能把旧值当成永久现状，也不能只凭界面开关就宣布整条链路恢复。

## 二、导航需求是怎样从“传几个字段”变成“接收车机画面”的

### 2.1 最初的 BLE 方案做了什么

早期伴侣应用的思路，是让安卓手机把通知、媒体状态、来电状态和导航摘要通过自定义 BLE GATT 服务发给 M2，板端再用自己的界面显示。反向控制也走自定义命令，例如下一首、暂停等。

它适合传递“前方右转、剩余距离、预计到达时间”这样的结构化信息。就算进一步分片传递了路线折线，板端拿到的仍然是数据，需要自己实现地图底图、坐标转换、缩放与路线绘制。

这里最容易误解的一点是：**收到一条导航 JSON，和显示高德完整地图，是两种不同的能力。** 自定义 BLE 服务不会因为已经能传通知，就自动拥有地图画面、媒体音频和通话音频。

历史工程记录中涉及 `agent/drivers/ble_gatt.py`、`ble_protocol.py`、`bluetooth.py`，以及手机端的 `M2LinkService.kt`、`BleProtocol.kt`。这些文件名用于区分旧伴侣应用的职责，本次整理没有重新审计它们在板端的最新版本，因此不把历史功能描述当作当前代码全部通过的证明。

### 2.2 为什么最终选择 LIVI + 无线 Android Auto

我的需求后来收敛成三件事：

1. 导航计算和地图应用仍放在安卓手机上，不在 M2 上另写地图引擎。

2. M2 连接显示器，作为接收、显示和交互终端。

3. 先打通最小链路，再谈音乐、通话、后台运行和产品化。

几种路线的边界如下：

| — | — | — | — |

本次没有接入高德地图 API，也没有在 M2 上实现路线规划。LIVI 是第三方 Android Auto 接收程序，我做的是 M2 上的集成与排障。

**手机安装了 Android Auto，并不能证明当前手机里的高德版本一定支持 Android Auto。** 这要在 AA 连接成功后查看实际应用列表，并启动导航确认。到目前为止，这一步还没走完。

### 2.3 两个原始要求，需要分别验收

“手机导航画面和 M2 一模一样”属于屏幕镜像要求；“手机切到别的应用，M2 继续独立显示导航”更接近车机投射要求。本文选择后者，因此接受 Android Auto 的车机界面形态。

手机按 Home 回到桌面、切换其他应用、系统回收进程、用户强行停止地图，分别是不同状态。后续必须实测，不能用一句“支持后台”把它们混在一起。

## 三、先理解整条链路，才知道应该查哪里

```text

安卓手机 Quectel Pi M2

Android Auto + 兼容的导航应用 LIVI 9.4.0

      │                                  │

      ├──── 蓝牙发现、配对与无线启动协商 ──┤

      │                                  │

      ├──── 加入 M2/LIVI 提供的 Wi-Fi ────┤

      │                                  │

      ├──── Android Auto 会话与画面传输 ──┤

      │                                  ├── LIVI compositor / UI

      │                                  └── M2 显示器

      └──── 触控、媒体和通话等能力：分别验收

```

这里不要把蓝牙当成整段导航视频的承载链路。LIVI 的无线说明里，蓝牙承担配对与交接，后续投射会话通过 Wi-Fi 运行。[2]

我后来把连接过程拆成六个检查点：

| 检查点 | 要确认的事实 | 不能拿来代替它的现象 |

| — | — | — |

| ① 程序运行 | core、compositor、UI 与 helper 存在 | AppImage 文件已经下载 |

| ② 蓝牙连接 | 指定安卓手机出现在已连接列表 | M2 显示屏残留“已连接”字样 |

| ③ 无线 AA 启用 | 保存值和 helper 参数都已开启 | 手机开发者设置里的无线 AA 已开 |

| ④ 热点就绪 | AP 接口、SSID 和服务状态可核验 | 驱动支持 AP 或安装了 hostapd |

| ⑤ AA 会话建立 | 真实连接事件、手机提示或车机画面 | 初始化时打印了 `AaSession display` |

| ⑥ 地图应用可用 | 在 AA 中找到目标应用并实际导航 | 手机上的高德单独能打开 |

其中任何一步没有证据，就在那一步停下来。不要一口气把手机配对、系统网络和显示配置全部重置。

## 四、我的测试环境与关键文件

### 4.1 已有记录能确认的环境

| 项目 | 本次记录 |

| — | — |

| 开发板 / SoC | Quectel Pi M2 / RK3576 |

| 系统 / 架构 | Debian 13.7 / aarch64 |

| LIVI | `LIVI-9.4.0-linux-arm64.AppImage` |

| 蓝牙控制器 | `hci0`，名称 `linaro-alip` |

| Wi-Fi 接口 | `wlan0` |

| 图形环境 | M2 本地 Wayland 桌面 |

| 音频服务 | PulseAudio 协议兼容服务，实际后端为 PipeWire 1.4.2 |

| 默认音频输出 | `alsa_output.platform-es8389-sound.analog-stereo` |

| AA 显示参数 | 启动日志协商目标为 1280×720、180 dpi；尚无实际导航视频验收 |

| 安卓手机 | 最近一组连接记录为 iQOO Z11 Turbo；已确认安装 AA 并开启手机侧无线 AA |

| 调试网络 | M2 的 `wlan0` 连接另一部手机提供的热点 |

这些是本次终端记录，不代表所有 M2 固件的默认配置。内核、手机系统与高德应用版本没有完整留档，本文不借用其他体验帖的版本号补齐。

蓝牙地址、手机个人名称、热点名称和 SSH 地址在公开示例中做了省略；登录密码与无线密码不放进帖子。

### 4.2 文件与组件索引

| 路径 | 用途 | 本次如何使用 |

| — | — | — |

| `/home/ji/Downloads/LIVI-9.4.0-linux-arm64.AppImage` | 本次使用的发行程序 | 在 M2 本地桌面终端启动 |

| `/home/ji/.config/LIVI/config.json` | LIVI 用户配置 | 只提取需要核对的字段，不整份公开 |

| `/home/ji/.config/LIVI/log/LIVI.log` | 当前核心与 helper 日志 | 对照本次启动和连接尝试 |

| `/home/ji/.config/LIVI/log/LIVI.1.log` 等 | 轮转历史日志 | 查历史行为，不作为进程仍在运行的证明 |

| `/home/ji/.config/LIVI/log/compositor.log` | 图形合成器日志 | 找到 `NoCompositor` 的直接报错 |

| `/home/ji/.config/LIVI/log/gst-host.log` | 媒体子进程相关日志 | 在需要排查画面解码时再查看 |

| `/home/ji/.config/LIVI/driver/livi-helperd` | 特权辅助程序 | 通过已有 sudoers 规则启动 |

| `/run/user/1000/livi/core.sock` | 本次用户运行目录中的核心 IPC socket | 查看是否存在监听者 |

| `/tmp/aa-bt.sock` | helper 与核心之间的 AA 本地接口 | 监听成功不等于手机已经连接 |

| `/etc/sudoers.d/99-LIVI-helper` | 本次已授权添加的 helper 规则 | 已通过 sudoers 语法与权限核验 |

| `/home/ji/.config/wireplumber/wireplumber.conf.d/99-livi-hfp.conf` | 历史蓝牙角色覆盖配置 | 保留为待审查配置，不盲目删除 |

| `/usr/local/lib/livi/livi-touch-filter` | 已发现的触摸辅助组件 | 文件存在不代表 AA 触控已验收 |

| `/usr/local/lib/livi/gvfs-phone-guard.sh` | 已有的手机挂载防护辅助脚本 | 本次没有重新安装或扩大权限 |

`1000` 是本次用户的 UID，其他设备应按 `/usr/bin/id -u` 的结果替换。运行时目录通常随用户会话建立和清理，不是永久配置目录。

### 4.3 其他读者如何选择安装包

本次使用的是官方 `v9.4.0` 发行页中的 `LIVI-9.4.0-linux-arm64.AppImage`，与板端 `aarch64` 架构对应。[12] 复现本文时应记录实际版本，不把不同版本的设置项、安装器和日志行为混在一起。

已有同一版本文件的设备，不需要为了排障重复下载安装。新设备应先确认架构、发行资产来源和运行依赖，再赋予 AppImage 执行权限；涉及特权 helper、AP 服务和网络管理配置的安装步骤，应先阅读对应版本说明及变更范围。不要把 AppImage 可执行，理解成无线热点配套组件已经全部配置完成。

## 五、依赖已经安装，命令却找不到：先查路径

### 5.1 本次补装与复检经过

最初阶段只明确补装了两个缺失包：`libfuse2t64` 和 `iw`。当时执行的是：

```bash

# 历史安装记录：不是要求当前设备再执行一次。

sudo apt update && sudo apt install -y libfuse2t64 iw

```

没有执行 `apt upgrade` 或 `full-upgrade`。后续依赖复核时，其他运行包也逐项确认已安装。

| 包 | 当时记录的状态 / 版本 |

| — | — |

| `libfuse2t64` | 已安装，2.9.9-9 |

| `iw` | 已安装，6.9-1+b1 |

| `bluez` | 已安装，5.82-1.1 |

| `libspa-0.2-bluetooth` | 已安装，1.4.2-1 |

| `dnsmasq-base` | 已安装，2.91-1+deb13u2 |

| `pulseaudio-utils` | 已安装，17.0+dfsg1-2+b1 |

| `rfkill` | 已安装，2.41.5-0+deb13u1 |

| `hostapd`、`avahi-daemon`、`avahi-utils` | 后续已确认安装；本文未记录完整版本号 |

`libfuse2t64` 是这次 Debian 环境中的包名；换发行版时不要直接照搬成通用安装命令。

### 5.2 第一个误判：`iw: command not found`

包列表已经显示 `iw` 为 `ii`，直接执行却找不到命令。实际二进制在：

```text

/usr/sbin/iw

```

当前普通用户 PATH 没包含 `/usr/sbin`。使用绝对路径后就能正常工作，没有必要重新安装软件、修改驱动或重启网络。

可复用的只读核对，一次三条：

```bash

/usr/bin/dpkg -l libfuse2t64 iw

/usr/bin/dpkg -L iw

/usr/sbin/iw dev

```

另一种输出是整页 `iw` 命令帮助。那通常意味着调用方式或参数需要核对，不能直接解释成无线芯片不支持 AP。需要看完整命令和具体报错；本次最后执行的 `/usr/sbin/iw dev` 能正常列出接口。

## 六、Wi-Fi 能力、热点建立和 SSH 保活，是三件事

### 6.1 驱动声明支持什么

这块板的实际检查包含：

- `Supported interface modes` 中有 `managed`、`AP`、`AP/VLAN`、`monitor`、`mesh point` 和多种 P2P 模式。

- 存在 `Band 2`，有 5 GHz 频段能力。

- 历史连接曾使用 channel 149（5745 MHz）和 channel 153（5765 MHz），宽度 80 MHz。

- `valid interface combinations` 声明允许 managed 与 AP 的组合，并给出 `total <= 4`、`#channels <= 3` 等限制。

需要复核时，分组执行以下三条只读命令：

```bash

/usr/sbin/iw dev

/usr/sbin/iw list | /usr/bin/grep -A20 ‘Supported interface modes’

/usr/sbin/iw list | /usr/bin/grep -A30 ‘valid interface combinations’

```

检查 5 GHz 可另用 `/usr/sbin/iw list | /usr/bin/grep -A20 ‘Band 2’`。更换驱动或系统后，还要结合频率和信道列表确认，不能永远只依赖 “Band 2” 这个编号。

### 6.2 支持 STA + AP，并不保证启动 LIVI 时 SSH 不断

最初我想当然地把“驱动支持并发”理解成“开热点不影响当前热点连接”。后来对照 LIVI 9.4.0 的 AP 实现，这个推断不成立。

驱动公布的是能力上限；应用实际采用哪种接口管理方式，是另一层逻辑。要让 STA 和 AP 并存，仍需要应用创建或选择合适的接口，并满足信道、固件和管理器的约束。

LIVI 9.4.0 的 Linux AP 流程会管理选定接口。对应源码包含将该接口交出 NetworkManager 管理的动作，以及 AP 服务、hostapd 和 DHCP 的配置逻辑。[7][8]

因此，如果我当前靠 `wlan0` 连接手机热点，并通过它使用 SSH，那么把同一个 `wlan0` 交给 LIVI 建热点，**必须按可能断开调试网络来准备**。不能因为驱动支持 managed + AP，就向用户保证 SSH 一定保留。

### 6.3 `Dedicated Interface=false` 也不是网络保护开关

这是这次源码核对后需要补充的一点。LIVI 9.4.0 的 AP 需求判定同时考虑无线 AA、无线 CarPlay 和专用接口设置；开启无线 AA，本身就足以让 AP 流程成为需要运行的组件。[7]

`Dedicated Interface` 还会影响 AP 服务是否启用为常驻服务等行为。把它保持为 `false`，并不能阻止运行中的无线投屏流程接管所选 Wi-Fi 接口。

这也意味着，“打开一个 LIVI 界面开关”不能被描述成绝对只改用户目录：AP 流程可能安装或使用 `livi-wifi-ap.service`、root 所有的 helper 副本、sudoers 配套规则，并写入 NetworkManager 的接口管理配置。[7][8]

这些是核对源码得到的潜在副作用，**不是本次已经确认全部发生的系统变更**。是否实际创建过，要查设备上的文件和服务状态。

我的操作分工是：首次图形启动和涉及无线接管的配置在 M2 本地桌面完成；SSH 用于只读检查。也可以先验证 eth0 有线 SSH 可用，再把它作为备用管理通道。仅插上网线而没有确认地址与连通性，不算备用通道准备完成。

## 七、最花时间的显示问题：`DISPLAY=:0` 不代表身处桌面会话

### 7.1 表面现象

LIVI 可以打印核心初始化和 Android Auto 显示参数，但不到一秒便退出：

```text

[core] the compositor closed: Ok(ExitStatus(unix_wait_status(25856)))

[core] stopping

```

当时终端里有 `DISPLAY=:0`，所以很容易误以为图形环境已经准备好了。

真正把原因说清楚的，是同一个启动终端中的环境检查：

```text

TYPE=tty

DISPLAY=:0

WAYLAND_DISPLAY=

XDG_RUNTIME_DIR=/run/user/1000

```

随后 `compositor.log` 给出了直接证据：

```text

no outer wayland session: NoCompositor

```

在这次启动路径中，外层 Wayland 会话没有连上。`25856` 是进程 wait status 的显示值，对应退出码 101；真正有诊断价值的仍是后面的具体 panic 原因，而不是单看这个数字。

### 7.2 解决方法与边界

在 M2 HDMI 显示器上的 Wayland 桌面打开 Terminal，在同一个本地桌面终端检查环境并启动：

```bash

/usr/bin/printf ‘TYPE=%s WAYLAND_DISPLAY=%s DISPLAY=%s XDG_RUNTIME_DIR=%s\n’ “$XDG_SESSION_TYPE” “$WAYLAND_DISPLAY” “$DISPLAY” “$XDG_RUNTIME_DIR”

/home/ji/Downloads/LIVI-9.4.0-linux-arm64.AppImage

```

本次成功启动后出现：

```text

[core] compositor display wayland-1 on /dev/dri/renderD128

[core] UI started

```

屏幕上也实际出现了 LIVI 界面。

这里的经验不是“任何 SSH 都不能启动图形程序”，而是：**这次 VS Code Remote-SSH 终端没有获得可用的外层 Wayland 会话，所以失败。** 正确建立授权与环境的远程图形启动属于另一种方案，本次没有采用，也不通过随手伪造环境变量来替代它。

程序启动以后，`iw`、日志、进程和配置检查都可以回到 VS Code 远程终端做。保留本地 LIVI 窗口与启动终端，不要为了“换终端检查”把程序关掉。

## 八、helper 文件可执行，不等于具备所需权限

早期另一个阻断点是 helper 通过 `sudo -n` 启动时需要密码。文件具有执行位，只能说明当前用户可以执行它，不能证明程序能够取得系统管理权限。

本次检查过：

```bash

/usr/bin/stat -c ‘%A %U:%G %n’ /home/ji/.config/LIVI/driver/livi-helperd

/usr/bin/sudo -n -l

```

经单独授权后，只添加了 `/etc/sudoers.d/99-LIVI-helper` 这一项，并通过 `visudo` 校验。随后权限列表出现了针对该 helper 的 `SETENV: NOPASSWD` 授权，helper 也实际以 root 身份运行。

> 这是本次实验中已经发生的权限变更记录，不是让读者复制一条宽泛的免密 root 规则。尤其要注意：这里的 helper 位于用户可写目录，授权它以 root 执行会扩大信任边界。正式部署应审查程序来源、可写父目录、命令范围和环境变量传入方式；只把文件所有者改为 root，而父目录仍可由普通用户替换，也不足以解决问题。

LIVI 的 AP 子系统在此版本中另有 `/usr/local/sbin/livi-helperd` 这样的 root 副本路径。它和用户目录中的 helper、AP 单元与相关授权，是需要分别确认的对象；不能因为其中一个文件存在，就推断所有安装步骤完成。[7]

另一条常见日志是：

```text

[helperd] no local MFi …

```

本次目标是 Android Auto。该日志涉及 CarPlay 的 MFi 检测，不能单独拿它证明 Android Auto 失败，也不能据此要求一定加购认证芯片或投屏盒。[2]

## 九、最明确的阻断点：手机侧开关和 LIVI 侧开关不是同一个

### 9.1 蓝牙已连接的证据是真的，但它只证明了一层

手机已经连接，板端也能查到对应设备：

```bash

/usr/bin/bluetoothctl devices Connected

```

输出中出现安卓手机，并不等于无线 AA 已启用。LIVI 的界面和普通蓝牙状态仍然可以正常工作，而无线 AA 的启动入口处于关闭状态。

当时读取到的配置是：

```json

{

“btAdapter”: “hci0”,

“wifiInterface”: “wlan0”,

“wifiDedicatedInterface”: false,

“wirelessAaEnabled”: false,

“wirelessCpEnabled”: false

}

```

这是原配置的相关字段摘录，**不是完整的配置文件，不应覆盖原有 JSON**。

进一步只读取运行中 helper 的一项参数，结果为：

```text

LIVI_AA_WIRELESS=0

```

保存值与运行时值一致：无线 AA 确实没有启用。这足以解释当时没有进入无线 AA 启动流程，但不意味着其他潜在问题已经全部排除。

### 9.2 源码怎样验证这个判断

核对的是与安装包相同的 `v9.4.0` 标签，而不是直接看后来变化的主分支：

| 上游文件 | 与本次判断有关的行为 |

| — | — |

| `src/main/shared/types/DefaultConfig.ts` | 默认 `wirelessAaEnabled` 为 false |

| `native/livi-helperd/bin/livi-core/src/helper.rs` | 将该配置映射为 `LIVI_AA_WIRELESS` 环境参数 |

| `native/livi-helperd/bin/livi-helperd/src/linux_main.rs` | 按该参数决定是否启用无线 AA 的 TCP 与蓝牙启动逻辑 |

| `native/livi-helperd/crates/livi-runtime/src/bt.rs` | 无线 AA profile 成功注册时打印 `[aa] profile registered` |

因此，`[hfp] HF profile registered`、`[aa] media player registered` 和 `[aa-sock] listening` 都不能替代无线 AA profile 的注册证据。名字里带 “aa”，也可能只是本地通信或媒体对象初始化。[4][5][6]

### 9.3 正确的设置核验方法

LIVI 9.4.0 对应的界面路径为：**Settings → General → Connections → Wireless Android Auto**。蓝牙接口检查为 `hci0`，Wi-Fi 接口检查为实际要交给投屏流程的接口。[9]

界面显示打开后，分别核对三个层次：

1. 配置文件已经是 `true`。

2. 当前 helper 参数已经是 `1`。

3. 新日志出现无线 AA 注册或明确的失败原因，然后继续核对 AP 与手机会话。

只读核验一次三条：

```bash

/usr/bin/grep -oE ‘“wirelessAaEnabled”[[:space:]]*:[[:space:]]*(true|false)’ /home/ji/.config/LIVI/config.json

helper_pid=$(/usr/bin/pgrep -xo livi-helperd); if [ -n “$helper_pid” ]; then /usr/bin/sudo /usr/bin/grep -az ‘^LIVI_AA_WIRELESS=’ “/proc/$helper_pid/environ” | /usr/bin/tr ‘\0’ ‘\n’; else /usr/bin/printf ‘未找到 livi-helperd\n’; fi

/usr/bin/tail -n 100 /home/ji/.config/LIVI/log/LIVI.log

```

第二条使用 sudo，仅为读取 root 进程的一项环境变量，不打印整份环境。多实例场景需要先将 helper PID 与对应 core 对上；`pgrep -xo` 的简写只适合本次单实例排查。

### 9.4 “是不是忘记点 Apply”也不能靠猜

排查时我也想到过：会不会只是打开开关，没有点击应用？核对该版本前端后，需要更准确地说：设置变化会调用保存逻辑；在没有开放投射会话的情况下，核心通常自行应用变更；存在需要重新应用的状态时，界面才会显示相应的 Apply 操作。[10][11]

所以不能把“每次都必须手动点 Apply”当成这个版本的统一规则。如果按钮出现，可以按界面提示操作；如果没有，也不该为了寻找它反复重启。最终以配置值、helper 参数和新日志是否一致为准。

当前的真实进度是：已经发现过 `false / 0`；之后界面开关已打开，手机仍无提示。下一轮需要取得开关打开之后的对应输出，再区分“设置没有应用”和“设置已经应用但后续链路失败”。

## 十、HFP 和音频：看到一个可疑配置，还不能直接删

### 10.1 本次实际读取到的 PipeWire 状态

`/usr/bin/pactl info` 的输出包含：

```text

Server Name: PulseAudio (on PipeWire 1.4.2)

Default Sink: alsa_output.platform-es8389-sound.analog-stereo

Default Source: alsa_input.platform-es8389-sound.analog-stereo

```

命令开头同时有以下提示：

```text

Authorization required, but no authorization protocol specified

xcb_connection_has_error() returned true

```

如果只看前两行，就容易把它理解成“音频服务已经完全不可访问”。但后面已经返回了 PipeWire 服务与默认设备信息，因此这份结果至少证明本次音频服务查询成功。

它仍然不能证明手机媒体音频已经送到 M2，也不能证明扬声器、通话下行和麦克风上行都正常。设备查询成功、板子自己能播声音、手机通过蓝牙传音频，是三个不同测试。

### 10.2 历史角色覆盖配置

本机读到的 `99-livi-hfp.conf` 内容如下：

```ini

monitor.bluez.properties = {

bluez5.roles = [ a2dp_sink a2dp_source ]

}

```

这个覆盖配置只列出了 A2DP 角色，没有列出 HFP 角色，确实值得审查。LIVI 的 README 也说明了无线 AA 启动与 HFP 的关系。[2]

但不能由此立即跳到“删除文件就好了”：同一版本的 helper 自身会尝试注册 HFP HF profile，源码还考虑了 profile 已由音频守护进程持有的情况。[6] 需要结合实际服务记录、连接事件与音频进程的职责，判断配置是否造成缺失或冲突。

**本次对它的结论是：待审查，不是已经确认的最终故障原因。** 发现更直接的 `wirelessAaEnabled=false` 后，应先验证无线入口，再决定是否需要调整角色配置。本文不提供一条“全部恢复默认”的命令去覆盖现有音频设置。

### 10.3 三类日志不能混为一谈

| 日志 / 现象 | 能说明什么 | 还不能说明什么 |

| — | — | — |

| `HF profile registered` | HFP profile 注册调用成功 | 手机已完成 HFP 服务级连接、通话音频已通 |

| `aa-sock listening` | 板端本地 AA IPC 监听已建立 | 安卓手机已经加入 Wi-Fi 或 AA 已授权 |

| `aa media player registered` | 蓝牙媒体对象已注册 | 无线 AA 蓝牙启动 profile 一定启用 |

| 手机蓝牙显示已连接 | 至少有蓝牙连接存在 | 所有需要的 profile 和投屏会话全部可用 |

| M2 或显示屏能播放本地音乐 | 对应本地音频输出链路可用 | 手机音乐已经通过 AA / A2DP 到达该设备 |

## 十一、另外几个值得单独记下的坑

### 11.1 “another livi-core is running”不等于可以删锁

某次启动提示另一个 livi-core 正在运行；后续检查时，进程列表没有 LIVI，Unix socket 监听没有匹配项，`/run/user/1000/livi` 目录也不存在。

这两组观察发生在不同时间。它们不能证明当时一定是残留锁，也不能证明旧实例一定持续存活。可能涉及实例已退出、启动时间窗口或其他单实例检查条件，当前记录不足以定因。

我保留了这项不确定性，没有把清空配置、删除 socket 或强制杀进程写成通用解法。

最小只读核对可以是：

```bash

/usr/bin/pgrep -af ‘livi-core|livi-helperd|livi-compositor’

/usr/bin/ss -lxnp | /usr/bin/grep -E ‘livi|core\.sock’

/usr/bin/ls -la /run/user/1000/livi

```

其中 `ss` 的进程归属信息可能受权限限制；没有显示进程名，不等于 socket 没有监听者。对齐执行时间与用户会话，比只盯一个旧报错有用。

### 11.2 轮转日志是历史，不是实时健康检查

旧的 `LIVI.2.log` 曾记录合成器启动成功，但当前终端又因 `NoCompositor` 失败。这并不矛盾，它们来自不同次启动。

我现在优先对齐：

1. 当前进程是否存在。

2. 日志修改时间是否对应这次启动。

3. 同一次连接尝试之后是否出现新事件。

CarPlay 的监听端口在不同启动之间发生过变化，检查某次旧日志里的动态端口没有占用，不能证明 Android Auto 故障。也没有必要拿 CarPlay 端口替代 AA 会话证据。

### 11.3 系统有 MPP 解码器，不代表 LIVI 已用上硬解

系统侧 `gst-inspect-1.0 mppvideodec` 能找到 Rockchip 插件，`waylandsink` 也存在。但 LIVI 的媒体能力日志仍报告 H.264 为软件可用、硬件未识别：

```text

“h264”:{“hw”:false,“sw”:true}

```

同一份进程记录还显示 LIVI 使用发行包里的 GStreamer 工具路径。系统插件存在和应用实际运行时发现了插件，是不同的检查。

因此，本文没有把“系统有 mppvideodec”写成“导航画面已经硬解”。本轮先完成最小连接与出图；后续再围绕 LIVI 实际媒体运行时、插件兼容性与性能测量开展优化，不直接混用系统和打包运行库。

### 11.4 BLE 名称、经典蓝牙名称和屏幕状态要分开看

旧伴侣应用排查时，控制器名、Alias、BLE 广播 LocalName 曾经不一致。手机系统蓝牙列表与应用内 BLE 扫描，也不是同一个观察入口。

屏幕上的“已连接”还可能来自业务层缓存，不能代替 BlueZ 当前设备状态。对于 LIVI 这条路线，我优先看实际连接的手机、无线入口注册和后续会话，而不靠名称或一处状态文字判断整条链路。

### 11.5 一米距离问题仍然没有结案

之前遇到过“约一米外就断开”的反馈，这次按最小导航验证目标暂时搁置。它没有因为 LIVI 界面跑起来就自动解决。

射频、天线接法、板端控制器和环境需要单独测试。`iw dev` 里的 txpower 属于 Wi-Fi 输出；蓝牙能力字段里的最大支持功率，也不能直接等同于当前实际发射功率。不能拿其中一个数值代替距离测试，更不能在没有新证据时写成“已修复”。

## 十二、关键配置汇总：实际值、目标值、未知项分开写

| 配置项 | 最近一次命令确认 | 最小验证的目标 / 处理原则 |

| — | — | — |

| `wirelessAaEnabled` | false | 目标为 true；界面开启后需重新读取确认 |

| `LIVI_AA_WIRELESS` | 0 | 对应 helper 应为 1 |

| `wirelessCpEnabled` | false | 本轮仅验证安卓，暂不增加 CarPlay 变量 |

| `btAdapter` | hci0 | 与实际蓝牙控制器一致 |

| `wifiInterface` | wlan0 | 只有明确准备交接该接口，或已换好管理通道时再用于 AP |

| `wifiDedicatedInterface` | false | 不保证 STA 并发或 SSH 保留；不要当作接口保护开关 |

| `wifiType / wifiChannel / wifiChannelWidth` | 没有从本次设备配置完整留档 | 按实际无线能力与 AP 日志确认，不把 STA 当前信道当成 AP 设置 |

| `country` | 本次设备值未核验 | 对照实际使用地区与设备支持信道；不直接照搬上游默认值 |

| PipeWire 蓝牙角色覆盖 | A2DP sink/source | 是否调整 HFP，待无线入口与连接证据核对后决定 |

| helper sudoers | 已确认存在特定免密规则 | 不扩大为任意命令免密；正式部署需重新审查信任边界 |

| 图形启动环境 | 本地 Wayland 成功，SSH TTY 路径失败 | 保留成功的启动路径，SSH 用于只读检查 |

上游 9.4.0 默认配置中还可见 5 GHz、信道 36、40 MHz 宽度和 `country=DE` 等值。[3] 这些只是该版本代码的初始值，并不是本机已经验证适用的无线参数。特别是国家码，应按实际使用地区核对；不能为了让 AP 出来就盲目修改监管域。

**建议通过界面修改必要字段，避免拿本文片段覆盖整份 `config.json`。** 原文件可能包含更多显示、音频、无线和设备状态配置。

## 十三、下一轮怎样排查，才能少做无效操作

### 13.1 先保住管理通道

如果要进行会改变无线状态的操作，先使用 M2 本地桌面，或确认备用有线 SSH 已经可用。诊断阶段不停止 NetworkManager，不手动启停系统 hostapd，也不重跑完整安装脚本。

注意两种权限范围：本文列出的查询命令是只读；启用无线投屏、调整接口和运行安装器，则可能改变系统或网络状态，不能混称为“只读检查”。

### 13.2 按结果分支，不再反复问同一个问题

| 新检查结果 | 接下来查什么 |

| — | — |

| 配置 false、helper 0 | 界面变更是否保存、是否查看了同一用户的配置，以及界面是否重新回退 |

| 配置 true、helper 0 | 当前 helper 是否属于旧实例，设置应用是否失败；若界面出现 Apply，按提示处理 |

| 配置 true、helper 1，但 profile 注册失败 | 对应 BlueZ 注册错误及其他服务占用情况 |

| 无线 AA profile 注册成功，但 AP 不存在 | LIVI AP 单元、权限、hostapd 和接口管理错误 |

| AP 已存在，手机未加入 | 手机端实际 Wi-Fi 行为、无线协商日志、SSID 与信道条件 |

| 手机已加入 AP，但没有 AA 会话 | AA 端版本、授权与拒绝记录，以及 helper 的会话日志 |

| AA 车机界面已出现，高德入口缺失 | 目标地图版本的 Android Auto 兼容性；此时不要重新折腾蓝牙驱动 |

手机是否显示 Wi-Fi、是否加入、是否弹出授权，都应由手机现场确认，不能只看 M2 侧推测。必要时记录手机 Android / AA / 高德版本，区分应用版本、ROM 和权限因素。

### 13.3 只有 AP 环节失败，再查 AP 服务

下面是核对上游 9.4.0 实际服务与日志路径后整理的只读检查，不是手动启动服务的命令：[7][8]

```bash

/usr/bin/systemctl show livi-wifi-ap.service -p LoadState -p ActiveState -p SubState

/usr/bin/journalctl -u livi-wifi-ap.service -b --no-pager -n 80

/usr/bin/tail -n 80 /tmp/livi-hostapd.log

```

判断时注意：

- `LoadState=not-found` 与“已经安装但 inactive”不同。

- 日志为空或文件不存在，可能是没有进行过对应尝试，不能一概认定 hostapd 已崩溃。

- journal 或 root 日志可能需要额外读取权限，遇到权限不足要明确记录。

- 先阅读 LIVI 管理的 AP 日志，不另起一套 hostapd / dnsmasq 与它竞争接口。

- 若怀疑信道或频段，不先盲试所有参数；记录当前参数、设备能力与明确报错后，再一次只改一个变量。

### 13.4 手机侧要确认什么

1. 手机 Wi-Fi 与蓝牙均开启，AA 已安装并具备对应设备所需的运行条件。

2. 手机端无线 AA 开关与 LIVI 端无线 AA 开关分别确认。

3. 在系统已配对设备中确认连接的是 M2，而不是同名历史设备。

4. 查看该设备是否存在并启用了通话相关选项；这个界面状态只作为线索，还要结合板端连接日志。

5. 记录有无 AA 授权、拒绝或连接失败提示，必要时查看 AA 的已连接车辆设置。

6. 如果手机自己还在开热点或使用 VPN，先记录这个状态；只有进入相应排查分支，再说明影响后临时测试，不一次关闭所有功能。

清空配对并不是每一步的必选动作。只有怀疑旧授权或服务缓存，并准备好重新确认权限时，再做双方重新配对。

## 十四、怎样才算导航真的打通

我给这次最小可行验证设定以下验收表，空项保留为空，不用 UI 截图代替真实结果：

| 项目 | 通过标准 | 当前结果 |

| — | — | — |

| 程序持续运行 | LIVI 窗口保持，core / compositor / helper 未退出 | 单次启动已验证；长期运行未测 |

| 安卓蓝牙连接 | 板端列表和手机端状态对应同一台手机 | 已验证普通连接 |

| 无线入口开启 | config=true、helper=1，注册成功且无相应失败 | 开关变更后的证据待补 |

| AP 建立 | `iw dev` 显示 AP 接口，SSID 与 LIVI 设置一致 | 最近一次未出现 |

| 手机加入 | 手机实际加入该 AP，板端有对应关联 / 地址记录 | 未验证 |

| AA 启动 | M2 出现 Android Auto 车机界面，手机完成所需连接流程 | 未验证 |

| 地图应用兼容 | AA 应用列表中出现目标地图，能够启动 | 高德版本兼容性待核验 |

| 路线显示 | 真实发起一条路线，地图与导航指引持续更新 | 未验证 |

| 后台行为 | 手机返回桌面、切换前台应用后，M2 仍持续导航 | 未验证 |

| 触控回传 | M2 触摸操作能改变 AA 界面的对应状态 | 未验证 |

| 导航语音 | 实际导航播报进入指定的板端输出设备 | 未验证 |

| 媒体播放 | 手机音源进入指定输出，暂停 / 下一首确实生效 | 未验证 |

| 来电与麦克风 | 来电提示、接听、下行声音与上行语音均由现场验证 | 未验证 |

| 断连恢复 | 记录手机蓝牙 / Wi-Fi 断开后的状态和重新连接过程 | 未系统测试 |

我目前不填帧率、端到端延迟、长时间稳定运行时长等数字，因为还没有完整导航画面，也没有同口径测试数据。等能出图之后，再把它们作为下一阶段的测量任务。

对于高德，还多一道硬门槛：**如果手机里的这个版本不提供可用的 Android Auto 入口，那么 AA 链路连通也不能算高德投屏成功。** 本次没有绕过这一步的私有协议实现，也没有获得可宣称官方适配 M2 的证据。

## 十五、这次踩坑清单，按处理状态整理

| 现象 | 本次得到的结论 | 处理状态 |

| — | — | — |

| `iw` 已安装却提示找不到 | PATH 缺少 `/usr/sbin`，绝对路径可用 | 已定位 |

| 驱动支持 AP，却没有 LIVI 热点 | 硬件能力不能代替应用开关、安装与运行状态 | 尚待开关生效后的检查 |

| 支持 STA + AP，就认为 SSH 不会断 | 应用可能直接接管所选接口；不能只凭驱动声明保证并发 | 已纠正理解，未做并发实测 |

| `Dedicated Interface=false` 被当成网络保护 | 无线 AA 开启仍可触发 AP 流程与接口管理 | 已按源码纠正 |

| `DISPLAY=:0` 却启动就退出 | 当前 SSH 会话缺少可用的外层 Wayland，日志明确 `NoCompositor` | 本地 Wayland 启动已通过 |

| helper 可执行但起不来 | 早期免密权限缺失；定向授权后已实际运行 | 已通过启动验证；正式部署权限仍需审查 |

| MFi 缺失被当成 AA 原因 | 日志针对 CarPlay 路径，不能直接推断 AA | 已区分 |

| 蓝牙连接成功，手机无 AA 提示 | 曾明确核验 LIVI 无线 AA 配置与运行时均关闭 | 找到阻断点；开启后的链路仍待验证 |

| 界面开关打开，就当作已经生效 | 必须同时看保存值、helper 参数与新日志 | 下一轮重点 |

| 怀疑 A2DP-only 配置就准备删除 | 需结合 LIVI 自有 HFP 实现与音频服务职责判断 | 保留待审查 |

| `pactl` 有图形授权警告 | 本次仍查询到 PipeWire；不能仅凭首行认定音频服务不可用 | 查询已通过，实际音频未验收 |

| 系统存在 MPP 插件，就宣称 AA 硬解 | LIVI 当前探测仍为 H.264 软件可用 | 硬解优化未开展 |

| 重复启动提示已有 core | 不同时间的进程与日志不能证明残留锁根因 | 未擅自清缓存或删锁 |

| 超过约一米断开 | 尚未完成射频、天线与距离专项复核 | 未解决，不作为本次成果 |

## 十六、结语：先把每一层的成功标准写清楚

这次 M2 导航互联最有价值的部分，是把“看起来已经连接”的状态拆开了：普通蓝牙、无线 AA 入口、Wi-Fi AP、投射会话、地图应用和音频，每一层都有独立证据。

目前真正完成的是：依赖和路径问题被厘清，helper 能启动，LIVI 在本地 Wayland 桌面正常显示，安卓普通蓝牙连接可核验，并找到了无线 AA 曾被关闭这一明确阻断点。接下来要补的是界面变更之后的新证据，再向热点、AA 会话和高德兼容性逐步推进。

感谢移远产品体验官计划提供这次动手验证的机会。后续如果完成真实导航、触控和音频验收，我会按同一份表补充日志和实机画面；在此之前，这篇帖子保持为阶段性实战与排障记录。

-–

## 参考资料与源码定位

本文中的设备状态来自本次调试终端记录；下面的公共资料用于解释软件行为。源码均固定到 `v9.4.0`，不是对任何后续版本的承诺。

1. [移远 Quectel Pi M2 官方资料入口](M2 | 移远通信-全球物联网整体解决方案供应商)。

2. [LIVI v9.4.0 README：无线连接、运行依赖和 MFi 边界](LIVI/README.md at v9.4.0 · f-io/LIVI · GitHub)。

3. [默认配置：DefaultConfig.ts](LIVI/src/main/shared/types/DefaultConfig.ts at v9.4.0 · f-io/LIVI · GitHub)。

4. [核心向 helper 传递配置：helper.rs](LIVI/native/livi-helperd/bin/livi-core/src/helper.rs at v9.4.0 · f-io/LIVI · GitHub)。

5. [Linux helper 的无线 AA 启动分支：linux_main.rs](LIVI/native/livi-helperd/bin/livi-helperd/src/linux_main.rs at v9.4.0 · f-io/LIVI · GitHub)。

6. [蓝牙 AA 与 HFP 注册逻辑：bt.rs](LIVI/native/livi-helperd/crates/livi-runtime/src/bt.rs at v9.4.0 · f-io/LIVI · GitHub)。

7. [核心 AP 状态协调与服务管理：wifi_ap.rs](LIVI/native/livi-helperd/bin/livi-core/src/wifi_ap.rs at v9.4.0 · f-io/LIVI · GitHub)。

8. [AP 运行时、接口交接与日志路径：wifi_ap.rs](LIVI/native/livi-helperd/crates/livi-runtime/src/wifi_ap.rs at v9.4.0 · f-io/LIVI · GitHub)。

9. [设置页面字段与 Connections 路径：generalSchema.ts](LIVI/src/renderer/src/routes/schemas/generalSchema.ts at v9.4.0 · f-io/LIVI · GitHub)。

10. [设置保存与重新应用行为：useSmartSettings.ts](LIVI/src/renderer/src/components/pages/settings/hooks/useSmartSettings.ts at v9.4.0 · f-io/LIVI · GitHub)。

11. [Apply 按钮的显示组件：SettingsLayout.tsx](LIVI/src/renderer/src/components/layouts/SettingsLayout.tsx at v9.4.0 · f-io/LIVI · GitHub)。

12. [LIVI v9.4.0 官方发行页](Release v9.4.0 (2026-10-11) · f-io/LIVI · GitHub)：本次核对到 ARM64 AppImage 资产名与测试文件一致。

13. [移远论坛：M2 的 BLE 伴侣应用调试记录](Quectel Pi M2 实战：用 BLE 打通手机互联，从搜不到到只有一米)。该路线用于理解早期工程边界，不作为本次 AA 投屏成功的证明。还差哪几步？**

> 体验平台：Quectel Pi M2（RK3576），Debian 13.7 / aarch64。

> 接收端：LIVI 9.4.0 Linux ARM64 AppImage。

> 记录日期：2026-10-25。

> 当前阶段：LIVI 图形界面、helper 与普通蓝牙连接已验证；Android Auto 导航画面尚未完成现场验收。

我参与移远产品体验官计划后，一直想把 M2 和安卓手机连起来：消息能在小屏幕上看，音乐能控制，来电能提示，导航也能放到板子连接的显示屏上。最开始做的是 BLE 伴侣应用，后来需求逐渐明确——我想要的是手机负责导航计算，M2 负责显示和交互，体验接近车载中控。

真正开始调试后，最让人困惑的并不是某条复杂协议，而是一个很日常的现象：手机显示蓝牙已连接，M2 屏幕也显示已连接，手机却始终没有 Android Auto 的连接或授权提示。

这篇记录围绕这个问题展开。已经拿到证据的部分写清楚；只有猜测的地方保留为排查项。LIVI 的界面跑起来，不等于 Android Auto 已经连接；普通蓝牙配对成功，也不等于导航画面正在传输。

## 一、先把当前进度摆出来

| 环节 | 当前结果 | 证据或限制 |

| — | — | — |

| M2 系统与架构 | 已确认 | Debian 13.7，aarch64 |

| 蓝牙硬件与 BlueZ | 已确认可用 | `hci0` 已上电，手机实际出现在已连接设备列表 |

| Wi-Fi AP 与 5 GHz 能力 | 驱动声明支持 | `iw list` 包含 AP、Band 2 与 managed + AP 并发组合 |

| LIVI 图形界面 | 已跑通 | 本地 Wayland 桌面启动，日志出现 `UI started` |

| LIVI 特权 helper | 已跑通启动 | 进程以 root 运行，已出现蓝牙 profile 和本地 socket 初始化日志 |

| 无线 Android Auto 开关 | 找到过明确阻断点 | 最近一次命令核验为 `wirelessAaEnabled=false`、`LIVI_AA_WIRELESS=0` |

| 界面开启后的设置生效情况 | 尚缺新证据 | 后续界面已打开开关，但尚未取得对应的新配置、helper 环境和握手日志 |

| LIVI Wi-Fi AP | 最近一次检查未建立 | 只看到 `wlan0` 为 managed，仍连接调试用手机热点 |

| Android Auto 授权与会话 | 未完成 | 安卓手机尚未弹出连接或授权提示 |

| 高德实际导航画面 | 未验收 | 尚未确认当前手机高德版本在 Android Auto 应用列表中可用 |

| 后台导航、触控、音乐和通话闭环 | 未验收 | 必须在会话建立后逐项测试 |

这里有一个时间顺序需要特别说明：`false / 0` 是最后一次通过命令确认的状态；随后界面开关已经打开，但没有新的运行时输出。因此，不能把旧值当成永久现状，也不能只凭界面开关就宣布整条链路恢复。

## 二、导航需求是怎样从“传几个字段”变成“接收车机画面”的

### 2.1 最初的 BLE 方案做了什么

早期伴侣应用的思路，是让安卓手机把通知、媒体状态、来电状态和导航摘要通过自定义 BLE GATT 服务发给 M2，板端再用自己的界面显示。反向控制也走自定义命令，例如下一首、暂停等。

它适合传递“前方右转、剩余距离、预计到达时间”这样的结构化信息。就算进一步分片传递了路线折线，板端拿到的仍然是数据，需要自己实现地图底图、坐标转换、缩放与路线绘制。

这里最容易误解的一点是：**收到一条导航 JSON，和显示高德完整地图，是两种不同的能力。** 自定义 BLE 服务不会因为已经能传通知，就自动拥有地图画面、媒体音频和通话音频。

历史工程记录中涉及 `agent/drivers/ble_gatt.py`、`ble_protocol.py`、`bluetooth.py`，以及手机端的 `M2LinkService.kt`、`BleProtocol.kt`。这些文件名用于区分旧伴侣应用的职责，本次整理没有重新审计它们在板端的最新版本，因此不把历史功能描述当作当前代码全部通过的证明。

### 2.2 为什么最终选择 LIVI + 无线 Android Auto

我的需求后来收敛成三件事：

1. 导航计算和地图应用仍放在安卓手机上，不在 M2 上另写地图引擎。

2. M2 连接显示器，作为接收、显示和交互终端。

3. 先打通最小链路，再谈音乐、通话、后台运行和产品化。

几种路线的边界如下：

| — | — | — | — |

本次没有接入高德地图 API，也没有在 M2 上实现路线规划。LIVI 是第三方 Android Auto 接收程序，我做的是 M2 上的集成与排障。

**手机安装了 Android Auto，并不能证明当前手机里的高德版本一定支持 Android Auto。** 这要在 AA 连接成功后查看实际应用列表，并启动导航确认。到目前为止，这一步还没走完。

### 2.3 两个原始要求，需要分别验收

“手机导航画面和 M2 一模一样”属于屏幕镜像要求；“手机切到别的应用，M2 继续独立显示导航”更接近车机投射要求。本文选择后者，因此接受 Android Auto 的车机界面形态。

手机按 Home 回到桌面、切换其他应用、系统回收进程、用户强行停止地图，分别是不同状态。后续必须实测，不能用一句“支持后台”把它们混在一起。

## 三、先理解整条链路，才知道应该查哪里

```text

安卓手机 Quectel Pi M2

Android Auto + 兼容的导航应用 LIVI 9.4.0

      │                                  │

      ├──── 蓝牙发现、配对与无线启动协商 ──┤

      │                                  │

      ├──── 加入 M2/LIVI 提供的 Wi-Fi ────┤

      │                                  │

      ├──── Android Auto 会话与画面传输 ──┤

      │                                  ├── LIVI compositor / UI

      │                                  └── M2 显示器

      └──── 触控、媒体和通话等能力：分别验收