企业官网建设流程全解析

简介：面向Android底层驱动开发者，这份资料围绕GPS模块的JNI与HAL层实现展开，整理了从Java层到C/C++硬件交互的完整调用链路，涉及GpsInterface、GpsLocationProvider、GpsStatus等关键组件，适合想深入理解定位服务原理或进行驱动移植、调试的工程师。包体共5个文件，约9.28MB，包括2个docx分析文档、1个HAL层参考压缩包、1个构建脚本以及1个示例C源码，文档与代码互相配合，可覆盖源码阅读、编译配置和实际移植场景。已有839人学习，资料源自作者zgkxzx的实践整理，并附有基于Android 2.3的车载导航GPS HAL移植分析，可帮助读者快速搭建GPS底层驱动知识框架，掌握JNI函数实现、HAL接口封装、定位数据上报等核心环节，对未来优化定位性能或拓展Wi-Fi、蓝牙等驱动开发也具参考价值。

1. GPS Android 底层驱动资料：从串口到定位的完整链路，这套源码包能帮你省下什么

做系统集成的工程师基本都有这种体感：GPS 在 Android 里是典型的「看着简单、动起手来全是暗坑」的模块。串口读 NMEA、HAL 层注册、JNI 绑定，任何一环断掉，LocationManager 拿到的要么是空指针，要么是永远转圈的「搜索中」。这份 GPS Android 底层驱动资料把 Kernel 串口驱动、HAL 实现、JNI 绑定到 Framework 回调的完整链路源码放在一起，适合正在做定位功能适配、CTS 一致性测试，或者要在新平台上把 GPS 从零点亮的人。下面按我拆包的实际顺序讲：先看懂分层，再抄三段关键代码，最后把五个翻车现场说清楚。

2. 驱动分层与源码组织：先看懂四层调用链，再动手不迟

GPS 底层驱动不像普通外设驱动那样直接暴露给应用层。Android 对定位模块做了四层切分，任何一层出问题，表象都是「定位没反应」或「定位永远搜索中」。这也是为什么这套资料把源码按层整理，而不是按文件堆在一起。花半小时把层次关系理清，后面移植至少能省一半排错时间，尤其是当你面对一个从未接手过的芯片平台时。

2.1 四层架构：Kernel、HAL、JNI、Framework 各自管什么

先明确一个事实：绝大多数 GPS 芯片走 UART 口输出 NMEA 数据，内核层往往不需要额外写一个字符驱动，直接复用 kernel 自带的 serial 驱动即可。真正需要你在内核侧动手的是设备树里的引脚复用（pinctrl）、供电 GPIO 和复位脚配置。HAL 层是 Android 定义的硬件抽象接口，厂商实现一个共享库 gps. .so，放进 /vendor/lib/hw 或 /system/lib/hw，它负责打开串口、启动读线程、解析 NMEA，并通过 GpsCallbacks 回调结构往上层回报位置和状态。JNI 层则是 Framework 的 GpsLocationProvider 与 HAL 之间的桥，JNI 文件里调用 hw_get_module 拿到 GpsInterface 指针，再把 Java 层的回调翻译成 C 层的回调函数指针。最上层 Framework 的 LocationManagerService 负责把 JNI 上报的原始数据整理成 android.location.Location 分发给应用。

数据流向是 GPS 芯片 → 串口 → HAL 读线程 → JNI → Framework，控制流向反过来。所以排查问题的顺序永远是自底向上：先看内核设备节点有没有字节出来，再看 HAL 有没有解析出 fix，最后才轮到 JNI 和 Framework。我在实际移植时见过有人在上层 Java 代码里查了半天，最后发现是串口波特率配错，底层一帧有效数据都没有，这种错位排查非常浪费时间。

2.2 源码包的文件清单与推荐阅读顺序

资料拿到手，别急着打开文件就啃。先把目录结构过一遍，我拆的这份包里目录组织大致如下：

推荐阅读顺序是：先读 hal/gps_hal.h，搞清楚 GpsInterface 里每个函数指针的职责，包括 init、start、stop、delete_aiding_data、inject_time 这些基本项；然后读 gps_hal.c 里的 init 和 start，重点看串口打开和读线程是怎么起的；接着跳到 jni 目录，找到 hw_get_module(GPS_HARDWARE_MODULE_ID) 的调用位置，理解 JNI 如何拿到 HAL 接口；最后回来看 framework 层的回调处理。dts 和调试脚本在遇到具体问题的时候再翻，第一遍不用通读，通读反而容易陷入细节。

2.3 为什么移植的第一刀必须切在 HAL 层

很多人拿到源码包后的第一反应是去改 JNI 或 Framework，因为上层代码看起来更「像 Android」。但实际换平台移植时，变化最大的恰恰是 HAL 层：串口设备名不同、波特率不同、NMEA 输出语句集不同、供电和复位 GPIO 不同。JNI 和 Framework 的接口是 Android 系统定死的，基本不用动，真正需要返工的地方全在 HAL。

我一般会先落实三件事，否则后面必然翻车。第一，确认目标平台 GPS 芯片对应的串口节点是 /dev/ttyS 几还是 /dev/ttyMT 几，用 getprop 和 dmesg 查内核注册结果。第二，确认芯片默认波特率和输出的 NMEA 语句集合，很多芯片上电默认 9600，但也有出厂配置成 115200 的。第三，确认供电和复位引脚的 GPIO 编号，漏掉这个会出现上电无输出或休眠唤醒后模块死掉。这套资料的 docs 目录里通常记录了一台参考设备的完整移植过程，照着它的检查清单走，比自己从零读代码快得多，尤其是第一次接触某类芯片时。

3. 移植实战：HAL 层注册与 JNI 绑定，三段可直接抄的代码

这一章把最核心的三段代码拆开讲透。第一段是 HAL 模块的注册骨架，第二段是 JNI 侧的方法绑定，第三段是编译脚本。三段代码在多数 Android 版本上通用，需要改的只有类名、接口名、串口参数这几个位置。别小看这几段，很多移植工程卡住一周，问题就出在 HMI 符号名或 JNI 签名对不上。

3.1 HAL 模块的 hw_module_t 定义与 open 流程

HAL 能被 hw_get_module 加载，靠的是一个全局 hw_module_t 结构体和一个标准 open 函数。Android 的硬件抽象层有约定：每个模块必须导出名为 HAL_MODULE_INFO_SYM 的符号，hw_get_module 底层用 dlopen 加 dlsym 找到它，再调 open 拿到设备句柄。

/* gps_hal.c - HAL 模块入口，Android 约定导出 HMI 符号 */ #include <hardware/hardware.h> #include <hardware/gps.h> static int gps_open(const hw_module_t* module, const char* name, hw_device_t** device); /* 模块 ID 必须是 "gps"，hw_get_module 靠它索引 */ static struct hw_module_methods_t gps_module_methods = { .open = gps_open, }; /* HAL_MODULE_INFO_SYM 是系统约定的导出符号名，写错就加载失败 */ struct hw_module_t HAL_MODULE_INFO_SYM = { .tag = HARDWARE_MODULE_TAG, .id = GPS_HARDWARE_MODULE_ID, /* 即 "gps" */ .name = "GPS HAL module", .methods = &gps_module_methods, }; static int gps_open(const hw_module_t* module, const char* name, hw_device_t** device) { gps_device_t* dev = (gps_device_t*)calloc(1, sizeof(gps_device_t)); if (!dev) return -ENOMEM; dev->common.tag = HARDWARE_DEVICE_TAG; dev->common.version = GPS_DEVICE_API_VERSION; /* 跟随 Android 版本走 */ dev->common.module = (hw_module_t*)module; /* 上层最终通过 get_gps_interface 拿到 GpsInterface 指针 */ dev->get_gps_interface = gps_get_gps_interface; *device = (hw_device_t*)dev; return 0; }

这里的调用链是：SystemServer 启动 LocationManagerService 时，JNI 侧调用 hw_get_module("gps")，系统按候选名依次尝试 dlopen /vendor/lib/hw/gps.default.so 或 gps. .so，找到 HMI 符号后调用 open，拿到 gps_device_t，再通过 get_gps_interface 取出 GpsInterface。最容易翻车的是两个地方：一是 HMI 符号名被编译器加了下划线前缀或改名，二是 .id 字段写错导致索引不匹配。编译完后可以用 nm -D 查一下 so 里导出的符号，确认 HAL_MODULE_INFO_SYM 存在。

3.2 JNI 侧 RegisterNatives 的绑定写法

JNI 侧的关键不是业务逻辑，而是绑定方式。源码包里用的是 RegisterNatives 动态注册，比静态的 JNI_OnLoad 里逐字拼接函数名要稳得多，因为函数名一旦被 C++ 编译器 name mangling 处理过，静态匹配极易失败。

/* com_android_location_GpsLocationProvider.cpp */ static const GpsInterface* sGpsInterface = NULL; static jboolean android_location_GpsLocationProvider_init(JNIEnv* env, jobject obj) { const hw_module_t* module = NULL; /* 第一步：按模块 ID 加载 HAL 库 */ if (hw_get_module(GPS_HARDWARE_MODULE_ID, &module) != 0) { return JNI_FALSE; } /* 第二步：打开设备，取出 GpsInterface */ gps_device_t* dev = NULL; if (module->methods->open(module, GPS_HARDWARE_MODULE_ID, (hw_device_t**)&dev) != 0) { return JNI_FALSE; } sGpsInterface = dev->get_gps_interface(); return (sGpsInterface != NULL) ? JNI_TRUE : JNI_FALSE; } /* 签名表：字符串必须与 Java 声明完全一致 */ static const JNINativeMethod gMethods[] = { { "nativeInit", "()Z", (void*)android_location_GpsLocationProvider_init }, { "nativeStart", "()Z", (void*)android_location_GpsLocationProvider_start }, }; extern "C" jint JNI_OnLoad(JavaVM* vm, void* reserved) { JNIEnv* env = NULL; if (vm->GetEnv((void**)&env, JNI_VERSION_1_6) != JNI_OK) return JNI_ERR; jclass clazz = env->FindClass("com/android/location/GpsLocationProvider"); if (clazz == NULL) return JNI_ERR; if (env->RegisterNatives(clazz, gMethods, NELEM(gMethods)) < 0) return JNI_ERR; return JNI_VERSION_1_6; }

JNI 方法签名是有讲究的：()Z 表示无参数、返回 boolean；()V 表示无参数、无返回；如果要传 String 参数就是 (Ljava/lang/String;)V。签名写错不会在编译期报错，而是运行时抛 UnsatisfiedLinkError，这类问题我后面在避坑章节里会细说。另一个坑是 FindClass 的路径必须和 Java 包路径完全一致，斜杠分隔，改了包名忘记同步这里，NoClassDefFoundError 立刻出现。

提示：换 Java 文件名或包名后，强制先改 JNI_OnLoad 里的 FindClass 字符串和 gMethods 签名表，再改 Java 本体，这个顺序能少踩两个雷。

3.3 Android.mk 与模块安装路径：让系统找到你的 so

代码写完之后，编译脚本和安装路径决定系统能不能在运行时找到模块。Android 对 HAL 库的查找路径有硬性约定，模块必须落在 hw 子目录。

# Android.mk - HAL 模块编译脚本 LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) # 产物名 gps.default.so，default 是兜底名 LOCAL_MODULE := gps.default # 关键：必须放到 hw 目录，否则 hw_get_module 找不到 LOCAL_MODULE_REL_PATH := hw LOCAL_SRC_FILES := gps_hal.c LOCAL_SHARED_LIBRARIES := liblog libcutils libhardware LOCAL_MODULE_TAGS := optional include $(BUILD_SHARED_LIBRARY)

LOCAL_MODULE 的命名规则是 gps. ，hw_get_module 会按 ro.hardware.gps、ro.hardware 的顺序拼候选名去尝试，最后才试 gps.default。LOCAL_MODULE_REL_PATH := hw 决定 so 安装到 /vendor/lib/hw 还是 /system/lib/hw，具体看 PRODUCT_VENDOR_KERNEL 之类的配置。手动验证时可以直接 adb push gps.default.so 到对应目录，重启 system_server 观察日志，不用整机编译，这个做法在调试阶段非常省时间。

4. 串口读取与 NMEA 解析：GPS 驱动真正干活的地方

HAL 层真正的业务集中在两块：串口字节的读取，和 NMEA 语句的解析。这两块做扎实了，上层几本不用动。反过来，如果这里偷懒，比如只解析 GGA 不解析 RMC，就会出现定位点能出来但速度方向全为 0 的诡异现象。

4.1 串口打开与参数设置：8N1 不是玄学

GPS 芯片的 UART 默认参数绝大多数是 9600 波特率、8 数据位、无校验、1 停止位，即常说的 8N1。换平台时第一件事就是确认这个参数，因为有些芯片默认输出是 115200，配错了读出来的字节流全是乱码，且没有任何报错。

/* gps_uart.c - 串口打开与参数配置 */ static int gps_uart_open(const char* dev_path, int baudrate) { int fd = open(dev_path, O_RDWR | O_NOCTTY); if (fd < 0) { ALOGE("open %s failed: %s", dev_path, strerror(errno)); return -1; } struct termios cfg; memset(&cfg, 0, sizeof(cfg)); tcgetattr(fd, &cfg); /* 波特率按传入参数从常量表取值 */ speed_t speed = B9600; if (baudrate == 115200) speed = B115200; else if (baudrate == 38400) speed = B38400; cfsetispeed(&cfg, speed); cfsetospeed(&cfg, speed); /* 8N1：8 数据位、无校验、1 停止位 */ cfg.c_cflag &= ~CSIZE; cfg.c_cflag |= CS8; cfg.c_cflag &= ~PARENB; cfg.c_cflag &= ~CSTOPB; cfg.c_cflag |= (CLOCAL | CREAD); /* raw 模式：避免终端驱动拦截控制字符 */ cfmakeraw(&cfg); tcsetattr(fd, TCSANOW, &cfg); return fd; }

这里有两个参数容易忽略。一是 CLOCAL | CREAD，CLOCAL 避免串口被挂起时收到 SIGHUP，CREAD 启用接收器，少了它 read 永远返回 0。二是 cfmakeraw，它把输入输出都设为 raw 模式，否则 0x1A 之类的字节会被终端驱动当控制字符吞掉。读取线程我一般用阻塞读加 poll 超时的组合，而不是非阻塞轮询，后者会把 CPU 打满，在低功耗设备上尤其不能接受。读线程循环里拿到一行就以 \r\n 为界切出来，逐条交给解析器。

4.2 NMEA 语句的最小解析：RMC 与 GGA 各管一摊

NMEA 协议里跟定位最相关的是 RMC 和 GGA。RMC 给出经纬度、速度、航向和定位状态，GGA 给出海拔、卫星数和精度因子。HAL 至少要解析这两个，GSV 只是卫星视图，Framework 拿它画天空图用，驱动层可以不处理。

/* nmea_parser.c - RMC 解析最小实现 */ #include <stdio.h> #include <string.h> /* 兼容旧协议 GPRMC 与新协议 GNRMC */ static int parse_rmc(const char* line, gps_msg_t* msg) { if (strncmp(line, "$GPRMC,", 7) != 0 && strncmp(line, "$GNRMC,", 7) != 0) { return -1; } /* 跳过 "$GPRMC," 前缀，从时间字段开始解析 */ const char* p = strchr(line, ',') + 1; char time_buf[16]; char status; double lat_raw, lon_raw, speed; char ns, ew; /* 对应字段：时间,状态,纬度,NS,经度,EW,速度 */ int matched = sscanf(p, "%15[^,],%c,%lf,%c,%lf,%c,%lf", time_buf, &status, &lat_raw, &ns, &lon_raw, &ew, &speed); if (matched < 7) return -1; /* A=有效定位，V=未定位，直接丢弃 */ if (status != 'A') return 0; /* NMEA 纬度格式是 ddmm.mmmm，需拆成度分再转十进制度 */ int lat_deg = (int)(lat_raw / 100); msg->lat = lat_deg + (lat_raw - lat_deg * 100) / 60.0; int lon_deg = (int)(lon_raw / 100); msg->lon = lon_deg + (lon_raw - lon_deg * 100) / 60.0; if (ns == 'S') msg->lat = -msg->lat; if (ew == 'W') msg->lon = -msg->lon; msg->speed = speed; /* 单位是节，Framework 层再转 m/s */ return 1; }

这段解析里有三个细节值得注意。第一，格林尼治时间字段在这里取出来就能用，但要转本地时间得在 Framework 层做，驱动里不要动时区。第二，纬度 4807.038 表示 48 度 07.038 分，转十进制度要拆成度加分除以 60，这个转换错一位，位置能偏出上百公里。第三，status 是 A 才上报，V 状态直接丢弃，否则 Framework 会收到一堆无效位置拉低定位体验。新出的芯片很多输出 GNRMC 而不是 GPRMC，解析器两个都要认，这也是常见的兼容性坑。

4.3 数据上抛：回调、事件与 Binder 怎么选

驱动层往上层抛数据，最标准的路径是 GpsCallbacks 回调结构体。HAL 在 init 时从 JNI 拿到一组函数指针，读到有效 fix 后直接调用 location_cb，把填充好的 GpsLocation 结构体传上去。JNI 侧在这个回调里用 env->CallVoidMethod 触发 Java 层的 locationChanged 方法。

/* gps_hal.c - 位置回调上报示例 */ static void on_location_fix(const GpsLocation* loc) { if (gps_callbacks.location_cb) { gps_callbacks.location_cb(loc); } } /* 读线程里解析出有效 fix 后调用 */ static void handle_nmea_line(const char* line) { gps_msg_t msg; if (parse_rmc(line, &msg) == 1) { GpsLocation loc; memset(&loc, 0, sizeof(loc)); loc.size = sizeof(loc); loc.latitude = msg.lat; loc.longitude = msg.lon; loc.speed = msg.speed * 0.51444f; /* 节转米每秒 */ loc.flags |= GPS_LOCATION_HAS_LAT_LONG | GPS_LOCATION_HAS_SPEED; on_location_fix(&loc); } }

回调是驱动层唯一需要关心的上抛方式。事件队列是 Framework 内部消化数据用的，Binder 则是应用层与 system_server 之间的事，驱动层碰不到。有一个常见误用是有人在 HAL 里自己开 Binder 客户端往应用层直传数据，这在架构上是绕过了系统位置服务，既拿不到权限校验也过不了 CTS，正路永远是乖乖走 GpsCallbacks。

5. GPS 驱动移植避坑与常见问题排查：五个翻车现场

这一章全是实战里反复出现的坑，每一条我都按「现象 → 原因 → 解决」的顺序写。你在移植时遇到类似日志，可以直接对号入座。

5.1 串口设备打不开：节点权限与 SELinux 策略

现象：HAL 日志打印 open /dev/ttyS3 failed: Permission denied 或 No such file or directory，上层一直显示 Initializing，串口节点在 shell 下 root 能开，但 system_server 进程开不了。

原因：新平台没在 ueventd.rc 里给串口节点分配 group 和权限，导致非 root 进程无读写权限；或者 SELinux 处于 Enforcing 模式，gps 域没有被放行访问 tty_device 类型的 chr_file。

解决：先 adb shell ls -l /dev/ttyS3 看属主和权限，再用 getenforce 确认 SELinux 状态。常规修法是改 ueventd.rc 加一行 /dev/ttyS3 0660 radio radio，并在 sepolicy 里给 gps 域补 allow gps_t tty_device:chr_file { open read write ioctl }。改完 push 后重启再验证。这里有个细节：有些平台串口节点注册在 /dev/ttyS 下，有些是 /dev/ttyMT，找错前缀也是 No such file 的来源之一，用 dmesg | grep tty 看内核实际注册的是哪个节点。

5.2 Native 方法找不到：JNI 签名与类名不一致

现象：开机 logcat 报 UnsatisfiedLinkError: No implementation found for boolean com.android.location.GpsLocationProvider.nativeInit()，但 so 文件确认已经 push 进系统目录。

原因：Java 层的方法声明与 RegisterNatives 里写的签名不一致，最常见的是返回类型写错，或者方法名大小写不对；另一种可能是 FindClass 的路径与实际包名不符，RegisterNatives 拿到的是空 clazz。

解决：用 javap -s -p 反编译 jar 里的 GpsLocationProvider.class，把真实签名抄出来和 gMethods 表逐字符比对。检查 FindClass 的路径是否用斜杠且大小写正确。还有一招：在 JNI_OnLoad 里加 ALOGI 打印 FindClass 和 RegisterNatives 的返回值，返回值小于 0 就说明绑定没成功，能精确定位问题在哪一步。

5.3 HAL 模块加载失败：模块名与编译路径

现象：logcat 报 hw_get_module: module id "gps" not found，或者直接 -ENOSYS，getgpsinterface 拿到空指针。

原因：so 文件名不在 hw_get_module 的候选列表里。Android 会按 gps.<ro.hardware.gps>、gps.<ro.hardware>、gps.default 的顺序找，文件只有 gps.default.so 但 ro.hardware 被设成了别的值，且没写 default 的情况之下就会失败。另一个原因是 LOCAL_MODULE_REL_PATH 没设 hw，so 被装到了普通 lib 目录。

解决：先 getprop ro.hardware.gps 和 getprop ro.hardware 看候选名，再 ls /vendor/lib/hw 确认实际文件名。手动验证时直接 adb push gps.default.so 到 /vendor/lib/hw，重启 system_server 再看日志。编译脚本里 LOCAL_MODULE_REL_PATH 这个变量一定不能省，少了它问题非常隐蔽，因为编译不报错，只有运行时找不到。

5.4 有数据但解析不出定位：波特率与语句名的玄学

现象：串口明显有字节流，HAL 日志也打印了原始行，但解析状态一直是 V，定位点一个都出不来。拿串口抓的原始数据肉眼一看全是乱码或奇怪的半截语句。

原因：第一嫌疑是波特率不匹配，芯片输出 115200 但 HAL 按 9600 收，字节流被拆得乱七八糟；第二是 NMEA 语句头不匹配，新版芯片输出了 GNRMC 而解析器只认 GPRMC；第三是校验和不过，数据在传输中丢了字节，解析器发现校验失败直接丢弃整条语句。

解决：先在 HAL 里把原始字节流完整打日志，不要解析就输出，肉眼对比逻辑分析仪抓到的波形，确定真实波特率。多数芯片支持上电后通过 AT 指令或厂商私有命令配置输出频率和波特率，在 HAL init 里发一次配置命令即可。语句头兼容问题，把 GPRMC 和 GNRMC 都纳入解析。校验和问题，把解析器的校验和对不上的行单独打日志，看是不是固定丢某个字节，如果是，大概率 UART 的 FIFO 或 DMA 配置有误。

提示：调试串口 GPS 时，先把 ALOG 的原始数据日志打开，这一步能过滤掉 80% 的猜测空间。看不见原始字节就谈解析，纯属猜。

5.5 休眠唤醒后 GPS 失效：电源与 GPIO 的隐性坑

现象：系统休眠再唤醒后，位置一直停在 searching 状态，或者回调彻底不再触发，只有重启才能恢复。

原因：电源管理框架在休眠时把 GPS 芯片的供电 LDO 关了，或者把 UART 的 TX/RX 引脚复用成了别的功能；HAL 的读线程随进程挂起后没有在唤醒时重新初始化芯片。

解决：在 HAL 的 start 里做完整的电源时序，唤醒后重新拉高复位脚、等待芯片 ready、重新发送配置命令。设备树里要把 UART 引脚配置为保持（pull 状态不变），供电 LDO 的 suspend 策略改成不关或者加一个 wakelock 保护。这个坑最容易在量产阶段爆发，因为休眠场景工程师测试时常常不覆盖，用户实际使用中锁屏一段时间再解锁就中招。

6. 进阶验证：用模拟 NMEA 数据把全链路跑通

没有真实 GPS 信号或天线环境受限时，有一个非常实用的技巧：往串口注入模拟 NMEA 数据，验证 HAL 到 Framework 的整条链路是否健康。这个动作能把「驱动代码问题」和「射频天线问题」干净利落地切分开。如果你在室内或者板子上还没接 GPS 模块，这个方法能让驱动的调试完全不依赖硬件。

第一步，确认 HAL 的串口路径。把 gps_hal.c 里的 dev_path 临时指向一个伪终端，或者直接用 USB 转串口把 PC 和目标板的 RX 对接。我一般用 Python 在开发机上开一个 pty，生成一条持续输出的模拟 RMC 语句：

# fake_gps.py - 在开发机上开伪串口，每秒发送一条模拟 RMC import os, pty, time master, slave = pty.openpty() print("slave 端:", os.ttyname(slave)) # 形如 /dev/pts/3 rmc = b"$GNRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A\r\n" while True: os.write(master, rmc) time.sleep(1)

把 HAL 里的设备路径改成这个 slave 端，或者把目标板的串口 RX 接到 PC 的 USB 转串口上，用 cat 命令直接注入同一句话。第二步，观察定位结果：adb logcat -s GpsHAL 看 HAL 有没有解析出 fix，再 adb shell dumpsys location 看 system_server 有没有拿到最新的 Location 对象。三层都有输出，说明 HAL、JNI、Framework 链路是全通的，问题一定在射频或天线侧。第三步，验证完记得把 HAL 里的调试注入代码删干净，换回真实串口路径，别带着 mock 代码进生产版本。

要注意模拟数据的校验和必须是正确的，这条经典 RMC 语句的校验和是 6A，写错了解析器会直接丢包，反而误导你以为是链路有问题。更稳妥的做法是先让解析器把校验和计算结果打日志，和 * 后面的值比对，一致才继续往下走。

从那以后我每次移植 GPS，第一件事永远是先把模拟注数据的环境搭好，确认上层链路全通，才去碰真实模块。这样真信号没出来时，排错范围立刻缩小到射频、天线和供电三件事上，不再被「驱动到底写没写对」这种问题反复折磨。希望帮到你。

本文还有配套的精品资源，点击获取