简介面向安卓系统底层开发者的全球定位系统驱动分析资料核心围绕Java本地接口JNI与硬件抽象层HAL重点解决上层框架与底层硬件之间交互的认知与调试问题。压缩包共5个文件、约9.28MB包含2份分析文档、1个源码压缩包、1个构建脚本以及1个C语言示例文件文档侧重原理梳理与硬件抽象层移植过程源码提供可对照阅读的实际实现。已有838人学习/下载适合想从框架源码层面理解位置服务、优化或移植定位驱动的中高级开发者。内容深入解析定位服务相关接口、定位提供者、状态回调等关键组件展示了从Java本地接口定义到底层硬件抽象层函数调用、再到定位数据上报的完整链路并附有2.3版车载导航场景下的硬件抽象层移植分析。1. GPS Android 底层驱动资料附关键源码到底在解决什么问题第一次拿到 GPS Android 底层驱动资料附关键源码时不要急着把里面每个 .c 文件都编译一遍。这套东西解决的核心问题是GPS 模块输出的原始定位数据怎样经过 Linux 串口驱动、Android HAL 和 JNI最终变成应用层 LocationManager 里一个可用坐标。很多开发者的误区是直接拿串口工具或 NMEA 分析仪去测模块模块明明输出正常App 里却一直显示定位失败于是怀疑硬件坏了。实际上问题通常出在内核设备树没配串口、HAL 打开错设备节点、或是 JNI 回调没有注册。适合读这篇内容的是做 Android 系统移植、驱动开发、以及需要自己定制 GPS 定位器硬件方案的人。看完这篇你能知道改哪几个文件、按什么顺序验证而不是把时间浪费在玄学层面。2. GPS 硬件链路与内核驱动从 UART 字节流到可用的 NMEA 定位语句GPS 模块在 Android 系统里不是应用直接读串口的。模块上电后按 NMEA 0183 协议以文本形式不断输出定位语句比如$GNGGA、$GNRMC。这些文本通过 UART、I2C 或 USB 送到应用处理器内核串口驱动把它注册成/dev/ttyS*、/dev/ttyTHS*或/dev/ttyACM*设备。上层 HAL 再打开这个字符设备按行读取并解析。所以硬件方案选型会直接决定内核驱动怎么配。做 Android 系统集成时第一步永远是看原理图GPS 模块的 TX/RX 接在哪个串口、电平是 1.8V 还是 3.3V、有没有外部 LNA、天线是有源还是无源。这些信息不确认清楚后面所有源码修改都可能是白做。2.1 GPS 定位器硬件方案选型UART、I2C、SPI、USB 怎么选常见的 GPS 定位器硬件方案无非四种接口各有各的适用场景我列一张参数表方便对照接口典型速率数据特点适用场景主要坑UART9600 / 115200 bpsNMEA 文本逐行输出绝大多数 GPS/北斗模块电平不匹配、串口被 console 占用I2C100/400 kHz寄存器式读取NMEA 少见u-blox 等模块的 DDC 模式地址冲突、软件模拟 I2C 不稳定SPI1~8 MHz适合原始观测量输出RTK/高精度定位板卡驱动复杂、需要 DMA 才能不丢数据USB12 Mbps 起模块虚拟成 ACM 设备开发调试、快速验证量产成本高、占用 USB Host做量产 Android 设备我还是建议 UART。GPS 模块的 UART 输出是文本流驱动只要保证字节不丢应用层怎么解析都好办。I2C 和 SPI 看上去速率高但 NMEA 本来就是低速文本杀鸡用牛刀还额外引入驱动复杂度。UART 方案里最容易被忽略的是电平。GPS 模块常用 1.8V 或 3.3V TTL而应用处理器串口可能是 1.8V。如果直接接 3.3V 模块轻则数据乱码重则烧掉主控引脚。我一般在原理图阶段就要求模块厂商标注电平并确认板上有没有做电平转换。这个不是驱动能补回来的问题。2.2 设备树与内核串口驱动最小 dts 片段确定硬件接在哪个 UART 之后改内核设备树。以 i.MX8M Mini 这类常见 Linux 应用处理器为例GPS 接在 uart3设备树里需要把该串口节点打开并把对应的 pinmux 配好。/* 设备树把 uart3 分配给 GPS 模块 */ uart3 { pinctrl-names default; pinctrl-0 pinctrl_uart3; status okay; }; iomuxc { pinctrl_uart3: uart3grp { fsl,pins MX8MM_IOMUXC_ECSPI1_MISO_UART3_DCE_TX 0x1c0 MX8MM_IOMUXC_ECSPI1_SS0_UART3_DCE_RX 0x1c0 ; }; };这段 dts 做的事情有两件第一把 uart3 的status从disabled改成okay让内核串口驱动 probe第二把芯片引脚复用成 UART3 的 TX/RX。0x1c0是引脚配置值包含上拉、驱动能力和施密特触发设置不同平台的 bit 含义不一样不要直接抄别的平台。改完设备树还要确认内核配置打开了对应串口驱动# kernel defconfig 或 menuconfig 中确认 CONFIG_SERIAL_IMXy CONFIG_SERIAL_IMX_CONSOLEy注意CONFIG_SERIAL_IMX_CONSOLE是把它注册成内核 console。如果板子上这个串口同时拿来打印 logcatGPS 驱动和 kernel log 会互相抢数据。我的习惯是 GPS 串口不要开 console宁可让 console 走别的调试口也不要和定位数据混在一起。设备树编译成 dtbo 或 dtb 后可以先用fdtdump或ls /dev/ttyS*确认节点是否生成。如果/dev/ttyS3不存在优先查 dts 是否被覆盖而不是去改 HAL 代码。2.3 NMEA 数据从驱动层冒出来的样子GGA 与 RMC 字段怎么读驱动配好之后最直接的验证方式是串口工具抓数据。GPS 模块定位成功时输出类似这样$GNGGA,092725.00,2233.4626,N,11357.5830,E,1,12,1.0,25.8,M,-3.2,M,,*5A $GNRMC,092725.00,A,2233.4626,N,11357.5830,E,0.0,0.0,010180,,,A*46驱动层不需要解析这些字段它的任务只有一个把从芯片来的字节完整传递给 HAL。真正干活的是 HAL 里的 NMEA 解析器它按$开头、\r\n结尾来切分语句。如果你在做底层驱动至少要看懂 GGA 里的几个关键段纬度、经度、定位质量标识、卫星数、海拔。定位质量标识1表示单点定位4表示 RTK 固定解0表示未定位。很多上层判断是否有定位就是看这个字段而不是看有没有数据。调试底层时我会在串口驱动或 HAL 入口加一个统计值每秒收到多少字节、多少行、多少校验失败。如果字节在涨但行数不涨说明波特率或数据位配置不对字节流是乱的。如果行数正常但校验失败率高那就要怀疑串口电气特性比如地线没共地或者信号线太长。2.4 GPS 模块的天线走线注意事项驱动正常、收星差的第一嫌疑驱动级数据通了不代表定位好。GPS 模块的天线走线注意事项里我踩过的坑比驱动代码还多。天线部分有点玄学很多时候串口数据一直稳定输出但收星数就是上不去定位误差几十米。有源天线要检查 Bias Tee 供电GPS 模块的 ANT_ON 或 VCC_RF 引脚要正确供给 3.3V 或 5V否则内部 LNA 不工作信号直接衰减。无源天线则要保证走线阻抗 50 欧姆尽量短远离高速信号线和 DC-DC 电感。如果 PCB 上 GPS 馈线旁边跑一条 MIPI 或 USB 差分线收星灵敏度会明显下降这种问题驱动层根本查不出来。天线净空区也很关键。陶瓷天线下面不能铺完整地铜皮天线周边要留出净空金属外壳和螺丝柱也会改变天线谐振。我遇到过一次定位慢的返修问题最后发现是结构设计把天线放在两个 USB 金属座中间挪开 1 厘米就好了。这类现象用仪器测模块本身没有意义要拿整机去室外开阔地测确认 SNR 值是否正常。3. Android 定位框架HAL、JNI 与 GnssLocationProvider 的调用链内核的/dev/ttyS3有了 NMEA 数据接下来就是 Android 软件栈的事。应用层调用LocationManager.getLastKnownLocation()拿到的坐标不是直接读串口解析的而是走一条很长的链路HAL 读取串口、解析 NMEA、通过回调上报到 JNIJNI 再转成 Java 层GnssLocationProvider的数据结构。这条链路只要有一层断掉上层就表现为没有定位。很多做应用开发的人不理解为什么 GPS 定位这么慢其实慢不一定在算法而在底层链路没有工作。比如 HAL 层的读线程没起来或者 JNI 的回调指针没有初始化onLocationChanged永远不会触发。这一节把四层链路和关键源码拆开讲。3.1 从 /dev/ttyS3 到 LocationManager四层调用链Android 的 GPS 定位框架分四层我整理了它们的职责和数据流向层级关键文件职责数据形式Linux 内核串口驱动、设备树把 GPS 模块字节流变成字符设备/dev/ttyS3 原始字节HALhardware/libhardware/modules/gps/gps.cpp打开串口、起线程、解析 NMEAGpsLocation 结构体JNIframeworks/base/services/core/jni/com_android_server_location_GnssLocationProvider.cpp把 HAL 回调转成 Java 方法调用jobject 回调Java FrameworkGnssLocationProvider、LocationManagerService管理 Provider 状态、广播位置更新Location 对象这条链路里HAL 是最容易出问题的一层。因为 Android 的 HAL 模块用hw_module_t结构体注册hw_get_module()按硬件 ID 去查找。如果 HAL 的id和系统预期不一致get_gps_interface()根本不会被调用串口当然不会被打开。3.2 HAL 层关键源码打开串口、起线程、按行解析 NMEAHAL 层的标准实现里最重要的两个函数是模块打开函数和读线程函数。模块打开函数要做的是分配gps_device_t并挂上get_gps_interface回调static const char* GPS_DEVICE /dev/ttyS3; static int gps_open(const struct hw_module_t* module, const char* name, struct hw_device_t** device) { struct gps_device_t* dev (struct gps_device_t*)calloc(1, sizeof(*dev)); if (!dev) { return -ENOMEM; } dev-common.tag HARDWARE_DEVICE_TAG; dev-common.version 1; dev-common.module (struct hw_module_t*)module; dev-get_gps_interface get_gps_interface; *device (struct hw_device_t*)dev; return 0; }common.tag必须等于HARDWARE_DEVICE_TAG这是 Android HAL 的硬性要求写错任何一个字节hw_get_module()就会认为设备描述无效。get_gps_interface返回的是一个函数指针表上层后续所有操作都通过这个指针表回调。真正干活的是读线程。GPS 模块上电后会持续吐数据所以 HAL 层必须有一个常驻线程在阻塞读串口static void* gps_reader_thread(void* arg) { int fd open(GPS_DEVICE, O_RDONLY | O_NOCTTY); if (fd 0) { ALOGE(open %s failed: %s, GPS_DEVICE, strerror(errno)); return NULL; } struct termios tty; tcgetattr(fd, tty); cfsetispeed(tty, B115200); cfsetospeed(tty, B115200); tty.c_cflag | (CLOCAL | CREAD); tty.c_cflag ~CSIZE; tty.c_cflag | CS8; tty.c_iflag ~(IXON | IXOFF | ICRNL | INLCR); tcsetattr(fd, TCSANOW, tty); char buf[512]; ssize_t n; while ((n read(fd, buf, sizeof(buf))) 0) { /* 把 buf 按 \r\n 切成完整 NMEA 行再解析 */ feed_nmea_parser(buf, n); } close(fd); return NULL; }这段代码里O_NOCTTY很重要如果不加这个 fd 可能被当成控制终端收到 CtrlC 这类信号字符会有额外处理。cfsetispeed和cfsetospeed把波特率设成 115200要和模块实际输出的波特率一致。GPS 模块默认不一定都是 115200有些是 9600需要在芯片手册里确认。CS8表示 8 数据位c_iflag里的ICRNL必须清零否则回车符会被转成换行符NMEA 行解析会错乱。读线程的线程优先级也值得设高一点。串口数据量不大但如果在读线程里做 NMEA 解析时被打断太频繁缓冲区溢出会丢行。我一般用pthread_setschedparam把读线程设成实时调度队列深度再调大一点避免高负载下丢数据。3.3 JNI 层关键源码回调初始化与线程切换HAL 解析出GpsLocation后通过GpsCallbacks结构体内的函数指针上报。这个结构体在 HAL 初始化时被传入JNI 层负责把 C 函数指针和 Java 方法绑定。JNI 里通常会在JNI_OnLoad阶段缓存 Java 方法 ID避免每次定位回调都去FindClassstatic jmethodID method_reportLocation; JNIEXPORT jint JNICALL Java_com_android_server_location_GnssLocationProvider_init(JNIEnv* env, jobject obj) { jclass clazz env-GetObjectClass(obj); method_reportLocation env-GetMethodID(clazz, reportLocation, (DDDDFIFFFFJ)V); gps_callbacks.location_cb native_location_callback; /* 把 callbacks 传给 HAL */ gps_interface-init(gps_callbacks); return 0; }reportLocation的签名(DDDDFIFFFFJ)V对应 Java 方法里的double, double, double, double, float, int, float, float, float, float, long参数。签名写错运行时直接NoSuchMethodError而且这类错误经常只在真机 GPS 定位成功那一刻才暴露。特别要注意线程切换。HAL 的读线程是 native 线程native_location_callback执行时所在的进程虽然还是 system_server但 JNI 里的JNIEnv是线程绑定的。不能在任意线程里直接调用env-CallVoidMethod必须先用JavaVM-AttachCurrentThread拿到当前线程的JNIEnv。很多移植项目在定位成功后偶发 crash原因就出在这里回调没 attach回调完全不上报或是直接 abort。static void native_location_callback(GpsLocation* location) { JNIEnv* env; jvm-AttachCurrentThread(env, NULL); env-CallVoidMethod(g_loc_provider_obj, method_reportLocation, location-latitude, location-longitude, location-accuracy); jvm-DetachCurrentThread(); }AttachCurrentThread和DetachCurrentThread必须成对出现。如果不 Detach线程退出时JNIEnv没清理轻则内存泄漏重则进程崩溃。这块我建议在初始化时就记清楚所有从 HAL 回调进来的路径统一走同一个 helper 函数做 attach/detach不要每个回调里各写一遍。3.4 Java 层GnssLocationProvider 与 LocationManager 的监听注册JNI 上报到 Java 层后位置数据会从GnssLocationProvider发给LocationManagerService再广播给注册了监听的应用。应用层注册的是 Provider 名称LocationManager lm (LocationManager) getSystemService(Context.LOCATION_SERVICE); LocationListener listener new LocationListener() { Override public void onLocationChanged(Location loc) { double lat loc.getLatitude(); double lng loc.getLongitude(); /* 这里拿到的是底层链路送上来并经过框架处理的坐标 */ } }; if (lm.isProviderEnabled(LocationManager.GPS_PROVIDER)) { lm.requestLocationUpdates(LocationManager.GPS_PROVIDER, 1000L, 0.0f, listener); }这里1000L是最小时间间隔毫秒数0.0f是最小距离变化米数。如果两个都设为 0回调频率会非常高耗电也大。底层驱动开发阶段可以先设成1000L方便观察位置是否刷新。另一个容易踩的是权限问题。Android 6.0 之后访问定位需要动态申请ACCESS_FINE_LOCATION驱动层看不到这个权限但如果 App 没有授予权限上层回调会被拦掉。表现为 dumpsys 里 provider 在运行但 App 收不到位置这种问题不属于底层资源却容易让驱动工程师背锅。4. 关键源码移植改串口、改协议、改电源管理三个必改点拿到一份 GPS Android 底层驱动资料里面通常包含内核设备树、HAL 源码、JNI 修改记录和 gps.conf 配置。但源码不能直接拿去编必须根据你自己的主板做三处修改串口设备名、NMEA 协议配置、电源管理。跳过任何一处板子上电后定位大概率不工作。4.1 源码文件清单先弄清自己的 Android 版本移植前先看系统版本Android 8 之前用的是gps.h这套 HALAndroid 8 以后逐渐迁移到android.hardware.gnss的 HIDL/AIDL 接口。这个判断决定你要改哪一层别拿着一套老 HAL 往新版系统里硬塞。源码位置对应内容移植时需要确认kernel 设备树UART 节点、pinmux、regulator串口号、电平、供电 GPIOhardware/libhardware/modules/gpsHAL 串口读取与 NMEA 解析GPS_DEVICE 常量、波特率hardware/interfaces/gnss 或 libhardware/include/hardware/gps.hHAL 接口定义接口版本是否匹配系统frameworks/base/services/core/jniGnssLocationProvider JNI回调方法签名device/ 厂商目录下的 gps.confAGPS、NTP、XTRA 参数服务器地址、协议版本我做移植的习惯是先把这些文件在源码里找到确认它们真的在自己这份代码树里而不是从别处拷来的碎片。最怕的是vendor目录下有另一份 HAL 覆盖了hardware/libhardware里的实现编译时还编进去了结果你改的文件根本没有生效。4.2 修改设备节点与权限ueventd.rc 和 HAL 常量不同平台 GPS 串口名不一样有些是/dev/ttyS3有些是/dev/ttyTHS2还有的是/dev/ttySC0。先在 adb shell 里确认adb shell ls -l /dev/tty* adb shell cat /proc/tty/driver/serial如果设备树已经 probe串口节点应该存在。接着要保证 HAL 进程有权限打开它。Android 的 ueventd 会在启动时设置设备节点权限默认可能只有 radio 或 system 用户能访问。在 ueventd.rc 里加一行# ueventd.rc /dev/ttyS3 0660 system system如果不加这条HAL 层 open 会返回Permission denied。有时候开发者会直接chmod 777 /dev/ttyS3做验证但这在量产固件里不持久重启就没了。正确做法是把 HAL 进程和 GPS 设备节点放进同一个 group。HAL 常量也得同步改。前面例子里的GPS_DEVICE是写死的字符串换成你的实际串口名。我一般会在 HAL 里支持用系统属性覆盖static const char* gps_device_path(void) { const char* p property_get(vendor.gps.tty); return (p *p) ? p : /dev/ttyS3; }这样在调试阶段可以用adb shell setprop vendor.gps.tty /dev/ttyTHS2动态切换不用每次改代码重编。方便归方便量产前一定要把错误属性清理掉否则用户开了开发者模式后改了属性会导致定位时好时坏。4.3 修改 NMEA 协议与 gps.conf 配置大部分消费级 GPS/北斗模块输出的是标准 NMEA 0183但有些模块支持扩展语句比如输出原始载波相位。驱动资料里如果带了 gps.conf要注意里面几个全局参数# gps.conf 常见配置 NTP_SERVERcn.pool.ntp.org SUPL_HOSTsupl.google.com SUPL_PORT7276 GPS_PROTOCOL1NTP_SERVER用于冷启动时获取时间时间不准会直接影响星历下载和定位解算。GPS_PROTOCOL在不同平台含义不同有的表示 NMEA 版本有的表示是否启用私有协议。如果模块支持北斗还要确认 NMEA 语句前缀GNGGA是北斗GPS 双系统GPGGA只有 GPS。HAL 里的解析器如果只认GPGGA双模模块输出的GNGGA会被丢弃定位永远出不来。还有一个隐蔽的问题是 NMEA 版本。老的模块输出 V2.3新模块输出 V4.0。V4.0 里卫星系统标识字段更丰富但有些解析器不认。这属于协议边界最好的验证方法是抓一段模块实际输出用 HAL 的代码跑一遍看能解析出几条定位语句。4.4 电源与 GPIO冷启动失败的常见原因GPS 模块上电时序没做好冷启动会一直失败。很多模块除了 VCC还要一个复位脚或使能脚驱动必须按芯片手册要求拉高或拉低。设备树里可以用regulator-fixed描述 GPIO 电源gps_power: gps_power { compatible regulator-fixed; regulator-name gps_3v3; regulator-min-microvolt 3300000; regulator-max-microvolt 3300000; gpio gpio1 14 GPIO_ACTIVE_HIGH; enable-active-high; regulator-boot-on; };然后给 UART 节点加上vmmc-supply或自定义的vb-supply属性让串口驱动 probe 时自动给 GPS 模块上电。如果忘了regulator-boot-on模块可能在驱动打开串口前还没上电数据自然来不了。更麻烦的是休眠唤醒。有些板子在灭屏后会把 GPS 的供电和串口时钟都关掉恢复后定位模块要重新冷启动。这个不一定是 bug也许是省电策略。但如果你希望定位一直在线就要在内核电源管理里把对应的power-domains或runtime_pm关掉。做法是在设备树里对 GPS 串口节点加power-domains pd_always_on不同平台写法差异很大我这里只能说思路具体的 phandle 要看 SoC 的手册。5. GPS Android 底层驱动常见问题避坑现象、原因、解决下面这几条是我在多个项目里实际踩过的坑每一条都按现象、原因、解决三个步骤写。排查 GPS 驱动问题时我不建议一上来就翻源码先按现象分类能省很多时间。5.1 fake gps location 能改定位说明底层驱动没事现象App 用 fake gps location 修改定位后地图 App 立刻显示到新地点但系统自带 GPS 还是显示真实位置或无法定位。于是有人判断底层驱动坏了因为连 fake gps 都能改底层肯定没工作。原因fake gps location 走的是LocationManager的模拟位置 Provider。系统开启了选择模拟位置信息来源后这类 App 会通过setTestProviderLocation直接把位置注入到LocationManagerService完全不经过 HAL也不经过 GPS 芯片。它生效只能说明应用层框架正常和底层驱动没有半毛钱关系。解决用adb shell settings get secure mock_location查看模拟位置是否开启或者直接关掉所有模拟位置来源。然后看adb shell dumpsys location | grep GPS里 provider 状态。如果 provider 显示NO_FIX那才说明底层没有有效定位。5.2 串口能抓到 NMEA上层还是 0 颗星现象用串口工具接 GPS 模块的 TX/RX能看到连续的$GNGGA里面有经纬度和卫星数。但 Android 系统里StatusBar的定位图标不亮打开测试 App 显示 0 颗星。原因数据在模块和应用处理器之间通了但 HAL 没有读到。常见原因有三个一是 HAL 打开的设备节点不是内核实际注册的那个二是 ueventd.rc 没给权限三是 HAL 进程根本没有被加载hw_get_module返回 null。解决先在 HAL 里加 log确认 open 的返回值。不要光看源码别的 device 节点。然后确认adb shell ls -l /dev/ttyS3 adb shell dumpsys activity service com.android.location.fused adb logcat -s GnssLocationProvider如果 open 返回Permission denied看 ueventd.rc。如果 logcat 里根本没有 HAL 初始化日志看hardware/libhardware/modules/gps是不是被编译进了系统镜像有时 Vendor 分区里有旧版本会覆盖新版本。5.3 GPS 误差大先查天线和参考点别急着动源码现象定位可以成功但坐标偏差 30 米以上在一个固定点反复横跳。很多人第一反应是修改 NMEA 解析或者给坐标加偏移这是把现象当成原因了。原因GPS 误差来自三个大头一是多径效应城市峡谷里信号反射导致伪距测量偏差二是 AGPS 辅助数据过期星历不准三是天线周边环境差。模块本身在没有遮挡的开阔地通常能到 2~5 米精度。如果整机测试老是偏差巨大嫌疑最大的是天线。解决把设备拿到室外开阔地远离高楼和金属围栏放 10 分钟看稳定后的位置和地图实际点的距离。再用adb logcat -s NmeaParser或 GNSS 原始数据看卫星信噪比。如果C/N0大于 35 的卫星少于 4 颗问题就在 RF 前端查 GPS 模块天线走线注意事项里的净空、阻抗和干扰源。驱动代码在这种场景下基本不用动。5.4 灭屏休眠后定位冻结电源管理把串口关了现象亮屏时定位正常灭屏 5 分钟后位置不再更新重新亮屏后过几秒才恢复。App 里没有崩溃日志也没有异常。原因这是内核电源管理在起作用。灭屏后 SoC 进入低功耗状态GPS 串口对应的时钟被 gate或者 GPIO regulator 被关掉模块断电后重新上电需要重新冷启动。如果 HAL 线程还在阻塞 read时钟 gate 后 read 不会返回但也没有新数据进来。解决先通过adb shell cat /sys/kernel/debug/clk/clk_summary | grep uart看串口时钟在灭屏后是否被关。如果被关检查设备树里串口节点的power-domains和clock属性不要把 GPS 串口归到默认的power-domains下。这块我建议使用内核的 runtime PM 机制在 HAL 层打开设备时pm_stay_awake关闭时pm_relax。如果不方便改内核可以在 dts 里增加wakeup-source属性但前提是平台支持。5.5 移植 android studio 项目时 HAL 接口版本不匹配现象把一个旧项目的 GPS 驱动源码移植到新平台编译能过但运行到定位时HAL module找不到或者报IGnss服务无法注册。在 android studio 里看 logcat只看到gnss service not available。原因Android 的 GNSS HAL 在演进。早期是hardware/libhardware/include/hardware/gps.h的GpsInterface后来变成了android.hardware.gnss1.0的 HIDL 服务再往后是 AIDL。旧 HAL 头文件里的函数指针表和新 framework 对不上接口 ID 不匹配时hw_get_module找不到模块。解决移植之前先确认目标和源码分支一致。驱动源码来自 Android 9就尽量放到 Android 9 或兼容版本上编译不要跨大版本硬移。如果必须移植要看 framework 调用的接口是什么。新系统里更合理的方式是写一个android.hardware.gnss的 HIDL/AIDL service把旧 HAL 的串口逻辑包在 service 里而不是继续维护旧的 libhardware 模块。6. 验证 GPS 驱动android studio 最小 Demo、logcat 与冷启动 TTFF6.1 用 android studio 写一个最小定位 Demo底层驱动改完需要一个 App 来验证整条链路。在 android studio 里新建项目不需要复杂 UI只注册 LocationListener 并打日志LocationManager lm (LocationManager) getSystemService(LOCATION_SERVICE); if (!lm.isProviderEnabled(LocationManager.GPS_PROVIDER)) { /* 这里可以提示用户打开 GPS 开关驱动正常时会显示可用 */ return; } LocationListener listener new LocationListener() { Override public void onLocationChanged(Location location) { Log.d(GpsDemo, lat location.getLatitude() , lng location.getLongitude() , acc location.getAccuracy()); } }; lm.requestLocationUpdates(LocationManager.GPS_PROVIDER, 0L, 0f, listener);在AndroidManifest.xml里申请定位权限uses-permission android:nameandroid.permission.ACCESS_FINE_LOCATION / uses-permission android:nameandroid.permission.ACCESS_COARSE_LOCATION /最小 Demo 的意义在于排除 App 代码干扰。如果这个 Demo 能持续输出坐标说明从 HAL 到 framework 的整条链路没问题。如果不行再回到 logcat 查底层。6.2 用 logcat 和 dumpsys 确认底层状态驱动层日志通常在 system_server 进程里过滤 GNSS 相关 tagadb logcat -s GnssLocationProvider Gnss adb logcat | grep -E NMEA|GGA|RMC|GNSS有的厂商 HAL 会打NmeaParser、GpsHal这类 tag找不到就多刷几行 grep。另一个快速判断是adb shell dumpsys location | grep -A 10 GPS如果provider状态是available但一直没有 fix说明底层还在等卫星如果状态直接是unknown说明 HAL 或 JNI 没起来。这两个命令是排查底层问题时最高效的组合。6.3 验收指标与最终检查顺序我一般用三个指标收尾冷启动 TTFF 在开阔地小于 35 秒热启动小于 3 秒静态定位误差稳定后小于 10 米。这三个值不是绝对标准但能满足大多数车载和物流定位需求。最后的检查顺序固定为先看设备树上电时序再看/dev/ttyS*是否出现然后用串口工具抓 NMEA最后打开 android studio 的 Demo 看坐标。很多人喜欢直接从应用层开始调绕一圈回来才发现是最底层串口没配好。我在做这类驱动移植时始终把这一步放在最前面能少走很多弯路。驱动资料里的源码只是起点真正让你省时间的是这条验证顺序和上面的避坑经验希望帮到你。本文还有配套的精品资源点击获取