Gps 整体框架文字版

1. GPS架构
   1.1 GPS总体架构
   
   GPS总体架构如图所示。相关模块功能描述：
   LocationManager提供定位服务，
   GpsLocationProvider用于抽象GNSS提供的服务，
   Network Provider用于抽象网络定位服务，
   Libgps用于对接Android接口，解析NMEA，
   Gps engine通过计算raw data，计算出PV并打包到NMEA，
   AGPS负责SUPL协议处理，以及位置承载协议处理。

1.2 GPS芯片分类
GPS chip一般分为两种：
1.Isolated，即不需要AP参与计算，由GNSS自助计算得到位置信息

• 理论上更省电，但不易于通过软件升级
• 值钱多用于数码相机等DC设备中
• 未来有回归的趋势，加入sensor fused engine，拥有batching能力

2.With AP help，需要AP提供计算能力，GNSS chip之提供Raw data

• 易于通过软件更新，较耗电
• 手机中最常见的解决方式

2.GPS主要流程
2.1 开机启动

• LocationManagerService开机启动过程见我本地文档画的“Gps框架图”，它作为系统服务，当系统启动时在System.java中加载启动，并执行systemRunning函数。

SystemRunning执行过程如下：

• 1.首先初始化mPackageManager、mLocationFudger、mBlacklist、mGeofenceManager等成员变量；
• 2.loadProvidersLocked，此方法会加载Provider，每一个加载成功的provider都会被放入mProviders和mProvidersByName中；
• 3.updateProviderLocked，通过调用此方法，可以对每一个provider的状态做更新，从mPovider中依次取出已经加载的provider，查看其在setting中的设置，如果设置中的设定与provider本身的状态不一致，则根据设置更新provider的状态。
• 4.注册LocationSetting中mode变动与user变更的监听。当用户改动了设置中位置信息的设定，则LocationManagerService会通过调用updateProviderLocked对已经加载过的provider做状态更新；当user变更时，更新通过mUserManager获取的Profiles。

2.1.1 loadProvidersLocked详解

• 1.加载PassiveProvider，它会一直存在于系统中，用于被动监听其他Provider获取的位置，只要LocationManagerService存在，PassiveProvider就会一直存在。
• 2.加载GpsLocationProvider，需要注意的是GpsLocationProvider中有一个static初始化块，其中的class_init_native方法将GPS HAL的接口函数地址注册到sGpsInterface中。接着会通过调用isSupported()查询注册结果，并据此来判断是否支持GPS，如果支持则加载GpsLocationProvider。
  sGpsInterface是一个指向结构体的指针，这个结构体包含了GPS
  - 3.加载NetworkProvider、GeocoderProvider、FlpHardwareProvider等Provider。NetworkProvider提供网络定位功能；GeocoderProvider提供经纬度与地址的转换，FlphardwareProvider提供包含BLE，sensor的方式获取位置，依赖于芯片能力。

2.2 打开GPS开关
2.2.1 更新GPS模式

• 从Settings打开GPS定位开关时，默认选择高精度模式，将开启的provider写到secure表中的LOCATION_PROVIDERS_ALLOWED字段中。在GPS开关已打开，变更定位模式时同样执行本流程，具体过程我本地文档画的“Gps框架图”。

• 当定位模式发生变化时，LocationMangerService会监听到SettingsProvider的变化，执行updateProviderLocked函数，对比当前provider状态与预期状态，如果不一致，按照用户指定的状态更新，并将provider 变更的消息用回调函数通知listener，并发送广播。AOSP中除了PassiveProvider以外，只有GpsLocationProvider是可以由芯片平台提供的。当打开位置开关，且选择高精度或者仅限GPS的时候，GpsLocationProvider会被打开，并完成初始化的工作。通过调用native_init()调用到JNI进一步到GPS HAL。这里要完成的工作是将JNI预先定义好的回调函数地址通过init(&sGpsCalllbacks) 传递到GPS HAL。GPS HAL通过这些callbacks可以将GPS HAL/GPS engine计算出的信息传递到framework。这些callbacks被封装到一个叫做GpsCallbacks的结构体里面，这个结构体定义在gps.h中。GpsCallbacks如图所示。
  
  这些callback的作用：

• location_callback用于向上层报告位置；

• status_callback用于将GPS HAL/engine的工作状态报告给上层；

• sv_status_callback用于将卫星状态报告给上层，当卫星状态（可见卫星数量，用于定位卫星数量，卫星的SNR，卫星的角度）发生改变时候，GPS HAL有责任汇报；

• nmea_callback用于将GPS engine计算出的nmea 报告给上层，nmea中会承载位置信息和卫星状态等信息；

• set_capabilities_callback用于表示engine 具备的功能；

• acquire_wakelock_callback用于向Android 申请一个wakelock；

• release_wakelock_callback用于释放wakelock；

• create_thread_callback用于申请一个thread，只有使用这个callback 申请的thread，才可以调用其他的callback。这样的方式可以将thread 从system_server进程中剥离，防止这些callback的上下文中由block操作而引起的system_server异常；

• request_utc_time_callback用于请求UTC时间，时间的获取，这有利于提高GPS定位速度。

对于GPS HAL来说，初始化意味着开始run起来的，因为GPS HAL是以.so的形式存在与file system中，只有调用到init时候，GPS HAL才会开始执行代码。在完成GPS HAL初始化工作后，framework还会通过调用native_supports_xtra来进一步确认GPS HAL的能力，然后framework会再次检查用于保存AGPS server 的变量，并再次设置给GPS HAL。至此，GPS HAL处于ready状态，应随时可以按照framework指令提供位置。

2.3 启动定位以及上报信息

• 应用开发者通过LocationManager中的API请求定位数据，调用至LocationManagerService的requestLocationUpdates函数，检查应用访问位置信息的权限之后会调用applyRequirementsLocked函数，此函数首先会记录应用的信息，接着会调用provider的setRequest函数，最终执行到updateRequirements函数，如果此时GPS HAL不处于工作状态，会执行startNavigating函数，进而调用native_set_position_mode，设定位置上报周期以及AGPS模式，然后调用native_start，启动定位，
• 当GPS chip和engine完成搜星定位之后，会把位置使用callback报告给framework。当有位置数据上报的时候，LocationManagerService会先将位置保存在lastLocation中，并根据是否有app请求passive provider来决定将此位置汇报给passive provider的申请者，最后根据每一个receiver对位置的精度请求将位置直接（高精度）或者加入一些误差（低精度）之后上报给app。

2.4 关闭定位

• 关闭定位的流程与开启定位十分相似，应用开发者通过调用LocationManager中的API停止请求定位数据。最终会执行至GpsLocationProvider中的stopNavigating函数，接着会调用native_stop关闭定位，至此，不会再继续上报数据。

2.5 关闭GPS开关

• 用户关闭GPS定位开关就相当于将定位模式更新成关闭模式。当LocationManagerService监听到模式改变，最终调用至GpsLocationProvider中的handleDisable函数，关闭定位并且调用native_cleanup函数，逆操作初始化，使GPS HAL处于无法工作状态。