企业官网建设流程全解析

做车载开发这几年，我越来越确信一件事：串口不是“过时的老古董”，而是Android车机上最绕不开的通信手段之一。很多人一看UART、RS232、RS485这几个词就觉得是教科书里才有的东西，可真到了项目现场，屏幕调参要串口、传感器上报要串口、外设对接要串口，连板子烧写、日志输出，最后几乎都退回串口。这篇笔记就把我调车载串口时踩过的坑、验证过的配置、以及能直接拿去用的代码整理出来，给正在做Android车载、车机、工业平板的工程师一个参考，也帮被乱码和权限折腾到头秃的朋友少走点弯路。

1. 先把串口的底子打牢：UART、RS232、RS485到底是什么关系

1.1 三者的真实关系：UART是“声带”，RS232/RS485是“嗓门大小和说话规则”

很多初学者会把UART、RS232、RS485当成三种并列的“串口”，这个理解其实不准确。UART（Universal Asynchronous Receiver/Transmitter）是芯片内部的硬件模块，负责把并行数据拆成一位一位的串行bit流发出去，再把收到的bit流拼回完整字节。它只解决“怎么说”的问题，至于信号在线上长什么样、能传多远、能不能挂多个设备，UART本身不管。

真正决定线上信号形态的，是电气标准。RS232和RS485就是两套经典的电气标准。打个比方：UART是你的声带，负责发出声音；RS232是让你面对面大声喊，声音大、抗干扰差，而且只能一对一；RS485则是给你一个对讲机，走差分信号，一条线上能挂几十台设备，传几百米还能抗干扰。

具体到电平上，差别非常大：

所以你在Android里打开一个“串口”，本质上是打开一个UART设备节点，节点的电平规格可能是TTL，也可能外接了RS232或RS485转换芯片。搞清楚这条链路，后面调参数、排故障才不会瞎猜。

1.2 为什么车载场景还死守着串口不放

车机里明明有CAN总线、有以太网、有USB，为什么还要用串口？原因很实在：串口简单、确定、实时性好。CAN虽然强，但协议复杂，帧结构、仲裁、滤波都得配；而且很多外设天生就是串口接口，你要做的是适配它们，而不是让它们来适配你。

典型场景一抓一大把：

• 串口屏：很多中控副屏、空调控制面板用的还是UART串口屏，主控发一串指令就能切页面、改数值。
• GNSS模块：GPS/北斗模块输出NMEA 0183语句，走的就是UART，一句$GPRMC里带出时间、经纬度、速度。
• OBD读取：不少车机方案里，诊断口数据经过转发后也是串口到Android主板。
• 传感器和外设：车身称重、胎压监测中转、后备箱锁控制、充电桩通信，这些东西量大、成本敏感，串口是最便宜的方案。

相比USB，串口不需要枚举、不需要驱动协商、没有热插拔状态机；相比I2C和SPI，串口只需要两条数据线没有时钟线，线序要求低，走线也友好。串口天然就是“发指令、收应答”这种控制类通信的好手，数据量不大、长度短、实时性要求高，正好命中车载控制场景的痛点。所以在 Android 系统里，串口通常不是被淘汰的接口，而是藏在系统服务或者硬件抽象层后面的“稳定底牌”。

2. Android开串口前必须理解的几个底层机制

2.1 串口在Android里没有“官方API”怎么办

Android SDK里没有面向应用层的串口API，这是所有Android串口开发者的“第一课”。Java层不能直接open("/dev/ttyS1")，系统不允许普通应用随意访问设备节点。你要么在系统层写一个串口服务，要么用JNI/NDK绕过Java的限制。

目前常用的方案有三种：

1. 使用Google早期的android-serialport-api。这个项目年代久远，但思想到现在依然管用：C文件里封装open/read/write/close，通过JNI把文件描述符传给Java层，Java层再基于InputStream/OutputStream做读写。
2. 自己写NDK代码。Android Studio里配好CMake，把Linux的termios操作封装成so库，灵活度最高，可以自由加自定义波特率、非标准校验。
3. 用现成的开源串口库。比如wendal维护的android-serialport-api，以及一些商业库，本质上还是JNI+termios，只是省去了自己编译的步骤。

抛开表象看原理，Android串口开发的核心就是：

• 调用Linux的open()打开设备节点；
• 用tcgetattr()和tcsetattr()配置termios参数；
• 用read()和write()收发数据；
• 最后close()关闭描述符。

设备节点的路径比较固定：高通平台常见/dev/ttyHSL*或/dev/ttyS*，联发科常见/dev/ttyMT*，USB转串口常见/dev/ttyUSB*。如果板子厂商提供了系统级串口服务，应用层可以直接通过Binder或Socket来收发；如果是自己玩开发板，那就要自己处理权限和节点问题了。

2.2 权限、SELinux和dev节点：新手最常卡的三个地方

我见过太多人卡在第一步：JNI代码明明没问题，但open()返回-1。其实大部分原因不是代码，而是权限。

第一层权限就是Linux文件权限。/dev/ttyS*通常属于root用户，默认权限是crw-rw----，root和serial组可以访问，普通app的uid根本不在组里。临时验证可以adb root后执行chmod 666 /dev/ttyS1；正式方案要改init.rc，在设备节点创建后追加chmod 666，或者写一个串口守护进程，由守护进程代你打开串口，再通过本地Socket把数据转发给应用。

第二层是SELinux。Android 5.0之后默认enforcing，即使你把节点权限改成777，SELinux依然可能拦你。排查时先跑adb shell getenforce，如果显示Enforcing，要么临时setenforce 0验证，要么正经写te策略，在.te文件里给串口设备节点加allow规则，常见写法是：

allow appdomain serial_device:chr_file rw_file_perms;

第三层是节点本身不存在。这就要回到内核设备树了。很多SoC的UART引脚默认是gpio或者被其他外设复用，厂商没有配置对应的pinctrl和uart节点，系统启动后/dev下根本没有设备节点。遇到这种情况，先看dmesg | grep -i uart有没有对应外设初始化信息，再去找内核dts，把uart*节点的status改成okay，pinmux选成uart功能。

排查顺序建议是：先ls -l /dev/ttyS*看节点存在与否，再ls -l看权限，再getenforce看SELinux，最后dmesg看驱动。一层一层排除，比一上来就怀疑自己的JNI写得不对高效得多。

3. 车载串口通信的核心参数配置：波特率、数据位、停止位、校验位

3.1 参数怎么配才不乱码：波特率一致只是第一步

串口通信双方必须约定好一组参数，通常叫“串口格式”，最常见的是“115200 8N1”：波特率115200、8位数据位、无校验、1位停止位。另一个高频组合是Modbus RTU默认的“9600 8E1”，8位数据、偶校验、1位停止位。

很多人以为只要波特率一样就不会乱码，实际远没这么简单。我调试时遇到的乱码，至少有一半是下面这些原因：

• 校验位不一致：设备端是偶校验，你配置成了无校验，收进来的数据自然对不上。
• 电平不匹配：TTL设备直接接在RS232转换器上，或者RS232线缆太长导致信号衰减，都会让波形畸变。
• 接线问题：TXD和RXD交叉错了，或者地线没接，通信就是单通或乱码。
• 干扰：车载环境里电机、点火线圈、电磁阀都会产生干扰，长距离走线尤其明显。
• 驱动和终端模式问题：没有设置原始模式（raw mode），终端对特殊字符做了转换，比如把0x0A转成0x0D 0x0A，也会出现数据错乱。

计算一下串口的理论吞吐，也能帮你判断配置是否符合预期。在8N1格式下，一个字节要发送1位起始位 + 8位数据位 + 1位停止位，一共10个bit。波特率115200时，理论最大每秒能传11520个字节。考虑系统调度、缓冲和协议开销，实际稳定传输也就七八成。如果你的业务需要持续传图片或大文件，串口会很快撞到天花板，这时候要么降低数据量，要么换USB。

3.2 从TC termios配置到JNI：一份能跑的配置代码示例

串口配置在Linux里统一走termios。我封装串口时常用的C代码核心长这样：

#include <termios.h> #include <fcntl.h> #include <unistd.h> #include <sys/ioctl.h> int open_serial(const char *path, int baudrate) { int fd = open(path, O_RDWR | O_NOCTTY | O_NDELAY); if (fd < 0) { return -1; } struct termios options; tcgetattr(fd, &options); // 原始模式，不做任何终端转换 cfmakeraw(&options); // 设置波特率，这里以 B115200 为例 cfsetispeed(&options, B115200); cfsetospeed(&options, B115200); // 本地连接，允许接收 options.c_cflag |= (CLOCAL | CREAD); // 8位数据位 options.c_cflag &= ~CSIZE; options.c_cflag |= CS8; // 无校验 options.c_cflag &= ~PARENB; // 1位停止位 options.c_cflag &= ~CSTOPB; // 关闭硬件流控 options.c_cflag &= ~CRTSCTS; // 读操作：至少读1个字节才返回，不超时 options.c_cc[VMIN] = 1; options.c_cc[VTIME] = 0; tcsetattr(fd, TCSANOW, &options); return fd; }

这里有几个关键点值得展开说说。cfmakeraw()是最容易被人忽略的一步，它保证串口不会经过终端驱动层的转义处理，否则你收到的0x11、0x13这类控制字符可能被拦截或转换，数据必乱。CLOCAL表示不依赖调制解调器的载波信号，适合板卡对板卡的直连。VMIN和VTIME是read的阻塞策略，VMIN=1, VTIME=0表示只要有1个字节就返回；如果你希望read超时返回，可以把VTIME设置成比如10，单位是0.1秒，配合VMIN=0使用。

JNI层要注意两件事：一是从Java传字符串路径给C时，用GetStringUTFChars()正确处理；二是在C层缓存文件描述符，封装nativeRead/nativeWrite方法，通过new byte[]和ByteBuffer传递数据时，要考虑内存拷贝的效率。对于车机设备来说，串口数据量通常不大，内存拷贝压力可以忽略，但逻辑一定要严谨，fd用完后及时close。

4. RS232/RS485组网与硬件方案里的那些坑

4.1 RS232：和调试电脑对接时，电平转换芯片别选错

RS232最经典的应用是连接调试电脑，但很多人会直接在TTL电平的主板上接一个DB9头到电脑，结果发现完全不通。原因很简单：TTL电平的1是3.3V或5V，RS232电平的1是负电压，两者根本不兼容。

正确的做法是中间加一颗电平转换芯片，比如MAX232、SP3232。这类芯片内部有电荷泵，把单5V电源变换出正负电压，实现TTL到RS232的电平转换。选型时注意供电电压和通道数，有的芯片是3.3V供电，别直接接5V烧掉。

RS232接线也有讲究。DB9公头和母头的2、3脚分别是RXD和TXD，两台设备对接时通常要交叉连接：A设备的TXD接B设备的RXD，A设备的RXD接B设备的TXD。调试时如果发现收不到数据，先把2、3脚对调试试。还有地线必须接，RS232是单端信号，以GND为参考，地线悬空的话电压参考点漂移，轻则乱码，重则烧接口。

遇到RS232乱码，先用万用表量静态电平。正常空闲状态下，TXD和RXD对GND应该有负电压（-5V到-12V之间），如果量出来是0V或者正电压，大概率是转换芯片没工作或者接错线了。

4.2 RS485自动收发电路为什么是车载通信的“保命”选择

RS485在车载和工控场景里地位很高，本质原因是差分传输。它用A、B两根线的电压差来表示逻辑1和0，外界的共模干扰同时作用在两根线上，差值基本不受影响，所以抗干扰能力强、传输距离远，还能一主多从组网。

RS485是半双工的，收发不能同时进行。传统方案里，MCU或SoC的GPIO需要控制收发芯片的DE/RE脚：发送数据前拉高DE，发完再拉低切回接收。这个软件切换看似简单，实际很坑：切换早了数据发不全，切换晚了丢应答；一旦总线繁忙，两个设备同时抢线还会冲突。

所以我更推荐自动收发电路。它的原理是把TXD信号经过三极管或比较器处理，自动产生方向控制信号，发送数据时任其拉高，空闲时自动回到接收态。硬件上不用软件干预，时序天然正确，对Android这种非实时系统反而更友好——要知道Android应用层的线程调度是不可控的，让一个随时可能被GC卡住的线程去精确控制收发方向，风险太大。

RS485组网的工程注意点至少有三个：

• 终端电阻只接两头。120欧匹配电阻是为了消除长线反射，只在总线物理最远的两端接，中间节点不要接。全部接上会拉低差分信号幅度。
• 走线尽量手拉手。RS485是总线拓扑，从总线某个节点再拉一条长分支到别处，容易造成反射和驻波，最后表现为偶发通信失败。
• 屏蔽层单点接地。屏蔽层是为了防共模干扰，但两端都接地会形成地环路，反而引入干扰。一般建议在主机端单点接地。

4.3 控制器选型里的那些指标：双电源、防雷、多路RS485

最近看一些车载控制器的需求文档，经常看到这样的描述：“控制器配备双电源，标配网络防雷接口≥6路、接地通路接口≥2路、RS485接口≥6。”这些指标不是拍脑袋写的，每一项背后都有实际工程原因。

双电源意味着主备供电。车载主电源在启动瞬间电压可能会跌落，如果控制器只有一路供电，复位一次整个通信网络都要重建，这是不可接受的。备用电源保证在主电异常时依然能维持RS485总线上的设备不掉线。

防雷接口多，和RS485的走线环境强相关。车载设备有时候要走很长的线缆到车尾或车顶，雷雨天气或静电放电时，浪涌会沿着线缆灌进接口。TVS管、气体放电管、PTC自恢复保险丝这些防护器件虽然不起眼，但没有它们，一颗雷就能烧掉一整批控制器。

多路RS485接口则对应“分区分设备”的布网思路。一路给管理平台上报，一路接现场交互设备，一路留作扩展或故障隔离。不同路数之间最好加隔离电源和隔离芯片，避免某一段总线短路把整个控制器拉死。如果项目选型时发现只有单路RS485，而现场设备又分散，后期加隔离器和路由器的成本会更高。

5. 实战：Android读取RS485传感器设备数据并解析报文

5.1 硬件连接和通信协议预演

纸上谈兵没意思，我拿一个实际场景来演示：Android车机通过USB转RS485接一个Modbus RTU协议的温湿度传感器。

先约定链路：车机USB口插一个USB转RS485模块，模块的A、B线接传感器的A、B端子，传感器端并联120欧终端电阻。串口参数设置为9600 8N1，也就是波特率9600、8位数据、无校验、1位停止位。

Modbus RTU协议非常简单，主机发出请求帧，从机回响应帧。举个例子，读地址为1的传感器保持寄存器，从地址0开始读2个寄存器，请求帧是：

01 03 00 00 00 02 C4 0B

拆开看：01是从机地址，03是功能码（读保持寄存器），00 00是起始寄存器地址，00 02是寄存器数量，C4 0B是CRC16校验。如果传感器正常，响应帧可能是：

01 03 04 02 6B 01 40 34 7E

01是从机地址，03是功能码，04是后面数据字节数，02 6B换算成十进制是619，可能是温度乘以10，01 40换算成十进制是320，可能是湿度乘以10，最后两个字节是CRC16。

这一步最重要的经验是：写代码之前先把协议用PC串口助手验证一遍。如果硬件和数据链路都正常，串口助手能收到和上面类似的响应帧，再开始写Android端代码；如果串口助手都收不到，先别折腾App，回头查硬件。

5.2 报文解析的完整Java/Kotlin示例

假设串口已经被JNI库打开，拿到InputStream和OutputStream，Android端的核心工作就是两件事：按帧读数据、按协议解析数据。

先写一个读取并解析Modbus响应帧的工具类，核心逻辑如下：

object ModbusParser { fun parseResponse(buffer: ByteArray, length: Int): ModbusData? { if (length < 5) { return null // 连基础帧长度都不够 } val slaveId = buffer[0].toInt() and 0xFF val function = buffer[1].toInt() and 0xFF val byteCount = buffer[2].toInt() and 0xFF if (length < 3 + byteCount + 2) { return null // 还没收完整，继续等 } val calCrc = crc16(buffer, length - 2) val recvCrc = ((buffer[length - 1].toInt() and 0xFF) shl 8) or (buffer[length - 2].toInt() and 0xFF) if (calCrc != recvCrc) { return null // CRC校验失败，丢弃或记录 } val values = ArrayList<Int>() for (i in 0 until byteCount step 2) { val high = buffer[3 + i].toInt() and 0xFF val low = buffer[4 + i].toInt() and 0xFF values.add((high shl 8) or low) } return ModbusData(slaveId, function, values) } fun crc16(data: ByteArray, length: Int): Int { var crc = 0xFFFF for (i in 0 until length) { crc = crc xor (data[i].toInt() and 0xFF) for (j in 0 until 8) { crc = if (crc and 1 != 0) { (crc ushr 1) xor 0xA001 } else { crc ushr 1 } } } return crc } }

读取线程要注意粘包和断包。串口数据不是一个帧一个帧整齐到达的，可能是两个帧粘在一起，也可能一个帧被拆成多次读。我习惯的处理方式是用一个ByteArrayOutputStream做临时缓冲，不断往里追加数据，然后尝试解析；解析成功就把帧头消费掉，解析失败则等更多数据。如果长时间解析不成功，比如超过500ms，就主动清空缓冲，防止坏数据堆积导致后续全部错乱。

CRC16校验是这层逻辑里最重要的一环。Modbus RTU的CRC算法是查表或者移位异或，上面代码是移位异或的实现，依赖0xA001这个多项式。别小看这两行校验，RS485通信在车载环境里受干扰是常态，没有CRC校验，光靠肉眼比对数据根本不知道哪一帧是错的。加了CRC，错误的帧直接丢弃，最多丢数据，不会拿错误数据去做控制决策。

6. 高频问题排查实录：打不开、乱码、烧写失败、驱动不识别

6.1 串口打不开/节点缺失：从日志到权限的排查顺序

串口打不开是最常见的问题，也是最好排查的问题。我自己的固定套路是：先用adb shell进系统，依次执行下面几条命令：

ls -l /dev/ttyS* getenforce dmesg | grep -i uart

ls看节点是否存在、权限是多少，getenforce看SELinux是否拦截，dmesg看内核里UART驱动有没有注册成功。如果节点根本不存在，那就不是权限问题，是内核配置问题，去改dts。如果节点存在但权限是crw-rw----且属主是root，普通App肯定打不开，先临时chmod验证，再决定是改init.rc还是做串口守护进程。

还有一种情况是设备节点被别的进程占用。Android系统里可能有某个系统服务或者vendor进程已经打开了同一个串口，应用再去open就会失败。排查时有两条思路：一是看日志，open失败时通常会有Device or resource busy的errno信息；二是用busybox fuser /dev/ttyS1看哪个进程占用，或者lsof直接查。车载设备上很多串口被默认分配给了蓝牙、GPS或Modem，如果你的App要复用同一个节点，先把对应服务停掉或者在方案阶段就把功能串口和系统串口分开。

6.2 数据乱码和粘包：不是所有问题都靠改波特率

乱码这个话题值得单独拎出来说。我见过最典型的误判，是开发者一口咬定波特率没错，但设备就是回乱码。后来拿示波器一量，TXD引脚的信号幅度只有1.8V，而对面设备需要3.3V的高电平，幅度不够自然识别不了。电平问题在车载板上非常常见，特别是SoC现在越来越喜欢用1.8V IO，而外设传感器还是3.3V或者5V逻辑，中间不加电平转换芯片或者转换电路，通信就是不稳定。

接线顺序问题也容易乱码。RS485的A、B线接反，现象是偶尔能收到数据但内容全是错的；RS232的TXD/RXD接反则是完全收不到。调试时先把线序确认三遍，再动软件，能省下一大半时间。

粘包和断包严格说不是“乱码”，而是数据帧的边界问题。车机Android系统存在GC卡顿、线程调度切换，读串口的时序不稳定，如果协议里没有明确的帧头和长度字段，解析代码很容易错位。我的经验是：协议设计阶段就定好“帧头+功能码+长度+数据+校验”的结构，CRC一定要有；解析时用状态机或者缓冲队列，不要用简单的“读固定长度”去赌数据刚好按帧到达。

6.3 串口烧写失败到底怎么回事

“串口烧写失败”这个词在搜索热词里常年居高不下，说明大家都被它坑过。烧写失败常见芯片是STM32、ESP32这一类，本质原因就几类：

• 芯片没进入下载模式。STM32需要拉低BOOT0再复位，ESP32需要在上电时保持IO0为低。很多新手代码编译没问题，但芯片一直运行的是App，串口工具当然连不上。
• 波特率太高。有些下载工具默认921600，如果线材质量差或者干扰强，握手阶段就失败。降到115200一般能解决。
• 线材太长或接触不良。烧写线尽量短，我用过超过一米的杜邦线就容易失败，换短线立刻好。
• 驱动不稳定。用的是CH340还是FT232，先确认电脑识别到了串口，再打开烧写工具，顺序反了偶尔也会握手失败。

在Android车载板子的场景里，烧写失败还得考虑一点：有些SoC的烧写串口和调试串口是同一个物理串口，但下载模式下引脚功能不同，需要拨码或者按住某个按键再上电。遇到烧写失败，先找板子手册，确认进入烧写模式的正确姿势，比反复换波特率有效得多。

6.4 CH340、FT232R、FT231X这些USB转串口驱动的正确打开方式

USB转串口是Android开发者的日常伙伴，CH340和FTDI系列最常见。Windows下CH340基本免驱，偶尔遇到旧系统需要装官方驱动；FT232R、FT231X这类FTDI芯片在Win10/11上可能遇到驱动签名问题，需要去官网下新版本的VCP驱动，别用Windows自动更新的旧驱动。

Linux下CH340一般内核自带ch341模块，插上后lsusb能看到1a86:7523，设备节点是/dev/ttyUSB0。Ubuntu有个经典的坑：brltty服务会抢占ttyUSB0，导致ch340明明识别到了但节点就是起不来。解决方法是sudo apt remove brltty然后重新插拔。

Android设备外接USB转串口时，要确认设备支持USB Host模式，然后在应用里通过UsbManager申请权限。如果你的Android系统本身已经内置了USB串口驱动，会在/dev下生成ttyUSB节点，可以走正常的串口设备访问；如果没有，需要在内核里打开USB_SERIAL、USB_SERIAL_CH341或USB_SERIAL_FTDI相关配置。开发调试阶段还经常用到虚拟串口，Linux下socat -d -d pty,raw,echo=0 pty,raw,echo=0可以创建一对虚拟串口，Windows下可以用Virtual Serial Port Driver，在没有物理串口设备时先把协议栈调通，非常省事。

7. 调试利器与效率提升技巧

7.1 在线调试：minicom、picocom、串口调试助手怎么选

调试工具选对，效率翻倍。Linux和macOS下，我推荐picocom而不是minicom，原因是picocom参数全部走命令行，简单直接：

picocom -b 115200 /dev/ttyUSB0

minicom要进菜单配置串口参数，交互繁琐，更适合需要保存多套配置的重度用户。Windows下常见串口调试助手很多，不用迷信哪个，但至少要有这几项能力：按十六进制发送和显示、支持定时发送、能计算CRC。如果你经常调试Modbus协议，最好选带CRC计算的助手，手算CRC非常容易错。

Android设备内部调试时，可以用adb shell里的工具。系统如果有microcom命令，可以用它直接连串口节点；没有的话可以临时用busybox的microcom。还有一个技巧是写一个极简的Android串口调试App，界面放一个TextView和EditText，数据收发都走同一个JNI库，这个App跑在目标设备上，比电脑接USB线来回折腾更贴近真实场景。

7.2 数据记录仪和日志分析技巧

排查偶发的串口丢帧问题，光靠肉眼盯屏幕是不够的。我建议把串口日志落盘，而且一定要带时间戳。PC端的串口记录仪很多支持导出CSV，Android端可以自己写一个Logger类，每次收到数据把System.currentTimeMillis()和十六进制数据一起追加到文件。

记录文件配合对比非常关键：有时候你以为数据丢了，其实是Android端应用卡顿导致读取不及时，数据还在内核缓冲区里，后面才一次性读上来；有时候设备端根本没发，那是设备或链路的问题。记录两端各自的时间戳和数据，回放时一眼就能定位问题出在发送端还是接收端。

协议设计上可以加一个帧序号。哪怕只是第N帧这个数字，排查问题时都能快速了解丢帧位置。我在一个项目里就是因为没有帧序号，两台设备明明偶发丢数据，却花了三天才定位到是其中一端的发送缓冲被塞满。加了一个两字节的计数器后，丢帧率一看便知，问题立刻浮出水面。

8. 最后想说的几句真话

我自己最早调串口时，也干过拿电脑串口助手一个字节一个字节对数据的蠢事，后来才明白，串口这东西看着简单，真正难的是链路里的每一层：硬件电平、线序、驱动、权限、协议解析，任何一层出了问题，数据都好不了。别急着上代码，先把协议定清楚、把硬件确认完、把工具准备好，再动手写Android端，你会发现串口通信其实很“讲道理”。如果你也在做车载Android串口开发，希望这篇笔记能帮你省下几个通宵。