企业官网建设流程全解析

1. 问题背景与核心难点拆解

两台 Android 开发板烧录了同一份镜像，硬件序列号一模一样，插上 USB 之后adb devices列出来的两行都是同一个序列号，adb -s <serial>根本没法区分到底连的是哪一台。这个场景在批量生产、产线测试、多板卡联调的时候特别常见，尤其是用同一批核心板、同一份量产镜像的开发板，序列号往往来自镜像里写死的ro.serialno或者芯片 efuse 没烧录唯一 ID，导致系统读出来的值完全一致。

我最早遇到这个问题是在一个多板卡并行测试的项目里，四块开发板同时插在一台 Ubuntu 主机上，adb devices输出四行一模一样的序列号，当时第一反应是用adb -s指定，结果发现指定了也没用，因为 ADB 自己都分不清哪个序列号对应哪个物理设备。后来才搞清楚，ADB 内部其实有一个比序列号更底层的标识——transport_id，它是在 ADB 建立连接时由主机端分配的，跟物理 USB 端口绑定，跟设备上报的序列号无关。这就是解决这个问题的关键切入点。

这个问题的本质是：ADB 的设备寻址机制有两层，一层是设备自报的序列号（ro.serialno），另一层是主机端分配的 transport_id。当序列号冲突时，必须绕过序列号，直接用 transport_id 来寻址。很多人只知道adb -s，不知道adb -t，所以卡在这里。

适合阅读这篇内容的人包括：做 Android 开发板批量测试的工程师、产线烧录和校准的技术人员、同时调试多块开发板的嵌入式开发者，以及任何遇到 ADB 设备序列号冲突的人。下面我会从原理讲到实操，把transport_id的用法、USB 端口绑定、udev 规则、以及几种不同场景下的解决方案全部拆开讲清楚。

2. ADB 设备寻址机制原理解析

2.1 序列号是怎么来的，为什么会重复

Android 设备上报给 ADB 的序列号，来源有几个层次。最底层是芯片的 efuse 或者 OTP 区域里烧录的唯一 ID，但这个不是所有芯片都有，很多国产开发板用的 SoC 根本没有烧录唯一 ID，或者出厂时是空的。往上一层是 bootloader 传递的androidboot.serialno参数，再往上是系统属性ro.serialno，这个属性通常在build.prop或者system.prop里写死。如果镜像里ro.serialno是一个固定值，比如0123456789ABCDEF，那么所有烧了这份镜像的板子序列号都一样。

ADB 在设备端有一个 daemon（adbd），它启动的时候会读取ro.serialno，然后通过 USB 或者 TCP 连接把序列号上报给主机端的 ADB server。主机端 ADB server 收到之后，就把它作为设备的唯一标识。问题就在于，如果两个设备上报的序列号相同，ADB server 就认为它们是同一个设备，或者至少在用-s参数时无法区分。

注意：有些开发板的序列号是从 CPUID 或者芯片唯一 ID 动态生成的，这种一般不会重复。重复的情况基本都出现在镜像里写死了ro.serialno，或者芯片本身没有唯一 ID 且系统用了默认值。

2.2 transport_id 是什么，为什么它能区分设备

transport_id是 ADB 主机端（也就是你电脑上的 adb server）在每次建立连接时分配的一个递增整数。它的分配逻辑跟设备上报的序列号无关，而是跟连接本身绑定。每当你插上一块开发板，ADB server 检测到一个新的 USB 设备或者新的 TCP 连接，就会创建一个 transport，分配一个唯一的 transport_id。这个 ID 从 1 开始递增，在当前 adb server 进程的生命周期内不会重复。

关键点在于：transport_id 是主机端分配的，不是设备端上报的。所以即使两台设备序列号相同，它们各自建立连接时会得到不同的 transport_id。你可以用adb devices -l看到每个设备对应的 transport_id，然后用adb -t <transport_id>来指定操作哪一台。

这个机制在 ADB 的源码里对应的是transport.cpp和adb.cpp里的逻辑，transport_id 在atransport结构体里维护，每次handle_new_device或者handle_packet建立新连接时分配。它不是持久化的，adb server 重启之后会重新分配，所以不能把 transport_id 写死在脚本里，必须动态获取。

2.3 为什么 adb -s 在序列号冲突时失效

adb -s <serial>的工作方式是：ADB 客户端把序列号发给 adb server，server 在设备列表里查找匹配的序列号。如果两个设备的序列号相同，server 找到第一个匹配的就返回，或者直接报错说多个设备匹配。具体行为取决于 ADB 版本，新版本会报more than one device/emulator，老版本可能随机选一个。

所以-s在序列号冲突时是不可靠的。你必须用-t来指定 transport_id，因为 transport_id 是唯一的。adb -t <id> shell会直接定位到那个 transport，不经过序列号匹配。

提示：adb -t这个参数在 ADB 1.0.36 之后的版本才支持，比较老的 ADB 可能没有。你可以用adb version看一下版本号，建议用 1.0.41 以上的版本。

3. 实操方案：用 transport_id 精确连接指定开发板

3.1 获取 transport_id 的完整步骤

第一步，把两台开发板都插上电脑，确保 USB 调试已经打开，驱动正常。然后在终端执行：

adb devices -l

输出大概长这样：

List of devices attached 0123456789ABCDEF device product:rk3399 model:rk3399 board:rk3399 transport_id:1 0123456789ABCDEF device product:rk3399 model:rk3399 board:rk3399 transport_id:2

可以看到两行序列号完全一样，但 transport_id 分别是 1 和 2。这就是区分它们的关键。

如果你用的是 Windows，命令一样，输出格式略有不同，但 transport_id 字段是一样的。如果输出里没有 transport_id，说明你的 ADB 版本太老，需要升级。

第二步，用 transport_id 执行命令：

adb -t 1 shell adb -t 2 shell

这样就能分别进入两台开发板的 shell，互不干扰。

3.2 如何确定哪个 transport_id 对应哪块物理板子

transport_id 是动态分配的，每次插拔或者 adb server 重启都可能变。所以你不能记住“1 号板子是左边那块”，必须每次重新确认。确认的方法有几种：

第一种，用 USB 端口路径来区分。在 Linux 下，执行：

ls -l /sys/bus/usb/devices/

或者用udevadm info查看每个 USB 设备的物理路径。每个 USB 端口在系统里有固定的路径，比如1-1.2和1-1.3，对应不同的物理端口。你可以把开发板插到固定的 USB 口上，然后通过端口路径来映射 transport_id。

具体操作是：先只插一块板子，执行adb devices -l记下 transport_id，然后拔掉，插另一块，再记下 transport_id。反复几次就能确定每个 USB 口对应的 transport_id 分配规律。但这个方法比较笨，而且 adb server 重启后可能变。

第二种，用adb -t <id> shell getprop ro.serialno来确认，但序列号一样，确认不了。可以改用adb -t <id> shell cat /sys/class/net/wlan0/address或者读其他唯一标识，比如 WiFi MAC 地址、CPU ID 等。如果开发板的 MAC 地址不同，就可以用这个来区分。

第三种，最可靠的方法：给每块板子分配不同的 USB 端口，然后用 udev 规则给每个端口绑定一个固定的符号链接，再通过符号链接来识别。这个后面会详细讲。

3.3 批量操作时如何动态获取 transport_id

在脚本里，你不能硬编码 transport_id，必须动态解析。下面是一个 bash 脚本示例，可以遍历所有设备并分别执行命令：

#!/bin/bash # 获取所有设备的 transport_id adb devices -l | grep -v "List of devices" | while read line; do if [ -n "$line" ]; then tid=$(echo "$line" | grep -oP 'transport_id:\K[0-9]+') if [ -n "$tid" ]; then echo "Operating on transport_id: $tid" adb -t "$tid" shell getprop ro.product.model fi fi done

这个脚本会依次对每个 transport_id 执行getprop，你可以把getprop换成任何你想执行的命令。

如果你用 Python，可以用subprocess调用 adb，然后解析输出：

import subprocess import re output = subprocess.check_output(['adb', 'devices', '-l']).decode() for line in output.splitlines(): match = re.search(r'transport_id:(\d+)', line) if match: tid = match.group(1) print(f"Transport ID: {tid}") result = subprocess.check_output(['adb', '-t', tid, 'shell', 'getprop', 'ro.product.model']) print(result.decode().strip())

这样就能在自动化脚本里精确控制每一块板子。

4. 进阶方案：用 USB 端口绑定和 udev 规则固定设备标识

4.1 为什么需要固定标识

transport_id 是动态的，每次 adb server 重启或者插拔顺序变化，ID 都可能变。如果你在产线上要反复测试，每次都要重新确认 transport_id，效率很低，而且容易出错。更好的做法是让每块板子在系统里有固定的标识，比如固定的设备节点路径或者固定的符号链接。

Linux 的 udev 机制可以根据 USB 设备的物理端口路径、厂商 ID、产品 ID 等属性，创建固定的符号链接。这样不管 adb server 怎么重启，你都能通过符号链接找到对应的板子。

4.2 编写 udev 规则绑定 USB 端口

首先，你需要确定每块板子插在哪个 USB 端口上。执行：

udevadm info -a -n /dev/bus/usb/001/002

把/dev/bus/usb/001/002换成你实际的设备节点。输出里会包含KERNELS、SUBSYSTEMS、ATTRS等信息，找到KERNELS=="1-1.2"这样的物理端口路径。

然后创建 udev 规则文件，比如/etc/udev/rules.d/99-android-boards.rules：

SUBSYSTEM=="usb", KERNELS=="1-1.2", SYMLINK+="android_board_1" SUBSYSTEM=="usb", KERNELS=="1-1.3", SYMLINK+="android_board_2"

保存后重新加载 udev 规则：

sudo udevadm control --reload-rules sudo udevadm trigger

这样/dev/android_board_1和/dev/android_board_2就会分别指向两块板子。但 ADB 本身不直接使用这个符号链接，它还是通过 USB 总线枚举设备。所以这个符号链接主要是给你自己参考，或者配合其他工具使用。

4.3 结合 adb 的 ANDROID_SERIAL 环境变量

ADB 支持一个环境变量ANDROID_SERIAL，可以指定默认的设备序列号。但序列号冲突时这个也没用。不过你可以结合 transport_id 来用：

export ANDROID_SERIAL=0123456789ABCDEF adb -t 1 shell

这样-t的优先级高于ANDROID_SERIAL，所以还是能精确指定。

另一个思路是：如果你能让每块板子的序列号不同，问题就从根本上解决了。修改序列号的方法取决于开发板，有些可以通过adb shell setprop ro.serialno动态改，但ro.开头的属性是只读的，改不了。有些可以在 bootloader 里改androidboot.serialno参数，或者修改镜像里的build.prop。如果开发板支持，最彻底的办法是给每块板子烧录不同的序列号。

注意：修改ro.serialno需要重新打包镜像或者修改 bootloader 参数，操作有风险，搞不好板子起不来。建议先在测试板上验证。

5. 常见问题与排查技巧实录

5.1 adb devices 只显示一个设备怎么办

有时候两台板子插上，adb devices只显示一行。这通常是因为 ADB server 把两个设备当成同一个了，或者 USB 枚举有问题。排查步骤：

第一，执行adb kill-server然后adb start-server，重新枚举。第二，检查 USB 线是否支持数据传输，有些线只能充电。第三，检查开发板的 USB 调试是否真的打开了，有些板子默认关闭。第四，在 Linux 下用lsusb看是否两个设备都识别到了。如果lsusb能看到两个，但adb devices只有一个，那可能是 adbd 的问题，尝试重启 adbd：adb -t <id> shell stop adbd; adb -t <id> shell start adbd。

5.2 transport_id 每次都不一样，脚本怎么写

transport_id 动态变化是正常的，脚本里不要硬编码，而是每次运行时动态获取。可以用前面给的 bash 或 Python 脚本。如果你需要区分具体的板子，可以结合 USB 端口路径来映射。比如先通过udevadm获取每个端口的设备节点，再通过adb devices -l获取 transport_id，然后建立映射关系。

一个实用的技巧是：在脚本里先只插一块板子，获取它的 transport_id 和某个唯一标识（比如 MAC 地址），记录下来。然后插第二块，再获取。这样就能建立“物理板子 -> 唯一标识 -> transport_id”的映射。

5.3 adb -t 报错 "unknown transport id" 怎么解决

这个错误通常是因为 transport_id 已经失效了。比如你之前记下的 ID 是 1，但 adb server 重启后重新分配了，原来的 1 可能已经不存在了。解决办法就是重新执行adb devices -l获取最新的 transport_id。

另外，如果你同时用了-s和-t，ADB 可能会报错。-t和-s不能同时用，-t的优先级更高，但有些版本会直接报冲突。建议只用-t。

5.4 常见问题速查表

5.5 实操心得与避坑技巧

第一个坑：不要依赖adb devices的输出顺序。有些人觉得第一行就是第一块板子，第二行就是第二块，但实际上顺序可能跟插拔顺序、USB 端口有关，不稳定。一定要用 transport_id 或者唯一标识来区分。

第二个坑：adb -t在有些 ADB 版本里不支持，尤其是 Windows 上一些老版本的 adb.exe。建议用 Android SDK Platform Tools 里的最新版 ADB，或者用 Linux 下包管理器安装的android-tools-adb。

第三个坑：如果你用adb over WiFi，transport_id 的分配逻辑跟 USB 不同，但同样可以用-t指定。WiFi 连接时，IP 地址和端口可以作为区分依据，但序列号冲突时还是得用 transport_id。

第四个坑：在产线批量测试时，建议给每个 USB 端口编号，物理上固定板子位置，然后通过 udev 规则和脚本自动映射 transport_id。这样可以避免人工确认，提高效率。

第五个坑：如果开发板支持，最好还是修改序列号，让每块板子有唯一标识。这是最根本的解决办法。修改方法因板而异，常见的是修改build.prop里的ro.serialno，或者在内核 cmdline 里加androidboot.serialno=xxx。具体操作需要参考开发板的文档。

6. 多板卡并行测试的自动化脚本实战

6.1 脚本设计思路

在多板卡并行测试场景里，你需要同时对多块板子执行相同的操作，比如安装 APK、抓取日志、执行测试用例。脚本的核心逻辑是：先获取所有 transport_id，然后对每个 ID 并行执行命令。并行可以用 bash 的&后台执行，或者用 Python 的concurrent.futures。

下面是一个 bash 并行脚本示例：

#!/bin/bash # 并行对每个设备执行命令 adb devices -l | grep -oP 'transport_id:\K[0-9]+' | while read tid; do ( echo "=== Device transport_id: $tid ===" adb -t "$tid" shell getprop ro.product.model adb -t "$tid" shell getprop ro.build.version.release adb -t "$tid" logcat -d -t 100 > "log_${tid}.txt" ) & done wait echo "All devices done."

这个脚本会并行抓取每个设备的型号、系统版本和最近 100 行日志，分别保存到不同文件。

6.2 用 Python 实现更复杂的并行控制

Python 的concurrent.futures可以更方便地控制并发数和错误处理：

import subprocess import re from concurrent.futures import ThreadPoolExecutor def get_transport_ids(): output = subprocess.check_output(['adb', 'devices', '-l']).decode() return re.findall(r'transport_id:(\d+)', output) def run_on_device(tid, command): try: result = subprocess.check_output( ['adb', '-t', tid] + command, stderr=subprocess.STDOUT, timeout=30 ) return tid, result.decode() except subprocess.CalledProcessError as e: return tid, f"Error: {e.output.decode()}" except subprocess.TimeoutExpired: return tid, "Timeout" def main(): tids = get_transport_ids() print(f"Found {len(tids)} devices: {tids}") with ThreadPoolExecutor(max_workers=len(tids)) as executor: futures = [] for tid in tids: futures.append(executor.submit(run_on_device, tid, ['shell', 'getprop', 'ro.product.model'])) for future in futures: tid, result = future.result() print(f"Device {tid}: {result.strip()}") if __name__ == '__main__': main()

这个脚本会并发获取每个设备的型号，超时时间 30 秒，出错会捕获异常。

6.3 日志抓取和文件拉取的注意事项

多设备并行抓日志时，注意每个设备的日志文件要分开保存，文件名里带上 transport_id 或者时间戳。拉取文件时，用adb -t <id> pull指定设备，避免混淆。

另外，adb logcat默认会阻塞，抓取时建议用-d参数只 dump 当前日志然后退出，或者用-t <count>指定行数。如果要持续抓取，可以用timeout命令限制时间：

timeout 10 adb -t 1 logcat > log_1.txt

这样 10 秒后自动停止。

提示：并行操作时，USB 带宽可能成为瓶颈，尤其是同时拉取大文件时。建议控制并发数，或者用 USB 3.0 集线器。

7. 从根源解决：修改开发板序列号的可行方案

7.1 修改 build.prop 里的 ro.serialno

如果开发板的系统是 Android，ro.serialno通常在/system/build.prop或者/vendor/build.prop里定义。你可以用adb -t <id> shell getprop ro.serialno确认当前值，然后修改镜像里的对应文件。具体步骤：

第一步，把开发板的 system 分区镜像挂载到 Linux 主机上。第二步，编辑build.prop，把ro.serialno=0123456789ABCDEF改成唯一值。第三步，重新打包镜像并烧录。这个方法需要重新烧录，适合产线批量操作。

但要注意，ro.属性是只读的，系统启动后无法修改。而且有些开发板的ro.serialno是从 bootloader 参数动态生成的，改build.prop可能不生效。

7.2 通过内核 cmdline 传递 androidboot.serialno

在 bootloader 里，可以通过内核 cmdline 传递androidboot.serialno=xxx参数。这个参数会被 init 进程读取，并设置ro.serialno。修改方法取决于 bootloader 类型，比如 U-Boot 可以修改bootargs环境变量。

具体操作：进入 U-Boot 命令行，执行setenv bootargs ${bootargs} androidboot.serialno=UNIQUE123，然后saveenv保存。重启后ro.serialno就会变成UNIQUE123。这个方法不需要重新烧录系统镜像，但需要串口或者调试口进入 bootloader。

7.3 用芯片唯一 ID 动态生成序列号

有些开发板的 SoC 有唯一 ID，比如 Rockchip 的 CPUID、Allwinner 的 chipid。可以在 init 脚本里读取这个 ID，然后设置ro.serialno。比如在init.rc里加：

on early-init write /proc/sys/kernel/hotplug "" exec - root -- /system/bin/set_serialno.sh

set_serialno.sh脚本读取/proc/cpuinfo里的 Serial 字段，然后setprop ro.serialno $SERIAL。但ro.属性在 early-init 之后就不能改了，所以要在合适的时机设置。

这个方法需要一定的系统定制能力，适合有源码的开发板。

7.4 方案对比与选择建议

如果只是临时调试，用 transport_id 最快。如果是产线长期使用，建议从根源修改序列号。

8. 跨平台注意事项与工具链适配

8.1 Windows 下的 transport_id 使用

Windows 下 ADB 的用法跟 Linux 基本一样，adb devices -l也会显示 transport_id。但 Windows 的 USB 设备管理跟 Linux 不同，没有 udev 机制，所以不能通过符号链接固定设备。Windows 下可以用 USB 端口号来区分，在设备管理器里查看每个开发板连接的端口。

另外，Windows 下如果装了多个 ADB 版本，可能会冲突。建议统一用 Android SDK Platform Tools 里的 ADB，把路径加到系统环境变量里。

8.2 macOS 下的注意事项

macOS 下 ADB 用法一样，但 macOS 对 USB 设备的权限管理比较严格。如果遇到权限问题，可能需要安装额外的驱动或者用sudo运行。不过一般 Android 开发板在 macOS 下免驱，直接能用。

macOS 下也可以用system_profiler SPUSBDataType查看 USB 设备树，确认每个板子的端口位置。

8.3 Linux 下的 udev 规则和权限

Linux 下最常见的问题是权限不足，adb devices显示no permissions。解决办法是添加 udev 规则：

SUBSYSTEM=="usb", ATTR{idVendor}=="2207", MODE="0666", GROUP="plugdev"

idVendor根据开发板的厂商 ID 填写，可以用lsusb查看。保存到/etc/udev/rules.d/51-android.rules，然后重新加载规则。

另外，Linux 下如果同时插多块板子，USB 供电可能不足，建议用带外部供电的 USB 集线器。

8.4 ADB 版本兼容性

不同版本的 ADB 对 transport_id 的支持程度不同。建议用 1.0.41 以上的版本。可以用adb version查看，如果太老，去 Android 开发者官网下载最新的 Platform Tools。

另外，设备端的 adbd 版本也会影响，但一般主机端 ADB 兼容性更好，建议保持主机端最新。

9. 实战案例：四块同序列号开发板并行烧录与测试

9.1 场景描述

我之前做过一个项目，四块 RK3399 开发板烧了同一份镜像，序列号都是0123456789ABCDEF。需要同时给四块板子安装测试 APK、运行自动化测试、抓取日志。主机是 Ubuntu 18.04，用了一个带供电的 USB 3.0 集线器。

9.2 操作步骤

第一步，插上四块板子，执行adb devices -l，确认四行输出，transport_id 分别是 1、2、3、4。

第二步，写一个 bash 脚本，并行安装 APK：

#!/bin/bash APK_PATH="./test.apk" adb devices -l | grep -oP 'transport_id:\K[0-9]+' | while read tid; do ( echo "Installing on transport_id: $tid" adb -t "$tid" install -r "$APK_PATH" adb -t "$tid" shell am start -n com.example.test/.MainActivity ) & done wait echo "Installation and launch completed."

第三步，并行抓取日志：

#!/bin/bash adb devices -l | grep -oP 'transport_id:\K[0-9]+' | while read tid; do ( timeout 30 adb -t "$tid" logcat -d > "log_${tid}.txt" ) & done wait echo "Logs captured."

第四步，测试完成后，用adb -t <id> pull /sdcard/test_result.txt分别拉取结果文件。

9.3 遇到的问题和解决

问题一：四块板子同时插上时，有一块偶尔识别不到。排查发现是 USB 集线器供电不足，换了一个带 12V 供电的集线器后解决。

问题二：并行安装 APK 时，有时会报INSTALL_FAILED_INSUFFICIENT_STORAGE，因为四块板子同时安装，存储 IO 压力大。解决办法是加延时，或者分批安装。

问题三：transport_id 在 adb server 重启后变了，脚本里硬编码的 ID 失效。后来改成动态获取，问题解决。

9.4 效率提升对比

手动一块一块操作，四块板子安装加测试大概需要 20 分钟。用并行脚本后，缩短到 6 分钟左右，效率提升三倍多。而且脚本可以重复使用，不用每次重新确认设备。

10. 个人经验总结与后续扩展方向

踩过几次坑之后，我现在的习惯是：只要遇到多设备调试，第一件事就是adb devices -l看 transport_id，而不是看序列号。序列号冲突在开发板场景里太常见了，尤其是批量烧录的板子。transport_id 虽然每次会变，但配合脚本动态获取，完全不影响自动化。

另外，如果项目长期需要多板卡测试，建议花时间搞定序列号唯一化。不管是改 build.prop 还是用芯片 ID 动态生成，一劳永逸。transport_id 方案适合临时调试和快速验证，长期产线还是唯一序列号更靠谱。

后续如果要做更复杂的多设备管理，可以考虑用adb connect走网络调试，每块板子分配不同 IP，这样序列号冲突就不影响了。或者用一些开源的设备管理工具，比如openstf（现在叫 DeviceFarmer），它支持多设备管理和远程调试，底层也是用 transport_id 来区分设备。

最后分享一个小技巧：如果你在 Linux 下用 udev 规则固定了 USB 端口，可以写一个脚本，根据端口路径自动映射 transport_id，这样每次插拔后自动更新映射表，不用手动确认。具体做法是结合udevadm monitor和adb devices -l的输出，写一个守护脚本。这个我下次再展开讲。