企业官网建设流程全解析

简介：Android-FakeGPS是一款面向Android开发与测试人员的GPS设备模拟器，核心功能是根据指定经纬度输出模拟定位信号，帮助验证地图导航、位置签到、周边服务等依赖地理位置的功能。包内除了可直接运行的APK或源码工程，还包含完整的Gradle构建配置、Java与XML源码、截图及说明文档，便于二次开发或学习定位模拟原理。资源共69个文件，以Java、XML源码为主，辅以PNG截图、Gradle脚本、JAR库及AIDL接口文件，整体压缩包仅1.06MB，轻量且结构清晰。目前已有781人学习下载，适合需要快速搭建虚拟定位环境、测试基于位置的应用或研究GPS模拟机制的开发者。借助悬浮手柄与方向键，可在不移动的情况下模拟连续轨迹，既支持功能联调，也适用于地理游戏探索与回归测试。 做Android定位相关开发、或者日常给地图类App做测试的工程师，大概率都遇到过同一个场景：测试环境里想让被测App认为自己“人在某某城市”，但人又不能真的买票飞过去。早些年大家习惯在代码里硬编码坐标，改一个测试分支就要重新编译一次，效率低到流泪。后来Android开发者选项里出现了“允许模拟位置”，配合FakeGPS这类GPS设备模拟器，定位测试才算真正轻松起来。

FakeGPS的本质很简单：它运行在Android系统层，把GPS定位信号统一替换成你填写的经纬度坐标。你在地图上点一个点，整个系统里所有向定位服务请求位置信息的应用——不管是高德、美团还是你自己的产品，拿到的都是这份“假”坐标。用于地图回归、坐标触发逻辑、距离计算这类测试，能省下大量在路上跑动的时间。这篇内容我从原理、配置、ADB命令行用法到常见坑位完整过一遍，适合做Android开发、App测试、以及地理信息相关方向的同学参考。

1. 项目核心：为什么GPS开发测试离不开模拟器

1.1 FakeGPS到底做了什么

FakeGPS从定位结果来看，等于在Android系统的LocationManager框架里注册了一个替代性的位置数据来源。Android定位框架本身就允许第三方应用通过“允许模拟位置”机制向系统提供替代定位数据，FakeGPS只是把这套机制用满，并做了更友好的坐标输入、地图选点、轨迹模拟等操作层能力。你不用写一行测试代码，就能获得一个可反复使用的模拟定位环境。

从使用者的视角看，FakeGPS的核心价值在于“无侵入”。被测App完全不知道自己拿到的是模拟坐标，定位回调和真实设备上的回调路径一致，只是数据源头从卫星信号变成了你指定的经纬度。我在给地图SDK做回归测试时，最怕的就是测试代码污染线上逻辑，而FakeGPS这种外部注入方式天然隔离了测试环境和业务代码，测完直接关闭模拟就恢复原状。

1.2 模拟位置相比硬编码改代码的优势

很多人第一次接触定位测试时，第一反应是直接在代码里写死一个坐标返回。这个做法至少有三个问题：一是必须重新编译测试包，改一次坐标编译一次，时间全浪费在构建上；二是调试逻辑容易泄漏到生产环境，万一忘了删就是线上事故；三是根本无法验证系统级定位链路，像GPS provider选择、定位权限弹窗这层行为，硬编码完全覆盖不到。

FakeGPS类工具的另一个不可替代的好处是能模拟“移动过程”。它支持沿指定轨迹以一定速度连续改变坐标，比如从A点沿道路匀速前进到B点。这种动态场景在代码硬编码里很难快速模拟，但对于运动类App、车队管理、导航应用来说又是刚需。从测试设计的角度看，FakeGPS不只是省时间，它还让测试用例更接近真实用户行为。

2. 原理拆解：模拟坐标是如何接管系统定位信号的

2.1 定位数据在Android系统里的流转链路

要理解FakeGPS为什么能生效，得先知道GPS坐标在Android内部是怎么走的。Android把定位能力抽象成LocationManager服务，应用通过getSystemService拿到LocationManager后，调用requestLocationUpdates请求定位。这个请求会上交到系统进程里的LocationManagerService，它再根据当前可用的provider——GPS_PROVIDER、NETWORK_PROVIDER、PASSIVE_PROVIDER——决定返回哪条链路的数据。

GPS_PROVIDER的数据来源是手机里的GNSS硬件固件，硬件从卫星信号计算出位置后，通过驱动和HAL层上报给系统；NETWORK_PROVIDER则是根据Wi-Fi、基站等网络信息估算位置。系统里预留了一个叫mock provider的插槽，用于开发测试时把GPS_PROVIDER的数据替换成注入的坐标。FakeGPS就是用它来接管真实GPS链路，把假坐标伪装成来自GPS_PROVIDER。实测下来上层应用基本无感知，真正来自卫星的信号并不会被转发出来。

2.2 “允许模拟位置”与provider机制

Android从早期版本就支持模拟位置，但入口在不同版本间有变化。Android 6/7/8时代在开发者选项里有一个“允许模拟位置”开关；到了Android 9及以后，系统收到声明了ACCESS_MOCK_LOCATION权限的应用后，这个权限默认就是可用的，开发者选项里反而没有独立开关了。现在主流版本的做法是，在开发者选项里找到“选择模拟位置信息应用”，把FakeGPS指定为默认的模拟位置来源。

这一步是很多刚上手的人最容易漏掉的。只给FakeGPS正常安装并授予定位权限还不够，如果没有在“选择模拟位置信息应用”里选中它，系统不会把GPS_PROVIDER切换到mock模式，模拟位置自然也不会生效。在部分定制ROM上这个选项可能被藏得比较深，建议直接用系统设置的搜索功能搜“模拟”关键词来定位。

2.3 坐标系、误差与坐标格式校验

用FakeGPS之前一定要了解坐标系的差异。WGS-84是GPS卫星定位的原生坐标系，GCJ-02是国内大部分地图平台做了加偏（俗称火星坐标）的坐标系，BD-09是百度坐标系。FakeGPS通常可以配置输出哪种坐标格式，如果目标地图App用的是GCJ-02，你却按WGS-84填入GPS原始坐标，模拟位置会偏移几百米甚至更远。

这里我要强调一个常犯的错误：把国内地图App里读取到的坐标直接填到FakeGPS里，想当然认为坐标是通用的，结果模拟出来的点落在隔壁街道，连打车路线的起终点都完全对不上。正确做法是先确认被测应用用的什么坐标系，再在FakeGPS里做对应设置；或者直接用工具内置的地图选点功能，它会按目标坐标统一处理。GPS定位本身依赖三边测量算法从卫星距离推算出位置，但模拟器绕过了这套计算，直接把最终坐标喂给系统，所以坐标系转换的准确性就完全依赖工具配置了。

3. 实操：完成一次FakeGPS模拟定位

3.1 基础环境准备

模拟定位对机型要求不高，但至少满足三个基础条件：第一，一台Android手机，系统版本建议5.0以上，且不是那种把开发者模式锁死的定制终端；第二，开发者选项已经打开——连续点击“版本号”7次即可；第三，安装好FakeGPS的APK，并授予定位权限。

如果需要用ADB命令行来控制坐标切换，还要在电脑上装好Android SDK Platform Tools，通过USB连接手机并授权调试。这里有个容易被忽略的点：很多机型在USB连接方式里默认是“仅充电”，需要手动切换到“文件传输/MTP”或“USB调试（RNDIS）”模式，ADB才能发现设备。用adb devices检查连接状态，看到设备序列号就说明环境通了。

3.2 拿到一份可用的GPS坐标

没有现成坐标时，推荐直接用FakeGPS内置的地图选点功能。进入坐标设置页面，拖动地图标记到目标位置，点确认即可。如果你手头有文本格式的经纬度，比如“31.2304, 121.4737”，也可以直接粘贴进去，但务必注意坐标系。坐标保留建议至少6位小数，对应厘米级精度；保留4位小数约10米左右，大多数场景也够用。

我的习惯是优先用WGS-84源获取坐标，再在FakeGPS里统一设置成WGS-84输出。GPS硬件上报的原生格式就是WGS-84，这条链路最稳定。如果非要测试国内地图加偏坐标系，就全程保持同一套坐标体系，不要在一个用例中混用，否则排查坐标偏移时会非常痛苦。

3.3 配置FakeGPS并验证结果

配置流程不复杂，按这个顺序走一遍就能正常模拟：

1. 打开FakeGPS，授予定位权限；
2. 进入开发者选项，在“选择模拟位置信息应用”中指定FakeGPS；
3. 回到FakeGPS，在地图上选点或直接输入坐标；
4. 点击“开始模拟”或Start按钮，MockProvider即切换生效。

验证是否生效的最快办法是打开第三方地图App，观察定位蓝点是否跳到目标坐标。更严谨一点，可以在自己开发的测试应用里打印Location对象，看isFromMockProvider()是否为true，同时把getLatitude()、getLongitude()和你填的坐标做差值对比。我在自动化脚本里会同时输出provider名称和isFromMockProvider两个字段，这样能明确区分当前是GPS硬件定位还是模拟定位。

3.4 用ADB命令快速切换坐标

手动在地图上点来点去，在批量测试场景下效率太低。如果是Android Emulator场景，可以直接用系统自带命令注入模拟位置：

adb emu geo fix <longitude> <latitude>

这条命令会让模拟器直接以经纬度参数生成GPS固定位置，不依赖任何第三方工具，速度最快。对真机加FakeGPS的场景，如果FakeGPS自身没有暴露ADB广播接口，通常做法是关闭模拟、修改坐标后重新开启模拟。另外Android Studio自带的Emulator也提供了图形化的位置模拟入口，在Extended Controls面板的Location选项卡里，可以顺序设置多个坐标点，还能模拟车辆沿路径匀速移动，适合做基础功能验证。

4. 进阶场景：从单点模拟到轨迹与真机设备测试

4.1 地图/导航App的轨迹回放测试

我最常接到的需求是轨迹回放。比如一个户外跑步App要验证运动轨迹生成，你不能真带着手机去操场跑一圈。在FakeGPS里设置一串关键坐标点，配上移动速度和坐标更新间隔，模拟位置就会沿着指定路径持续变化。App端收到的是一连串连续变化的坐标，和真机记录的轨迹序列几乎无法区分。这时再跑轨迹拉伸、轨迹纠偏、距离计算等用例，效率高出一大截。

轨迹模拟的关键是参数设置不能过于夸张。我通常用1秒间隔、每步移动3到8米，整体速度控制在5到15公里每小时，这个节奏接近真实步行或慢跑的回调频率。如果间隔5秒、步长50米，很多地图App会把轨迹点连成锯齿线，甚至触发异常轨迹告警，测试结果就失真了。

4.2 出行类App的距离计算与计费验证

打车类、外卖类应用的计费与配送距离测算，是最需要模拟位置的场景。人工打车核实一次起步价成本太高，用FakeGPS模拟同一个起终点跑一遍行程，立刻就能拿到订单金额、行驶时长、路线规划等多个验证结果。我此前提过一个跨城订单的长距离计费逻辑，直接在工位上把坐标从上海切到杭州，不到1分钟就把多段计费规则核对完了，这在真实路测中几乎不可能完成。

但这里也必须提醒：FakeGPS模拟的是纯坐标，并没有真实道路上的GPS误差波动和信号遮挡。如果测试目标是极端弱信号下的降级策略，比如进出隧道后的位置校正，软件模拟就覆盖不了。软件模拟适合验证业务逻辑，真正的硬件链路问题还是得回归到实车路测。

4.3 硬件级GPS信号模拟器（如H2）与软件模拟的关系

某些测试场景下，被测对象不是App而是导航设备本身——车载导航机、手持GPS仪表这类硬件。它们没有Android系统的模拟位置选项，软件模拟完全插不上手。这时要上硬件级的GPS信号发生器，像“partapack H2”一类的设备，可以直接发射模拟的GPS卫星信号，让被测导航设备认为自己接收到了真实卫星数据。

H2这类设备通常支持在配套软件里配置星历、目标坐标和移动轨迹，再通过射频线或天线把信号传给被测设备的GPS接收机。相比FakeGPS，它更接近源头级模拟，能控制卫星几何分布、信号信噪比、多径误差等参数，常用于导航设备冷启动搜星测试、定位性能验证和天线灵敏度标定。选型原则就是先分清测试对象：测App用软件模拟器，测终端设备用硬件信号源。

4.4 树莓派GPS、WiFi定位与GPS定位的差别

做物联网终端方案时，经常用到树莓派配合GPS模块（u-blox、NEO-6M这类）做数据采集。树莓派跑的是完整Linux系统，没有Android的mock location机制，所以FakeGPS派不上用场。要在树莓派上模拟GPS数据，通常有两种思路：一是改写串口输入，用程序输出NMEA语句，让GPSD等软件以为收到了真实卫星数据；二是用能输出NMEA格式的GPS模拟设备接入串口。这样组合起来，可以快速验证自己的导航数据解析模块是否正确。

顺便说下游WiFi定位和GPS定位的区别。WiFi定位依赖周边WiFi热点SSID和BSSID的指纹库，基本不依赖卫星，室内可用但精度通常在20到100米，城市高密度区域坐标跳跃明显；GPS定位依赖卫星信号，开阔室外精度可达2到10米，但室内或高架桥下会迅速劣化。FakeGPS之所以好用，是因为它直接提供了GPS这条最高精度的数据链路，而测WiFi定位就需要另一层面的信标模拟手段了。

5. 踩坑实录：FakeGPS常见问题与排查

5.1 模拟位置不生效，蓝点始终在真实位置

九成是前置配置问题。按优先级检查三点：开发者选项里“选择模拟位置信息应用”是否确实选中了FakeGPS；FakeGPS是否授予了定位权限；被测App是否强制指定了真实GPS_PROVIDER从而绕过了mock provider。另外很多高版本Android上，如果“允许模拟位置”开了但“选择模拟位置信息应用”里没指定具体应用，系统会静默忽略模拟请求，表现就是完全不起作用。

提示：遇到这类问题，先执行“停止模拟 -> 重新选择模拟位置应用 -> 再开始模拟”的复位操作，能解决相当一部分缓存型故障。

5.2 App识别出模拟环境

不少App为了反作弊，会在风控逻辑里读取isFromMockProvider()。如果是自己开发的应用，测试时可以通过代码开关或调试Hook临时绕过；如果是第三方应用，FakeGPS被识别是正常现象，更合理的方案是改用Android Emulator的模拟位置入口，或者用硬件级信号模拟器。绕过App的反模拟识别不在本文讨论范围，也不建议为此折腾对抗手段，这只是测试工具选型问题。

5.3 模拟点漂移或偏了几百米

坐标偏几百米，基本可以断定是坐标系混用。GCJ-02和WGS-84在中国区域通常存在几十到几百米偏差，不做转换直接填入坐标，结果必然不准。解决办法是全程统一坐标系。部分FakeGPS版本会在后台自动做坐标转换，这时要确认它转换后的输出是哪种格式，再去匹配目标App。实在判断不了，就依赖地图选点功能让工具自己落定坐标，最省心。

5.4 轨迹模式下位置跳变、速度忽快忽慢

常见原因是步长和间隔设置不合理，每步移动距离太远，模拟位置就像在“闪现”；其次是系统后台把FakeGPS进程冻结了，导致间歇性停止上报。解决办法是在系统设置里对FakeGPS开启“不限制后台电池”选项，同时保持屏幕常亮，测试时最好插着电源。我在真机轨迹测试中踩过最隐蔽的坑，就是进程被杀后坐标突然回到真实位置，过一段时间又恢复模拟，日志里中间断开一大截，数据根本不连续。后来统一用专门的测试机、关闭电池优化，问题才算根治。

6. 几个实操心得

最后分享几个我长期形成的个人习惯，希望对你有参考价值。第一，不要在生产主力机上跑模拟定位，最好准备一台专用的定位测试机，长期开启开发者模式和USB调试，所有定位类用例固定在这台机器上执行。这样既避免污染日常数据，也防止测试过程中消息、推送等真实行为干扰结果。

第二，测试报告里一定要记录模拟工具的版本、坐标格式、provider信息，甚至把目标坐标和实际收到坐标的差值直接贴进用例描述。这样后期排查问题会快很多，别人也能根据这些信息复现你的测试环境，而不是靠猜。

第三，如果是周期性回归测试，建议把ADB坐标切换脚本集成到自动化流水线里。手动在FakeGPS上点选坐标适合验证单点，但自动化的价值在于可重复、可追溯。把模拟定位纳入持续集成后，每次发版前的定位回归测试基本能做到无人值守，整体效率提升非常明显。GPS相关项目最怕的就是“代码没问题，但真实定位环境下行为不可控”，FakeGPS这类工具虽然体量小，却恰好解决了这个信任问题。

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