Android GPS底层驱动开发：HAL、JNI与串口NMEA解析实战

简介围绕GPS Android底层驱动的中文资料包面向Android系统开发者与驱动移植工程师系统讲解JNI与HAL层的协同原理并附关键源码与移植分析笔记。压缩包共5个文件大小约9.28MB内含2份Word讲解文档、1个RAR辅助资料包、1个构建脚本及1个C语言源文件文档侧重原理梳理脚本与源码用于构建验证结构清晰便于对照学习。该资料已有839人浏览学习内容结合基于Android 2.3的车载导航GPS HAL移植与剖析实例深入覆盖JNI函数原型定义与本地实现、HAL层接口初始化与定位数据上报流程、GpsInterface在LocationManagerService中的调用关系以及GpsStatus状态查询、GpsNavigationMessageCallback导航消息接收等组件的具体用法。同时讲解了如何通过JNI头文件声明本地接口并利用ndk-build编译生成动态库供Java层调用帮助读者从源码层面打通GPS驱动的开发链路。读者可借此理清GPS服务从Java层到底层硬件的完整调用链路理解GpsLocationProvider生命周期管理与位置更新逻辑为后续在真实设备上调试GPS驱动、优化定位性能甚至类比开发Wi-Fi、蓝牙等同类硬件驱动提供扎实参考。1. GPS Android底层驱动不是调个LocationManager那么简单把一块串口GPS模块接到开发板上烧一套Android系统打开地图定位图标永远灰的。Logcat里只有一句not available。多数人第一反应是应用层API写错了但真正卡住你的往往是HAL模块没注册、JNI方法符号没对接上。这份“GPS Android底层驱动资料附关键源码”不是讲怎么调requestLocationUpdates而是把UART串口、HAL抽象、JNI bridge、Framework调用这一整条链路拆开附上能编译的源码与脚本。适合正在做BSP移植、想在板子上把GPS真正跑起来的开发。读完你会明白让定位数据出现在getLastKnownLocation里只需要把底层这些代码逐行咬透。2. 整体架构拆解从硬件抽象到 Framework 的调用链2.1 源码结构每一层都有对应的文件拿到这份资料第一件事是把目录树展开。压缩包里的结构并不复杂但每层都能对应到Android系统里的一个真实位置gps_android_driver/ ├── README.md ├── gps.h ├── gps.c ├── Android.bp ├── jni/ │ ├── com_server_location_GpsLocationProvider.cpp │ └── Android.bp ├── app/ │ ├── GpsTestApp/ │ ├── AndroidManifest.xml │ └── MainActivity.java └── scripts/ ├── setup_uart.sh └── test_loc.sh粗看只有几个文件但它覆盖了三层代码gps.h和gps.c是HAL层负责屏蔽具体硬件差异对外提供一个标准GPS设备接口jni/目录下的.cpp是JNI层负责把C层的能力暴露给Java Frameworkapp/是一个验证用的Android工程里面就一个页面用来触发LocationManager.getLastKnownLocation。三个部分合起来就是一条完整链路。常见做法是把HAL模块放到AOSP源码树的hardware/libhardware/modules/gps/下因为这样可以直接用系统的编译框架。资料里单独给了一份Android.bp目的就是让你既可以整个扔进AOSP编也可以抽出源码自己搭NDK工程。我一般会先把gps.c和gps.h放到独立目录确认模块加载正常再去动JNI因为HAL有没有被加载是这条链路里最好排查的。还要注意gps.c里定义的结构体不是随便写的。Android HAL要求模块文件导出一个固定的全局符号HAL_MODULE_INFO_SYM系统通过hw_get_module去.so里找这个符号。如果导出的符号名变了或者模块id字段和上层请求的字符串对不上就会返回-1。这部分代码我会在下一章逐段讲。scripts/setup_uart.sh看起来不起眼但它解决的是串口设备权限问题。开发板上/dev/ttyS1大概率只有root或者特定用户组能用App要读串口必须把设备节点权限放开或者加对应SELinux策略。没有这个脚本就算HAL代码完全正确你也会发现打开串口时返回Permission denied。2.2 调用链与NMEA数据格式约定定位数据在这套架构里的流动顺序是固定的。我从App侧往前理方便你对照代码看App 调用LocationManager.getLastKnownLocation(LocationManager.GPS_PROVIDER)这个请求丢给系统进程里的LocationManagerServiceLocationManagerService找到对应的GpsLocationProviderGpsLocationProvider是个Java对象它内部通过loadLibrary(gps)加载JNI库然后调用init()、start()等 native 方法JNI层拿到 native 方法后通过hw_get_module(GPS_HARDWARE_MODULE_ID)加载 HAL 模块拿到gps_device_tHAL层start()里会开一个串口读线程不断从/dev/ttyS1读取NMEA语句HAL解析出经纬度后通过回调函数往上层送最终封装成 Android 的Location对象这条链路里有两个位置最容易断一是hw_get_module找不到模块整个native方法直接返回false二是串口读线程没有权限或读不到数据导致上层一直拿不到回调。资料里的核心源码其实就是在解决这两件事。NMEA数据格式也是绕不开的。GPS模块上电后主动输出$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,...这样的句子字段按逗号分隔。GGA里包含标准定位时间、纬度、经度、卫星数、海拔等。HAL层的parse_nmea要做的工作就是把字符串第3、4、5、6个字段抠出来换算成double。资料里没有完整实现所有句子只针对GGA和RMC做了大多项目都够用的解析这也是我认为它适合做原型验证的原因——不会一上来就让你陷到十几个NMEA消息类型里。在继续前我想说清楚为什么要一层JNI夹在中间。Android的Java框架跑在ART虚拟机里不能直接调C函数HAL层又是标准的C接口。JNI就是那座桥。它一方面把Java的native方法init()和C层的gps_init对应起来另一方面负责在Java对象和C结构体之间传递数据。很多初接触的人会跳过JNI直接写一个自己调用的.so用System.loadLibrary加载后native方法却找不到符号这就是因为没按JNI的注册规则来。资料里专门把JNI_OnLoad和RegisterNatives写出来就是让你少走这个弯路。需要特别提醒的是Android 8.0之后系统倾向于用HIDL接口替代传统直通式HAL但很多快速开发板仍然保留hw_get_module这一套。资料里的代码走的是传统HAL模型在Android 7-10之间都比较好编译如果目标是Android 11以上就得考虑接口迁移我在最后一章会给出改造思路。3. HAL 与 JNI 核心实现一份能跑通的关键源码3.1 HAL 层hw_module_t 与串口读写的骨架HAL层的代码量不大但骨架必须完整。第一个要看的是模块入口定义// gps.c 头部 #include hardware/gps.h #include hardware/hardware.h #include fcntl.h #include unistd.h static int gps_device_open(const struct hw_module_t* module, const char* name, struct hw_device_t** device); static struct hw_module_methods_t gps_module_methods { .open gps_device_open, }; struct hw_module_t HAL_MODULE_INFO_SYM { .tag HARDWARE_MODULE_TAG, .id GPS_HARDWARE_MODULE_ID, .name GPS HAL for Android, .methods gps_module_methods, };这里HAL_MODULE_INFO_SYM必须叫这个名字不能改动。Android 的hw_get_module(GPS_HARDWARE_MODULE_ID, module)会去/vendor/lib/hw/或/system/lib/hw/下找gps.default.so然后通过dlopen拿到这个符号再检查id是否匹配。所以四个关键点分别是文件要叫gps.default.so、符号名要叫HAL_MODULE_INFO_SYM、id要来自gps.h、路径要在HAL标准目录下。任何一个不对结果都是module not found。接下来是open回调static int gps_device_open(const struct hw_module_t* module, const char* name, struct hw_device_t** device) { gps_device_t *dev calloc(1, sizeof(gps_device_t)); if (!dev) return -ENOMEM; dev-common.tag HARDWARE_DEVICE_TAG; dev-common.version 0; dev-common.module (struct hw_module_t*)module; // 把资料里实现的函数挂到设备结构体上 dev-init gps_init; dev-start gps_start; dev-stop gps_stop; *device (struct hw_device_t*)dev; return 0; }这里calloc清空结构体防止残留野指针。dev-common里的tag必须等于HARDWARE_DEVICE_TAG这是hw_device_t的基本检查。gps_device_t是gps.h定义的结构体最前面一个是hw_device_t common后面跟着若干函数指针。这些函数指针就是上层通过gps_device-start()能直接调用的入口。常见坑是只实现了init和start漏了stop上层在某些场景下会崩溃当然至少要保证start正常工作。串口读写是核心。资料里把读线程写得很完整我摘一段加注释static void* gps_reader_thread(void* arg) { int fd open(/dev/ttyS1, O_RDWR | O_NOCTTY); if (fd 0) { ALOGE(open ttyS1 failed: %s, strerror(errno)); return NULL; } struct termios cfg; tcgetattr(fd, cfg); cfsetispeed(cfg, B9600); cfsetospeed(cfg, B9600); cfg.c_cflag | (CLOCAL | CREAD); cfg.c_cflag ~CSIZE; cfg.c_cflag | CS8; cfg.c_cflag ~PARENB; cfg.c_cflag ~CSTOPB; tcsetattr(fd, TCSANOW, cfg); char buf[256]; int n; while ((n read(fd, buf, sizeof(buf) - 1)) 0) { buf[n] \0; parse_nmea(buf, strlen(buf)); } close(fd); return NULL; }波特率通常默认96008N1但要注意不是所有模块都这样。有些模块上电默认38400必须先在PC上确认。O_NOCTTY防止串口被当作控制终端导致输入输出被shell接管CLOCAL | CREAD是保证即使没连调制解调器也能读数据。c_cflag那几行是在配置无校验、1位停止位、8位数据位这套配置兼容大部分NMEA设备。read是按底层缓冲区来的不一定一次就是一行所以parse_nmea需要先按\n切分。资料里的做法是维护一个静态环形缓冲把每个字节追加进去遇到\n就取出来处理。这个细节虽然小但直接影响数据解析正确性我在第五章会把它展开成一个典型踩坑场景。3.2 JNI 层native 方法与 Java 回调的桥接JNI 层在整份源码里的位置很特殊。它不是一个完整的HAL也不是纯Java而是一串C函数通过RegisterNatives绑定到系统Java类GpsLocationProvider上。核心函数如下// com_server_location_GpsLocationProvider.cpp #include jni.h #include hardware/hardware.h #include hardware/gps.h static gps_device_t* sGpsDevice NULL; static jboolean init(JNIEnv* env, jobject obj) { const hw_module_t* module NULL; if (hw_get_module(GPS_HARDWARE_MODULE_ID, module) ! 0) { ALOGE(hw_get_module failed); return JNI_FALSE; } gps_device_t* dev NULL; module-methods-open(module, GPS_HARDWARE_MODULE_ID, (struct hw_device_t**)dev); sGpsDevice dev; return JNI_TRUE; } static jboolean start(JNIEnv* env, jobject obj) { if (sGpsDevice sGpsDevice-start) { return sGpsDevice-start() 0 ? JNI_TRUE : JNI_FALSE; } return JNI_FALSE; }这里我把函数名简化了实际资料里的函数名会带完整包名前缀避免符号冲突。可以看到init()做的事情和上层Java的调用是对应的拿到HAL模块打开设备存到静态指针。start()则直接透传到HAL层。如果你发现sGpsDevice是空指针说明init没有在start之前被调或者init已经失败了。注册表是JNI的枢纽static const JNINativeMethod kMethods[] { { init, ()Z, (void*)init }, { start, ()Z, (void*)start }, }; extern C JNIEXPORT 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 cls env-FindClass( com/android/server/location/GpsLocationProvider); if (cls NULL) { return JNI_ERR; } if (env-RegisterNatives(cls, kMethods, sizeof(kMethods)/sizeof(kMethods[0]))) { return JNI_ERR; } return JNI_VERSION_1_6; }这里的()Z是JNI描述符表示无参、返回boolean。FindClass的字符串必须是Java层类的全限定名用/分隔。Android系统源码里的GpsLocationProvider类位于com.android.server.location如果你的目标源码版本改了包名这里就要跟着改。资料里给的是一种标准写法好处是它可以被同一个.so加载多次不会重复找到类。实际开发中我一般会在这两层之间加一层日志而不是只在上层看结果。比如在init里打ALOGD(gps native init called)在start里打日志并打印返回值。这样判断问题在哪里非常高效日志只到JNI层说明HAL没加载成功日志过了JNI层说明问题在串口或解析。NMEA解析函数我最后提一句static void parse_nmea(const char* line, int len) { if (strncmp(line, $GPGGA, 6) 0) { // 按逗号拆分字段 // 字段2, 4 分别是纬度经度的度分格式转成double再回调上层 } }虽然只有一段注释但它背后是GPS知识的一个门槛4807.038表示 48°07.038′需要拆成度加分/60换算成十进制。很多人在这一步把小数点位置放错差出的距离就是几十公里。资料里的源码有一整段用于转换我建议拿到后先拿模块实测的串口数据对一下。4. 编译与运行在 Android 源码树里把 GPS 模块拉起来4.1 源码树摆放与模块编译要跑这份驱动最直接的方式是把源码放进AOSP工程里编成系统镜像的一部分。这也是资料里Android.bp存在的意义。假设你的工作目录是~/aosp把资料解压后创建一个目录mkdir -p ~/aosp/hardware/libhardware/modules/gps cp gps.h gps.c Android.bp ~/aosp/hardware/libhardware/modules/gps/如果使用 Android.bp 构建内容可以参考下面这份cc_library_shared { name: gps.default, vendor: true, relative_install_path: hw, srcs: [gps.c], shared_libs: [ libhardware, liblog, libcutils, ], }name里的.default会生成gps.default.so安装路径由于vendor: true和relative_install_path: hw会变成/vendor/lib/hw/gps.default.so。注意Android 10之后已经不太推荐在hardware/libhardware/modules下直接放模块但你做的是传统HAL放到这里还是可以编只是系统会提示模块被deprecated。如果想放在一个更干净的位置也可以放在device/产品名/gps/下然后通过PRODUCT_PACKAGES加入构建。编译命令老工程师都有肌肉记忆source build/envsetup.sh lunch aosp_你的产品-userdebug mmm hardware/libhardware/modules/gps/新版本里mmm已被移除可以用m gps.default编译产物在out/target/product/产品名/vendor/lib/hw/gps.default.so。如果你用的是Android.bp检查路径是否和你声明的模块名一致。如果打包进系统镜像直接烧录即可。如果只是想快速试不再刷机你可以用adb root后把.sopush 进/vendor/lib/hw/。这里有个容易翻车的地方新手总是直接push却忘了先重新挂载系统分区。现在的Android系统/vendor是只读的需要先执行adb root adb remount adb push gps.default.so /vendor/lib/hw/ adb shell chmod 644 /vendor/lib/hw/gps.default.so adb reboot如果不remount会收到Read-only file system错误。这不是资料的问题是所有系统级文件修改的通用步骤。对于只做上层验证的同学一个现实问题是手头没有完整AOSP源码。资料里JNI目录下那份Android.bp也能用作NDK构建的参考你可以用 CMake 的思路把.cpp编成libgps_jni.so然后在App里System.loadLibrary(gps_jni)。但是HAL层调用hw_get_module需要系统库头和运行环境纯粹NDK工程里没有这些。所以我的建议是没有源码树至少准备一台能adb remount的开发板先在板子上验证HAL再用NDK单独编JNI层最后合到一起。4.2 设备端验证串口、模块与日志三步走编译完成并烧录或push好后先用最笨但有效的方法确认串口硬件通不通。这套资料里的scripts/setup_uart.sh内容大致是#!/system/bin/sh # 给串口设备开权限方便GPS HAL读取 chmod 666 /dev/ttyS1 # 有些板子需要重新配置gpio mux把串口功能引出来 # echo 1 /sys/class/misc/.../select手动验证时我先在adb shell里执行adb shell su chmod 666 /dev/ttyS1 cat /dev/ttyS1如果模块上电正常应该能看到一行一行$GPGGA开头的报文。如果这里没有输出那问题出在硬件或串口配置而不在Android驱动后面做再多的HAL适配都是白费。我见过至少两次现象是HAL代码没问题最后发现ttyS1被其他驱动占用了用cat /dev/ttyS1直接会卡住。串口通之后验证JNI和HAL的对接。先确认模块文件存在adb shell ls -l /vendor/lib/hw/gps.default.so adb shell ls -l /system/lib/hw/gps.default.so然后打开日志过滤启动资料里的测试Appadb shell setprop log.tag.GpsLocationProvider VERBOSE adb shell am start -n com.example.gpstest/.MainActivity adb logcat -s GpsLocationProvider GPS JNI如果你看到hw_get_module或GPS HAL module not found说明HAL没被找到对照第五章第一条处理。如果看到串口数据被解析并且回调了App界面上就会显示经纬度。这套验证流程在大部分Android 7-10的板子上都能跑通。为了让调试更方便资料里的JNI层编译了一个独立的可执行文件版本但依赖系统库。如果你把libhardware等库静态编进去可以考虑这个路径。不过我还是推荐直接在系统里跑因为hw_get_module依赖系统的/vendor/lib/hw/路径和硬件模块加载机制单独在用户态模拟出来的HAL环境不一定和真实一致。5. 常见问题与排查定位数据没出来先查这三处这一章是资料里最值钱的部分。下面三条问题是我在跑类似驱动时最常遇到的每条都按现象、原因、解决三个步骤写清。5.1 HAL设备加载失败hw_get_module 返回 -1 的排查细节现象logcat里出现hw_get_module failed或者GpsLocationProvider: GPS HAL module not foundApp的定位接口永远不返回数据。有时候你明明编译生成了.so也push到了板上但系统就是报not found。原因最常见的是模块ID字符串没对上。你编译出的gps.default.so里的HAL_MODULE_INFO_SYM.id是android.hardware.gps但Framework层请求的可能是另一个字符串。另外如果gps.default.so没编译进系统或者被系统分区清理掉也会出现这个错误。还有一种很隐蔽的情况你有两个.so一个在/vendor/lib/hw/一个在/system/lib/hw/系统按ro.hardware属性选了一个而那个文件是旧的。解决先用adb shell ls /vendor/lib/hw/看.so在不在。在的话执行adb shell setenforce 0临时关闭SELinux再看日志如果恢复正常说明是SELinux策略拦住了dlopen。如果还不行检查gps.h里GPS_HARDWARE_MODULE_ID的宏定义把它与AOSP源码里hardware/libhardware/include/hardware/gps.h的值逐一比对改成一致。我一般会在HAL模块入口加一行ALOGI(GPS HAL id%s, HAL_MODULE_INFO_SYM.id);这样能在日志里看到实际值对比请求值原因一眼就清楚。再深一层hw_get_module的查找路径和ro.hardware有关。默认会去/system/lib/hw/id.ro.hardware.so找如果没有再退回/system/lib/hw/id.default.so。如果你的板子ro.hardware被设置成某个奇怪名字可能就命中了gps.board.so而不是gps.default.so。解决办法是看adb shell getprop ro.hardware的输出把编译产物重命名成对应的格式或者删掉多余文件避免误加载。5.2 JNI注册失败类名变化导致系统服务闪退现象App或系统服务一闪退logcat里出现JNI RegisterNatives failed有时是No implementation found for void com.android.server.location.GpsLocationProvider.native_init()。更高频的画面是系统定位进程直接重启。原因Android不同版本里GpsLocationProvider的包名和类名经历过几次变化。例如旧版本在com.android.location新版本在com.android.server.location。资料里的JNI代码FindClass写死了类名换了源码树就会找不到。另一个原因是Java侧的方法签名和注册表里的signature对不上比如Java是private native void init()JNI侧却注册成()Z类型不匹配注册就会失败。解决把JNI_OnLoad里的FindClass字符串改成你当前Android版本实际包名。怎么查用grep -r class GpsLocationProvider -n frameworks/base/services/core/java。找到后把com/android/server/location/GpsLocationProvider替换成完整路径。同时确认Java类的native方法声明和注册表里的方法名、签名完全一致。我遇到最隐蔽的情况是Java侧方法加了synchronizedJNI侧照常注册这个不影响。还要注意JNI_OnLoad本身有没有被执行。如果.so是System.loadLibrary加载的JVM会默认找JNI_OnLoad但如果你用dlopen方式手动加载没有触发JNI_OnLoadRegisterNatives 就永远不会执行。资料里的.so走的是正常loadLibrary路径但你自己扩展测试工程时不要改成dlopen。5.3 串口乱码与无回调波特率和行缓冲的坑现象cat /dev/ttyS1能看到输出但内容是..?...x这样的乱码或者程序运行后一直没定位回调但串口分明在吐数据。原因乱码十有八九是波特率不对。GPS模块默认波特率不一定都是9600很多小厂商改成了115200必须看模块规格书。没有回调则有可能是缓冲区没有按行切分两条NMEA句子粘在一起解析函数没找到$GPGGA行首或者模块冷启动需要几十秒你以为没数据其实是在搜星。解决先用PC串口工具确认实际波特率然后修改gps.c里的cfsetispeed和cfsetospeed。如果串口数据不是规整文本不要尝试用read强行读先按字节十六进制打出来看帧结构。针对粘包我习惯用一个环形缓冲每次read之后把所有字节追加进去再按\n找完整行丢给解析函数。这个能解决大多数设备上buf被拆分导致的丢帧问题。另外不要忽略cat /dev/ttyS1之后你的终端本身会进入raw模式。退出cat后先恢复串口设置否则后续进程可能读不到正常数据。我每次验证完都会把HAL里的tcsetattr重新执行一遍。如果你发现HAL读线程正常但一直没有回调还要检查一下GPS模块在室内是否拿不到有效定位。模块输出GGA里第7个字段是定位质量指示0是未定位1是GPS定位2是差分定位。日志里加上这个字段的判断能快速区分是驱动问题还是天线问题。6. 二次开发改造把这套驱动适配到你的板子上6.1 替换串口设备与定位参数资料默认写死了/dev/ttyS1和9600。你要做的第一件事是改成自己板子的实际串口设备。常见的命名有/dev/ttyS1、/dev/ttyMT2、/dev/ttyHSL0。改的时候全局搜一下ttyS1把open的参数换掉同时确认setup_uart.sh里的GPIO复用配置对应你的板子。如果模块输出电平是3.3V或TTL需要确认转串口芯片方向这部分不是代码能解决的。换完设备之后记得用第五章的验证流程先cat串口码通再编译。6.2 从传统HAL迁移到HIDL服务Android 8以后Treble架构要求HAL运行在独立进程传统hw_get_module方式不再被官方推荐。如果你从资料代码迁移到高版本不要死磕JNI直接拉HAL可以保留gps.c作为HIDL服务的后端把gps_device_t包到IGnss实现里JNI侧改为通过HIDL client接口调用。改造核心是把hw_get_module换成IGnss::getService()其余数据解析逻辑不变。这样既保住了底层代码又跟上了新架构。从那以后我每次调GPS都要先过一遍“串口能不能cat出数据、HAL模块能不能被找到、JNI注册有没有报错”三座山再谈定位精度和冷启动优化。这份资料的价值就是把这三座山的代码都摆在眼前让你不用在黑匣子里瞎猜。希望帮到你。本文还有配套的精品资源点击获取