简介面向 Android 设备串口通讯开发与调试的实战项目适合具备 Android 基础、希望打通应用与硬件数据交互的开发者可服务物联网、自动化控制及嵌入式终端等场景。压缩包共 851 个文件、约 19.59MB含 26 个 Java 源码、15 个 jar、9 个 so 与 SerialPort.c 等原生实现另有 291 个 xml 配置、264 个 png 素材、131 个 json 资源及可直接安装的 app-debug.apk并保留 gradle 工程配置。已有 3452 人学习下载。读者可对照源码梳理串口打开、参数配置、读写、异常处理与资源释放流程借 apk 验证设备连通性再排查波特率、串口路径和权限问题快速搭建可运行样例。1. 从一块开发板说起Android 串口通讯最难的不是写代码某开发者把一块 Android 工控板摆在桌上板子引出四路/dev/ttyS*外设是一台称重传感器。App 装上去了open()直接返回 EACCES一晚上时间就没了。这类场景里Android 串口通讯真正的难点从来不是那几十行 Java 代码而是三件事设备节点归谁所有、SELinux 让不让过、以及在 Android Studio 里怎么把 JNI 那一层拼起来。这篇文章按「哪条路径能用 → 工程怎么搭 → 参数怎么配 → 数据怎么切帧 → 哪里会翻车」推下去给的是能照着敲的代码和能对号入座的排错顺序适合正在用 Android 接 RS232/RS485/TTL 外设的从业者。2. 两条落地路径JNI 直接操作 /dev 与 USB Host 枚举Android 本身没有一套面向应用层的串口 API系统给的只有文件描述符。想拿到那个 fd只有两条路一条是打开/dev/ttyS*或/dev/ttyUSB*这类设备节点另一条是走 USB Host把一个 USB 转串口芯片当成设备枚举出来用bulkTransfer收发。两条路的权限模型、延迟特性和维护成本完全不同选错了后面全是返工。2.1 路径一/dev/ttyS* 与 termios为什么绕不开 JNI板载 UART 在 Linux 层就是个字符设备标准做法是opentcgetattr/tcsetattrread/write。Java 层没有任何一个类能表达termios结构体所以这一层必须下沉到 NDK用 C/C 写 JNI 封装Java 只负责调用。真正的门槛不在代码量在权限。多数量产固件里/dev/ttyS0的属性是crw------- root root或者crw-rw---- root system普通应用的 UID 根本进不去这个组。要让第三方 App 打开它通常只有三种办法设备已经 root启动脚本里chmod 666 /dev/ttyS*简单但很多出货设备不允许应用预置为系统签名由ueventd.rc在创建节点时把属主和权限改掉在系统 sepolicy 里补一条allow untrusted_app serial_device:chr_file { open read write ioctl }。常见做法是前两种只在自有硬件上可行一旦 App 要装到客户已有的设备上这条路基本走不通于是就有了第二条路。顺带说一个容易忽略的点有些方案会去读/proc/tty/drivers或者扫描/dev目录列出可用串口这不叫打开串口只是拿路径列表。扫描本身也会因为 SELinux 对/dev目录的read权限限制而返回空数组别把「列不出设备」和「打不开设备」混成一个问题。2.2 路径二USB Host UsbManagerbulkTransfer 的边界USB 转串口芯片CH340、CP2102、FT232、PL2303 这一类的产品形态插到 Android 设备上走的是 USB Host 协议。UsbManager能枚举到设备openDevice()拿到UsbDeviceConnectionclaimInterface()之后就能对 bulk 端点做收发。这条路不需要 root也不需要改系统策略代价是你要处理芯片差异和授权流程。枚举与打开的主干大概是这样UsbManager manager (UsbManager) context.getSystemService(Context.USB_SERVICE); UsbDevice device null; for (UsbDevice d : manager.getDeviceList().values()) { // 只看有 bulk 端点的接口避免把 HID 键盘之类误抓进来 for (int i 0; i d.getInterfaceCount(); i) { UsbInterface itf d.getInterface(i); if (itf.getEndpointCount() 2) { device d; break; } } if (device ! null) break; } if (device null) return; if (!manager.hasPermission(device)) { // 没有授权就先申请结果通过 PendingIntent 回到广播接收器 PendingIntent pi PendingIntent.getBroadcast(context, 0, new Intent(ACTION_USB_PERMISSION).setPackage(context.getPackageName()), PendingIntent.FLAG_MUTABLE); manager.requestPermission(device, pi); return; } UsbDeviceConnection conn manager.openDevice(device); UsbInterface intf device.getInterface(0); conn.claimInterface(intf, true); UsbEndpoint epIn null, epOut null; for (int i 0; i intf.getEndpointCount(); i) { UsbEndpoint ep intf.getEndpoint(i); if (ep.getType() ! UsbConstants.USB_ENDPOINT_XFER_BULK) continue; if (ep.getDirection() UsbConstants.USB_DIR_IN) epIn ep; else epOut ep; }逻辑上分四步枚举过滤、权限申请、claim 接口、挑端点。参数上要注意claimInterface(intf, force)的第二个参数传true会强制从内核驱动手里抢接口在某些定制系统上会导致系统自带的光驱/串口服务被踢掉一般建议先传false失败了再考虑强制。真正的麻烦在于「USB 转串口」并不是一个标准类。CDC-ACM 芯片会声明USB_CLASS_CDC_DATA走标准类请求就能配波特率而 CH340、CP2102 这类用的是厂商自定义 class0xFF波特率、数据位、停止位全部要通过controlTransfer写芯片内部寄存器寄存器地址和换算公式各家不同。这就是为什么社区里会有 usb-serial-for-android 这类开源实现它把各家芯片的初始化序列都封装了一遍。自己从零写一个 CH340 的波特率配置光是对着芯片手册算分频系数就能耗掉半天。还有两个边界容易被忽略。第一bulkTransfer是会阻塞的timeout传 0 表示无限等待读线程一旦卡住就再也没有机会退出务必给个明确的毫秒数。第二USB 线拔掉的瞬间UsbDeviceConnection就失效了继续调bulkTransfer不会抛异常只会静默返回 -1必须监听UsbManager.ACTION_USB_DEVICE_DETACHED广播去置位并重建连接。2.3 选型对照权限、延迟、兼容性与维护成本维度直接操作 /dev/ttyS*USB Host bulkTransfer权限门槛需要 root 或系统签名或改 sepolicy运行时弹窗授权无需 root硬件依赖板载 UART 必须引出需要一个 USB 转串口芯片典型延迟微秒级可控毫秒级受 USB 帧调度影响多路支持几个 ttyS 就能开几路每路一个 USB 设备或芯片多通道兼容性风险各 SoC 的 ttyS 编号不统一芯片型号杂厂商协议不统一维护成本低代码稳定后基本不动中新芯片要补初始化序列判断标准其实很干脆设备是自己能控固件的板子优先走 ttyS延迟和稳定性都更好App 要装到别人家的设备上老老实实走 USB Host。中间还有一种折中方案设备厂商把串口服务做成系统服务App 通过 AIDL 或 Socket 转发数据把权限问题挡在系统侧这种在量产项目里很常见。3. 在 Android Studio 里跑通第一帧NDK 编译、termios 配置与读写线程这一章从空工程开始把 ttyS 路径完整跑通。选它作为主线是因为它把 termios 的每个参数都暴露在你面前理解了这套配置回头再看 USB 方案里的芯片寄存器会轻松很多。3.1 工程骨架与 CMake 配置把 ABI 和 STL 先定死模块结构建议这样切app放界面和业务serialkit做成一个独立的 library moduleJNI 代码放在serialkit/src/main/cpp。独立模块的好处是后面接第二个项目时直接拷过去不用在app里翻 JNI 目录。build.gradle里要显式声明 ABI 过滤和 CMake 路径android { compileSdk 34 defaultConfig { minSdk 21 ndk { // 只保留实际会出货的 ABI能显著缩小包体 abiFilters armeabi-v7a, arm64-v8a, x86_64 } externalNativeBuild { cmake { cppFlags -stdc17 -fexceptions } } } externalNativeBuild { cmake { path file(src/main/cpp/CMakeLists.txt) version 3.22.1 } } }abiFilters里的x86_64是为了模拟器调试保留的真机发版可以砍掉。cppFlags加-fexceptions是因为下面用到了std::string的异常路径不加会在某些 NDK 版本上报exception handling disabled。对应的CMakeLists.txtcmake_minimum_required(VERSION 3.22.1) project(serialkit) add_library(serialkit SHARED SerialPort.cpp) find_library(log-lib log) target_link_libraries(serialkit ${log-lib})不用额外链接libctermios、poll、fcntl都在 bionic 里。命名上库名叫serialkitJava 侧System.loadLibrary(serialkit)必须对上少一个字母就是UnsatisfiedLinkError这类错误不会告诉你缺哪个符号只会在第一次调用 native 方法时崩。3.2 open 与 termios 逐项拆解raw 模式到底关掉了什么先看打开设备的这一段。这里有个关键取舍open的时候带O_NONBLOCK打开成功后再用fcntl把非阻塞标志清掉。#include jni.h #include fcntl.h #include termios.h #include unistd.h #include poll.h #include errno.h #include android/log.h #define LOGE(...) __android_log_print(ANDROID_LOG_ERROR, SerialJNI, __VA_ARGS__) static speed_t to_speed(int baud) { switch (baud) { case 9600: return B9600; case 19200: return B19200; case 38400: return B38400; case 57600: return B57600; case 115200: return B115200; case 230400: return B230400; case 460800: return B460800; case 921600: return B921600; default: return B115200; } } extern C JNIEXPORT jint JNICALL Java_com_example_serialkit_SerialPort_nativeOpen( JNIEnv *env, jclass, jstring jpath, jint baud, jint dataBits, jint stopBits, jint parity) { const char *path env-GetStringUTFChars(jpath, nullptr); // O_NONBLOCK 只为避免 open 阶段被 DCD 信号卡死稍后会清掉 int fd open(path, O_RDWR | O_NOCTTY | O_NONBLOCK); env-ReleaseStringUTFChars(jpath, path); if (fd 0) { LOGE(open failed, errno%d, errno); return -errno; } // 打开成功后切回阻塞模式超时交给 poll 控制 int flags fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, flags ~O_NONBLOCK); struct termios tty{}; if (tcgetattr(fd, tty) ! 0) { close(fd); return -errno; } cfmakeraw(tty); // 关掉行缓冲、回显、信号字符 cfsetispeed(tty, to_speed(baud)); cfsetospeed(tty, to_speed(baud)); tty.c_cflag | (CLOCAL | CREAD); // 忽略调制解调器控制线允许接收 tty.c_cflag ~CRTSCTS; // 默认关硬件流控 tty.c_cflag ~CSIZE; switch (dataBits) { case 5: tty.c_cflag | CS5; break; case 6: tty.c_cflag | CS6; break; case 7: tty.c_cflag | CS7; break; default: tty.c_cflag | CS8; break; } if (stopBits 2) tty.c_cflag | CSTOPB; else tty.c_cflag ~CSTOPB; if (parity 1) { // 奇校验 tty.c_cflag | PARENB; tty.c_cflag | PARODD; } else if (parity 2) { // 偶校验 tty.c_cflag | PARENB; tty.c_cflag ~PARODD; } else { tty.c_cflag ~PARENB; } tty.c_cc[VMIN] 0; // 配合 VTIME 形成带超时的读 tty.c_cc[VTIME] 0; // 实际超时由 poll 负责 if (tcsetattr(fd, TCSANOW, tty) ! 0) { close(fd); return -errno; } tcflush(fd, TCIOFLUSH); // 丢弃配置期间残留的脏数据 return fd; }cfmakeraw是这段的核心它一次性做了这些事关掉ICANON否则 read 会一直等换行符、关掉ECHO、关掉ISIG否则收到 0x03 会触发 SIGINT 把进程干掉、关掉IXON/IXOFF否则 0x11/0x13 会被当成软件流控吃掉。做二进制协议时这几项必须关不然调试时会出现「数据里一有 0x0D 就断帧」这种看着像玄学的问题。CLOCAL表示忽略 DCD 信号很多 USB 转串口线不接 DCD不加这个在某些内核上open会一直阻塞。CREAD是接收使能漏了就一个字节都收不到。tcflush(fd, TCIOFLUSH)放在配置之后是因为波特率切换的瞬间收发 FIFO 里可能残留上一轮的半截数据不清掉第一帧解析必然出错。3.3 读写线程用 poll 拿超时别把阻塞读丢给 JavaJava 层的封装把 fd 当 int 保存所有读写都走 native避免FileInputStream在 Android 上被O_NONBLOCK和VTIME的交互搞出难以预料的行为。public final class SerialPort implements Closeable { private final int fd; private volatile boolean closed false; static { System.loadLibrary(serialkit); } public SerialPort(String path, int baudRate, int dataBits, int stopBits, int parity) throws IOException { int handle nativeOpen(path, baudRate, dataBits, stopBits, parity); if (handle 0) { throw new IOException(open path failed, errno (-handle)); } this.fd handle; } /** 返回实际读到的字节数0 表示超时无数据抛异常表示链路出错 */ public int read(byte[] buffer, int timeoutMs) throws IOException { if (closed) throw new IOException(port closed); int n nativeRead(fd, buffer, timeoutMs); if (n 0) throw new IOException(read failed, errno (-n)); return n; } public void write(byte[] data) throws IOException { if (closed) throw new IOException(port closed); int n nativeWrite(fd, data, data.length); if (n 0) throw new IOException(write failed, errno (-n)); } Override public void close() { if (closed) return; closed true; nativeClose(fd); } private static native int nativeOpen(String path, int baud, int dataBits, int stopBits, int parity); private static native int nativeRead(int fd, byte[] buffer, int timeoutMs); private static native int nativeWrite(int fd, byte[] data, int len); private static native void nativeClose(int fd); }对应的 native 读用poll等可读再读超时可控extern C JNIEXPORT jint JNICALL Java_com_example_serialkit_SerialPort_nativeRead( JNIEnv *env, jclass, jint fd, jbyteArray jbuf, jint timeoutMs) { struct pollfd pfd{}; pfd.fd fd; pfd.events POLLIN; int ret poll(pfd, 1, timeoutMs); if (ret 0) return 0; // 超时交给上层循环继续 if (ret 0) return -errno; if (pfd.revents (POLLERR | POLLHUP | POLLNVAL)) return -EIO; jsize cap env-GetArrayLength(jbuf); jbyte *buf env-GetByteArrayElements(jbuf, nullptr); ssize_t n ::read(fd, buf, static_castsize_t(cap)); env-ReleaseByteArrayElements(jbuf, buf, 0); if (n 0) return -errno; return static_castjint(n); } extern C JNIEXPORT jint JNICALL Java_com_example_serialkit_SerialPort_nativeWrite( JNIEnv *env, jclass, jint fd, jbyteArray jdata, jint len) { jbyte *buf env-GetByteArrayElements(jdata, nullptr); ssize_t n ::write(fd, buf, static_castsize_t(len)); env-ReleaseByteArrayElements(jdata, buf, 0); if (n 0) return -errno; return static_castjint(n); }poll的第三个参数就是超时毫秒数传 -1 会永久阻塞传 0 立即返回。返回值的三态必须分开处理0 是超时、负数要取-errno、revents里有POLLHUP说明对端没了。很多实现只看返回值大于 0 就往下读结果设备拔掉后read一直返回 0线程空转把 CPU 拉满。Java 侧读线程的写法private void readLoop() { byte[] buf new byte[512]; while (!port.isClosed()) { try { int n port.read(buf, 200); // 200ms 超时保证能响应退出信号 if (n 0) { decoder.feed(buf, n); // 交给协议解析不在这里做业务 } } catch (IOException e) { if (!port.isClosed()) notifyBroken(e); return; } } }超时值不能设太大200ms 是个平衡点既不会因为频繁唤醒增加功耗又能在业务层发停止命令后及时退出。写操作建议单独一个线程加一个队列因为write在缓冲区满时会阻塞跟读混在一个线程里会出现「发不出去也收不到」的死锁。3.4 联调验证虚拟串口对与自环回测试在真机上接外设之前先用 PC 验证协议层。Linux 下socat -d -d pty,raw,echo0 pty,raw,echo0能造出一对虚拟串口把 Android 设备通过 USB 转串口接到 PCPC 侧一端接 Android、一端接你自己的模拟脚本就能在不碰真实硬件的情况下把帧解析跑通。硬件侧的自环回是另一道保险把 TX 和 RX 短接注意电平TTL 直连没问题RS232 千万别这么干发什么就应该收到什么。收不到就按顺序查open是否成功、tcsetattr返回值、CREAD有没有置、TX/RX 有没有接反、地线有没有共。这套顺序比盲目改代码高效得多。4. 参数与协议115200 之外的波特率、帧格式与粘包切分链路通了之后问题会转移到数据层。串口是字节流没有包边界也没有重传所有帧结构都得自己在应用层补。这一层设计得糙后面接十个外设就要改十次。4.1 波特率误差与硬件时钟为什么 921600 会玄学UART 是异步通信收发双方靠各自的时钟对齐每一个 bit。工业上公认的安全边界是累计误差不超过 2%3%超过这个值采样点就会漂到相邻 bit 上表现是偶发丢字节或者整帧乱码。Android 设备的 UART 时钟通常来自 24MHz 或 48MHz 的晶振分频系数是整数所以能不能精确得到目标波特率取决于整除关系。115200 在多数 SoC 上误差接近 0921600 就要看具体平台了有的能整除有的只能取近似值误差上到 3% 以上短帧看着正常长帧必错。这不是代码问题改代码没用。几条实操经验能用 115200 就别上更高的绝大多数传感器和扫码模块在这个速率下完全够用必须上高速率时先在 PC 上同一根线同一速率跑一遍把 SoC 和线材的因素分开高波特率下要缩短线长TTL 电平超过 30cm 就开始不可靠RS485 差分能好一些但也要看终端电阻非标准波特率250000、256000 这类在 bionic 里没有对应的Bxxx常量cfsetispeed会静默失败。真要打得用ioctl配TCSETS2还得自己定义termios2结构体并且依赖内核开启对应支持成本不低。还有个隐蔽的坑部分 USB 转串口芯片内部的波特率是「近似档位」你传 921600它实际配出来的是 900000。这种偏差在芯片手册的分频表里能看到用逻辑分析仪抓一段波形量一下位宽就能算出来。4.2 帧结构设计帧头、长度、CRC 与超时切帧自己定协议时一个够用又不容易出错的帧格式大概是这四段字段长度说明帧头2 字节固定0xAA 0x55两字节比单字节抗误判长度1 字节只计 payload 长度上限 255超长就分片载荷N 字节业务数据含命令字和参数校验2 字节CRC16/MODBUS低字节在前CRC16 的实现没什么花样查表和非查表都行非查表的版本在 Java 里跑几十字节的开销可以忽略public static int crc16(byte[] data, int offset, int len) { int crc 0xFFFF; for (int i 0; i len; i) { crc ^ (data[offset i] 0xFF); for (int j 0; j 8; j) { if ((crc 0x0001) ! 0) { crc (crc 1) ^ 0xA001; // MODBUS 多项式反向写法 } else { crc 1; } } } return crc 0xFFFF; }校验范围要写死从长度字段开始算到 payload 结束不含帧头。这一点如果不约定清楚两边各按各的理解算联调时会出现「CRC 一直错但抓包看数据又都对」的情况非常浪费时间。4.3 环形缓冲与读取策略小包高频场景怎么不丢read一次拿到的字节数是不确定的可能半帧也可能三帧连在一起。直接往解析器里塞一定会遇到粘包和半包。标准解法是一个环形缓冲加一个状态机。public final class FrameDecoder { private final byte[] ring new byte[4096]; private int head 0; // 写指针 private int tail 0; // 读指针 private final FrameListener listener; public FrameDecoder(FrameListener listener) { this.listener listener; } public synchronized void feed(byte[] data, int len) { // 1. 入环形缓冲满了就丢最老的宁可丢数据也不能阻塞读线程 for (int i 0; i len; i) { ring[head] data[i]; head (head 1) % ring.length; if (head tail) tail (tail 1) % ring.length; } // 2. 循环切帧直到剩余数据不够一帧 while (true) { int avail (head - tail ring.length) % ring.length; if (avail 5) return; // 帧头2 长度1 CRC2 if ((ring[tail] 0xFF) ! 0xAA || (ring[(tail 1) % ring.length] 0xFF) ! 0x55) { tail (tail 1) % ring.length; // 不是帧头就滑一个字节 continue; } int payloadLen ring[(tail 2) % ring.length] 0xFF; int frameLen 2 1 payloadLen 2; if (avail frameLen) return; // 半包等下次数据 byte[] frame new byte[frameLen]; for (int i 0; i frameLen; i) { frame[i] ring[(tail i) % ring.length]; } int expect ((frame[frameLen - 1] 0xFF) 8) | (frame[frameLen - 2] 0xFF); int actual crc16(frame, 2, 1 payloadLen); if (expect actual) { listener.onFrame(frame, 3, payloadLen); tail (tail frameLen) % ring.length; } else { tail (tail 1) % ring.length; // 校验失败滑动重同步 } } } }状态机的核心是「校验失败只滑一个字节不滑一整帧」。因为出错的位置可能就在帧头附近按帧长跳会跳过真正的下一帧开头。滑动重同步的代价是重扫一遍但对 115200 的速率来说这点 CPU 完全不值一提。环形缓冲满了的处理也要想清楚丢最老的数据而不是阻塞写。读线程一旦阻塞底层 FIFO 溢出丢的就是一整段比丢一个旧帧严重得多。4.4 校验与重传CRC16 实现和一次翻车复盘串口本身没有重传机制应用层要不要做取决于业务。控制类指令开关、启停建议做发出去之后等 ACK超时 200ms 重发连发三次还不回就上报链路异常。数据上报类传感器周期读数通常不做重传丢一帧就丢一帧下一帧很快就来。重传的实现要点是「请求-应答要能配对」。只发一个自增的序号回包把序号带回来超时定时器按序号去匹配。曾经有个项目只做了超时重发没做序号匹配结果设备响应慢的时候重发的第二包和第一包的回复撞在一起业务层把同一条指令执行了两次机械臂直接走到了限位。同样的思路也适用于流控。软件流控XON/XOFF会把 0x11/0x13 当控制字符吃掉二进制协议里绝对不能用硬件流控RTS/CTS需要外设支持并且线要接全很多模块只引了 TX/RX/GND 三根线那就只能在应用层靠限速来避免把对方缓冲打爆。5. 避坑与排查五个把联调拖到凌晨的串口问题5.1 打开设备返回 EACCES日志里没有任何有效信息现象nativeOpen返回 -13Java 层抛open /dev/ttyS1 failed, errno13代码逻辑怎么看都没问题。原因/dev/ttyS1的属主是root:root权限600应用 UID 根本没有读权限或者权限已经放开但 SELinux 的策略里untrusted_app域没有访问这个字符设备的规则。前者用adb shell ls -l /dev/ttyS*就能确认后者要adb shell dmesg | grep avc看有没有denied { open }记录。解决如果是自有硬件改ueventd.rc里的权限位或者补 sepolicy比在应用里想办法靠谱得多。如果是客户现场的设备改不了固件那这条路径就该放弃转 USB Host 方案别在这上面继续耗。5.2 写操作返回成功但一个字节都收不到现象write返回的字节数和发送长度一致对端设备毫无反应示波器上 TX 脚也没有波形。原因大概率是 TX/RX 接反了或者两根线接了但地线没共。还有一种情况是电平不匹配3.3V 的 TTL 直接怼到 5V 的 RS232 接口上不仅收不到还可能把 IO 打坏。解决先短接自环回确认本端收发通路正常再接对端量一下空闲电平TTL 空闲是高电平 3.3V 或 5VRS232 空闲是负电压。这些用万用表就能测比盯着代码看快十倍。5.3 USB 设备授权弹窗点了确定仍然 openDevice 失败现象hasPermission在弹窗之后依然返回 false或者openDevice返回 null。原因PendingIntent的 action 字符串在申请和接收广播两处不一致Android 12 以后PendingIntent必须显式指定FLAG_IMMUTABLE或FLAG_MUTABLE少了会直接抛异常另一种常见情况是这个 USB 设备已经被系统里另一个应用claimInterface占住了同一个接口不能被两个进程同时声明。解决把 action 抽成常量两处引用同一个PendingIntent用FLAG_MUTABLE需要由系统填入 extras排查占用可以用adb shell dumpsys usb看当前设备的持有者。5.4 收到的数据能对上但偶尔错几个字节现象大部分帧正常每隔几十帧就有一帧 CRC 校验失败重发后又能通过。原因波特率误差累积到临界值采样点飘了或者线太长、没有屏蔽旁边有变频器这类干扰源还有一种容易被忽略的情况是共地不良两边地电位差几十毫伏就足以让高电平被判成低。解决先降波特率到 9600 试如果错误消失基本可以确认是时钟误差或线材问题换屏蔽双绞线并且单端接地长距离场景直接改 RS485 差分别在 TTL 上硬撑。5.5 设备拔插几次之后应用崩溃或数据不再刷新现象第一次插上能用拔掉再插上读线程就再也不返回数据了或者直接NullPointerException。原因UsbDeviceConnection在拔出后失效但对象引用还在bulkTransfer静默返回 -1读线程没有监听 detached 广播一直在对一个死连接做操作重连时旧的线程没退出新的又起来两个线程抢同一个端点。解决注册ACTION_USB_DEVICE_DETACHED广播收到后先置位停止标志、join读线程、close连接再走一遍完整的枚举授权流程。重连逻辑一定要做成幂等的重复调用不能产生第二个连接。6. 进阶把串口封装成可回放、可复现的组件现场调试最痛苦的不是写代码是「问题只出现一次之后再也复现不了」。所以在项目里我会强制给串口加两个能力录包和注入。录包指的是把每次read到的原始字节连同时间戳写进文件格式就是简单的二进制8 字节时间戳加 2 字节长度加原始数据。出问题时让现场把文件导出来在本地用同一个FrameDecoder回放能复现 90% 的解析问题。回放的时候把时间戳当作节奏控制比真实链路慢一点也无所谓重点是数据序列一致。注入则是给单元测试用的。FrameDecoder的feed(byte[], int)不依赖任何 Android 类直接把构造好的字节数组喂进去就能测边界半包、粘包、CRC 错、帧头出现在 payload 里。这套测试跑一遍只要几十毫秒比接硬件快太多。能力实现位置关键点原始录包读线程出口写文件用独立线程别阻塞读循环回放测试代码复用同一个 decoder 实例保证路径一致注入测试JVM 单测decoder 不依赖 Android API可直接跑链路健康度读线程统计超时次数、CRC 失败率超阈值告警还有一个习惯值得养成所有 native 报错都把errno原样带到 Java 层别只抛一句「打开失败」。EACCES、ENOENT、EBUSY、EIO这四个值对应的排查方向完全不同把 errno 打出来现场的人照着查就行能省掉一轮远程沟通。从那以后我每次接新的串口外设都强制先跑一遍自环回加录包确认链路和解析都干净了再接业务逻辑。这个习惯救过好几次尤其是在没法到现场的远程支持里。希望帮到你。本文还有配套的精品资源点击获取
