不参与定位的北斗：Pixel 系列手机的 GNSS 地理围栏策略

TL; DR

• 在美国使用的 Pixel 11 Pro 能正常接收北斗卫星信号，也会把北斗的原始测量和导航电文提供给 App，但系统定位过程中不使用北斗星座。
• 这一限制写在联发科 GNSS 配置文件的 USswitch 项中：在一个大致覆盖美国本土的经纬度矩形内，固件把北斗（以及日本的 QZSS、印度的 NavIC）排除在定位解算之外，GLONASS 不受影响。
• 用手机记录的原始数据重新解算，在开阔天空下，加入北斗后位置散布缩小约 20%；在模拟的遮挡环境中，加入北斗带来的改善明显更大。
• 这一做法与 FCC 对外国卫星导航系统的授权规则有关，但 Google 排除的星座与 FCC 未授权的星座并不完全对应。

一、起因

Google 的 Pixel 硬件规格页中，Pixel 10 及更早的机型把美国版和其他地区版的定位系统分开列出：

[US]: Dual-band GNSS GPS, GLONASS, Galileo
[ROW]: Dual-band GNSS GPS, GLONASS, Galileo, Beidou, QZSS, NavIC

美国版的列表中没有北斗、QZSS 和 NavIC。到了 Pixel 11 系列，这一栏只写了 “Dual Band Multi-constellation GNSS”，没有列出具体的星座。

网上也有用户讨论过这个现象。2023 年 7 月，一位 Pixel 6 Pro 用户在 GPSTest 讨论组发帖，反映北斗在美国被禁用。GPSTest 的作者 Sean Barbeau 在回复中提到，对 App 来说，手机最终如何算出位置"实际上是一个黑盒"（effectively a black box）。Reddit 上也有类似的讨论。

笔者手上有一台在美国购买的 Pixel 11 Pro（Android 17，版本号 CD1A.261005.003），于是想弄清楚三个问题：

1. Pixel 是收不到北斗信号，还是收到了但不用于定位？
2. 如果是后者，限制在哪里、以什么方式实现？
3. 定位时不使用北斗星座，会带来多大的影响？

二、现象：不参与定位的北斗

2.1 实验设置

笔者在美国本土（lower 48）找了一块开阔的空地，把 Pixel 11 Pro 和一台中国大陆版小米手机（Redmi K40，型号 M2012K11AC）并排平放，间距约 20 厘米，用同一个采集 App 同时记录了 20 分钟。小米是对照组：它在同一地点、同一时间看到的是同一片天空。

Android 提供了几层可以公开读取的 GNSS 数据，从"收到信号"到"参与定位"，可以逐层检查：

前三层说明 Pixel 收到了北斗信号，信号质量也正常。北斗信号强度的中位数是 32 dB-Hz，与参与定位的 GPS（34 dB-Hz）和 Galileo（31 dB-Hz）相当，可以排除信号太弱而被筛掉的可能。区别只出现在最后一层：Pixel 从不使用北斗卫星进行定位。

2.2 同一秒的两张星空图

下图是两台手机在同一秒看到的天空。圆心是天顶，外圈是地平线；实心标记表示参与定位的卫星，空心表示收到了但没有参与定位；橙色菱形是北斗卫星。

这一秒，Pixel 看到了 6 颗北斗卫星，全部是空心的；GPS、GLONASS 和 Galileo 共 29 颗，其中 26 颗参与了定位。小米看到的 4 颗北斗卫星全部参与了定位。

其他星座也有几颗空心标记，这是定位引擎正常的选星：信号太弱或对几何构型贡献不大的卫星不参与计算。北斗的情况不同：在整整 1,200 秒里，Pixel 没有选用过任何一颗北斗卫星。

这也解释了为什么 GPSTest 这类 App 能显示北斗卫星和信号强度：Pixel 并没有对 App 隐藏北斗，只是定位时不使用北斗星座。

三、固件分析：USswitch 配置项

那么北斗是在哪一步被排除的？

3.1 位置是谁算的

手机定位并不是由 Android 计算的。卫星信号的捕获、跟踪、测距和大部分定位解算，都在一颗独立的 GNSS 处理核心上完成，运行的是芯片厂商的固件。Android 负责接收结果，再转交给 App。

Pixel 11 的 GNSS 软件栈来自联发科（MediaTek），定位引擎叫 MNL。手机上报的 GNSS 硬件型号是 MNL_VER_26061601ALPS05_8.10_00。在 Google 公开的官方 OTA 包里，可以找到联发科的 GNSS 服务、守护进程，以及配置文件 MNL_Config.xml。

3.2 配置文件里的六个数字

MNL_Config.xml 第 133 行起有这样一段：

<feature>USswitch
<version>1.0</version>
<config>1</config>
<format>mode,bitmask,min lat, max lat, min long, max long</format>
<setting>1,104,24.5,48.7,-124.6,-69.7</setting>
</feature>

USswitch 处于启用状态（config 为 1）。format 一行说明了六个参数的含义：

Pixel 11、11 Pro 和 11 Pro XL 的这项配置完全相同，三款机型的联发科 GNSS 守护进程和 HAL 也相同。

3.3 地理围栏的范围

把配置中的经纬度范围叠加到地图上，可以得到下图中的矩形。

这个矩形大致覆盖美国本土 48 州，但边缘并不精确：

• 框内包括了一些邻国城市： 加拿大的多伦多、渥太华、蒙特利尔和维多利亚，墨西哥北部的蒂华纳、奇瓦瓦和蒙特雷，以及巴哈马的拿骚。
• 框外漏掉了一些美国领土： 北纬 48.7° 到 49° 之间沿美加边境的一窄条（例如华盛顿州的贝灵厄姆）、华盛顿州西端、缅因州东部（班戈）和明尼苏达州的"西北角"。阿拉斯加、夏威夷和波多黎各也都在框外。

固件中有一段代码会把当前位置与这四个边界比较：位于框内时，内部地区状态为 3；位于框外时为 2。因此，限制是否生效取决于手机所在的位置，而不是购买的版本。Google Store 的规格页也与此一致：同一型号 G7SWN，美国页面的定位系统列表中没有北斗，加拿大页面则列有北斗。比起"美版 Pixel 屏蔽北斗"，更准确的说法是"Pixel 在这个矩形内定位时不使用北斗星座"。

用四个数字近似一个国家，实现简单、运算开销小，代价是会覆盖到邻国，也会漏掉美国自己的一些边缘地区。笔者没有带手机到矩形外实测，离开矩形后北斗能否重新参与定位还有待验证。

3.4 掩码 104：北斗、QZSS 和 NavIC

104 的二进制是 0110 1000（十六进制 0x68），置位的是 0x08、0x20 和 0x40 三位。

配置文件没有注明这三位分别对应哪个星座，而联发科内部的星座编码与 Android API 的编码并不相同。笔者在固件中找到了一段在内部卫星编号与标准卫星编号之间互相转换的代码，根据每一位对应的编号范围推断：

QZSS 和 NavIC 是区域系统，卫星主要位于亚洲上空，在美国本土基本看不到；笔者在美国本土采集的两台手机记录里也没有出现这两个系统的卫星。因此在美国，这个掩码实际影响的只有北斗。

GLONASS 不在掩码中。它和北斗一样没有获得 FCC 的接收授权（见第五节），但 Pixel 11 在美国照常使用 GLONASS 定位：图 1 中 Pixel 看到的 6 颗 GLONASS 卫星全部参与了定位。

3.5 固件如何排除北斗

排除北斗的逻辑主要位于联发科的 GNSS 固件中。这部分固件打包在 OTA 的 modem 分区里，名为 connsys_gnss，是一段约 4.8 MB 的 RISC-V 代码。笔者对它做了静态反汇编，从 USswitch 这个字符串出发，还原出以下处理过程：

1. 读取配置： 固件解析到 USswitch 后，把六个参数依次存入专用的内存字段。
2. 判断地区： 模式和掩码被复制到运行时字段；另一段代码把当前位置与四个经纬度边界比较，得出"框内"或"框外"的状态。
3. 逐颗卫星过滤： 在处理卫星列表时，如果策略已开启、地区状态为生效，并且卫星所属的星座在掩码中，固件就清除这条卫星记录中的一个内部标志位（0x0008）。

用伪代码表示：

if (policy_mode != 0 && region_state_is_active) {
    for (record in satellite_records) {
        if (record.constellation_bit & policy_mask) {  // restricted constellation
            record.flags &= ~0x0008;                    // clear internal flag
        }
    }
}

固件中还有另外两处代码使用同一组模式、状态和掩码，对匹配的卫星做清零处理。另有一条只在模式 2 下执行的路径，会在重建卫星列表时直接跳过这些卫星；Pixel 11 当前使用的是模式 1。

可以把这个机制理解为：不是拔掉天线，而是在点名册上划掉某些名字。信号照常接收，距离照常测量，电文照常解码，原始测量也会交给 Android；只是在决定哪些卫星参与解算时，北斗被排除了。这与第二节的实测一致。从内部标志 0x0008 到 Android 的 usedInFix 之间还有几层转换，笔者没有逐一追踪。

3.6 早期 Pixel 的行为

这一策略并非从 Pixel 11 才开始。

• Pixel 6： 2024 年 7 月，Google 工程师为 Pixel 6/6 Pro 提交了一项配置修改，标题是 “Enable Beidou measurements only in the US”（在美国仅启用北斗测量），同年 9 月合入公开代码库。改动只新增了一行 ConstellationAutoSwitchOffNavOnly="true"，含义是在美国关闭北斗时只关闭导航解算，保留测量。可见此前 Pixel 6 在美国连北斗测量都不提供，这也与第一节提到的 2023 年用户反馈相符；修改之后的行为与 Pixel 11 现在相同。
• Pixel 8a： 它采用另一家芯片厂商的方案，公开的配置文件中有注释 # Disable BDS in the U.S.，下面是 bdsUsedInUSPolicy=2，同一处还有 SBAS 和 QZSS 的同类设置。

三代机型采用了不同的芯片方案和配置写法，结果都是在美国定位时不使用北斗星座。这更像是 Google 统一的产品策略，而不是某家芯片厂商的默认设置。

3.7 小结

配置文件和固件代码表明，Pixel 11 通过 USswitch 在一个覆盖美国本土的经纬度矩形内，把北斗排除在定位解算之外，实测结果也与此一致。104 对应的星座、离开矩形后北斗能否重新参与定位，目前是根据固件推断的，笔者没有修改手机配置做开关对照实验。

四、不使用北斗定位的代价

4.1 方法

由于 Pixel 会把北斗的原始测量提供给 App，我们也可以做一个理想实验：基于收集到的原始数据，分别计算使用和不使用北斗卫星时的位置，比较定位结果的变化。

笔者写了一个简单的单频定位解算器，卫星轨道和钟差的计算使用开源的 RTKLIB。对每台手机自己的原始测量，逐秒解算两次：

• 不使用北斗： GPS + GLONASS + Galileo。
• 使用北斗： 同样的数据和设置，额外加入北斗。

两种解算只有"是否使用北斗"这一项不同，都没有输入系统定位结果或地图坐标。分析取的是开始 5 分钟之后的约 15 分钟，共 898 个历元，两种解算在每个历元都得到了位置。

这个解算器比手机原厂引擎简单得多：它只使用单频观测、逐秒独立求解，没有滤波和传感器融合。所以下面的数字反映的是北斗观测本身包含多少有用信息，而不是 Pixel 解除限制之后定位能改善多少。

4.2 开阔天空

加入北斗后，每秒参与解算的卫星多了约 4 颗，衡量卫星几何分布的 HDOP 下降了 12%～15%，位置散布缩小了 17%～22%。

这里的散布是每个位置点到该组平均位置的距离，衡量的是定位结果的稳定性（精密度），而不是与真实位置的偏差（准确度）。笔者没有专业测量的参考点，只有根据自己的实际位置和卫星图，在地图软件上标记的对应点的经纬度。Pixel 加入北斗之后，平均位置与这个标记点的距离并没有缩小（2.37 m 变为 2.53 m）。因此这组结果说明的是定位更稳定，而不是更准确。

在开阔天空下，GPS、GLONASS 和 Galileo 加起来已经有十几颗卫星，是否使用北斗影响不大。定位更困难的场景，是天空被遮挡的时候。

4.3 天空被遮挡时

城市里的高楼、峡谷里的山壁、车辆的车顶，都会挡住一部分天空。笔者用同一份数据做了一组模拟：在解算之前，删掉被假想障碍物挡住的卫星，再比较使用和不使用北斗的结果。

第一种模拟最简单：只保留高于某个仰角的卫星，相当于四周有一圈等高的遮挡。

遮挡越严重，北斗带来的改善越大。仰角 40° 以下的天空被遮挡后，不使用北斗时散布扩大到 15 米，使用北斗时约为 5 米。

原因可以从下图看出。这段时间里有两颗北斗卫星（C26、C31）位于接近天顶的位置，仰角约 70°。周围的遮挡越高，剩下的卫星就越少，这两颗高仰角卫星的作用也就越大。

第二种模拟是城市街道：假设手机位于一条街道的中线，两侧楼高为 H，街道宽度为 W。

在楼高等于街宽（H/W = 1）的街道上：

• 东西走向： 不使用北斗时，Pixel 的数据只有 73.5% 的历元能解算出位置；使用北斗时为 99.1%。小米分别为 35.3% 和 85.9%。
• 南北走向： 不使用北斗时，Pixel 的数据在所有历元都无法解算；使用北斗时，58% 的历元可以解算。

这里的"能否解算"是针对笔者这个逐秒独立求解的解算器而言的，它要求观测数比未知数至少多一个。手机原厂引擎有滤波和惯性传感器，不会因为某一秒卫星不足就丢失定位。这组数字反映的是可用于定位的独立几何信息减少了多少。

这些模拟只删掉了被遮挡的卫星，没有模拟城市环境中的信号衰减、多路径和反射，而且只来自一个地点、一段 15 分钟的数据。它说明的是一个趋势：天空越受限、定位越困难的地方，多一个星座的价值越大。

五、监管背景：FCC 的授权规则

5.1 接收外国卫星信号也需要授权

按照 FCC 的规定（47 CFR §25.115(b)(9)），在美国境内运行、只接收外国卫星系统信号的设备，原则上也需要获得许可，除非该外国系统已获准进入美国市场。美国政府的 GPS.gov 明确说明，这条规定适用于接收外国卫星导航信号的设备。

截至目前，获得 FCC 一般授权的外国卫星导航系统只有欧盟的 Galileo：

• 2018 年： FCC 批准美国境内的设备接收 Galileo 的 E1 和 E5 信号，但拒绝了 E6 信号（FCC 18-158）。
• 2025 年 3 月： FCC 发布征询意见书（FCC 25-20），明确指出北斗和 GLONASS 的信号未经授权，Galileo 是唯一申请并获得批准的外国 GNSS 星座。日本 QZSS 和印度 NavIC 也没有获得一般授权（参见 2024 年美国 PNT 咨询委员会会议记录）。

申请授权的程序于 2011 年建立，只能由运营该星座的外国政府发起。

5.2 行业的看法

2024 年 3 月 19 日，代表 GNSS 芯片和设备厂商的行业组织 GPS 创新联盟（GPSIA）就外国卫星导航系统发表了声明。同年 5 月，FCC 主席在回复国会议员质询的信中表示，正在调查设备接收和处理未经授权 GNSS 信号的问题。GPSIA 声明的主要观点包括：

• 几十年来，FCC 从未对正在使用的数十亿台接收机的运营者采取过行动（“the FCC has never acted against operators of the billions of receivers in operation”）。
• 这套审批流程是为了推进美国的贸易政策而设立的，而不是为了防范安全威胁（“created to advance U.S. trade policies, not to guard against security threats”）。
• 多星座接收机能够识别某个星座的信号是否异常，并决定信任哪些信号、丢弃哪些信号；能"听到"的卫星越多，定位越准确。只依赖少数星座，反而可能促使对手针对这些系统。
• 声明还引用了时任 FCC 委员、后来出任主席的 Jessica Rosenworcel 在 2018 年 Galileo 决定中说的话：“技术已经走在了我们的审批政策前面，是时候校正了”（"[t]echnology has gotten ahead of our approval policies and it’s time for a true-up"）。

GPSIA 呼吁 FCC 更新这些规则。

5.3 Google 排除的星座与 FCC 的授权范围并不一致

按照 FCC 的授权状态，美国境内只有 GPS 和 Galileo（E1、E5）在授权范围内，北斗、GLONASS、QZSS 和 NavIC 都不在其中。

Pixel 11 的实际做法是排除北斗、QZSS 和 NavIC，保留 GLONASS。早在 2014 年美国 PNT 咨询委员会的会议记录中，就有与会者指出 GPS 与 GLONASS 的组合定位早已广泛使用；FCC 官员当时回应，使用 GLONASS 仍然需要授权。

笔者没有找到 Google 解释这份名单的公开文件。一个可能的解释是，GLONASS 很早就进入了成熟的多星座定位方案，厂商保留了长期验证过的组合，而对较晚普及的北斗等系统另行设置了地区限制。这只是推测。从结果看，USswitch 并不是 FCC 授权名单的完整实现；由于日本和印度的定位系统同样在掩码中，它也不能简单解释为只针对中国的定位星座。

六、总结

Pixel 11 在美国能接收北斗信号，也把北斗数据开放给了 App，只是系统定位过程中不使用北斗星座。实现方式是一个由四个数字定义的经纬度矩形和一个三位的掩码。从 Pixel 6 到 Pixel 11，三代机型、三种芯片方案都保持了相同的结果。

在开阔天空下，这一限制的影响不大：GPS、GLONASS 和 Galileo 已经足够，加入北斗后位置散布缩小约 20%。但在高楼林立的街道、峡谷或山区，天空被遮挡一大半时，北斗提供的额外卫星往往决定了定位结果是否可用、偏差有多大，而这些恰好是用户最需要定位的场景。笔者的模拟只考虑了卫星被遮挡，真实城市环境更复杂，但趋势是明确的。

对 Google 来说，这是合规与用户体验之间的取舍。FCC 的规则明确把北斗列为未经授权，2024 年以来相关的政治和监管关注也在增加；作为美国公司，Google 选择在美国境内定位时不使用北斗，是一种可以理解的保守做法。它也保留了一定的开放：北斗的原始测量照常提供给 App，研究者和专业应用仍然可以自行使用。

这种做法也有值得商榷的地方：

• 规则本身的合理性： 正如 GPSIA 和 Rosenworcel 所说，这套规则产生于多星座接收机普及之前。GPSIA 还认为，多星座接收在安全上是优势而不是弱点。
• 实现的一致性： 同样未经授权的 GLONASS 照常参与定位，说明现有的限制既不完全对应 FCC 的规则，也难以用单一的安全逻辑解释。
• 对用户的透明度： Pixel 10 及更早机型的规格页写明了美国版不支持北斗，Pixel 11 的规格页则不再列出具体星座；限制按位置生效，手机界面也不会提示，普通用户很难知道自己的定位少了一个星座。

美国用户为这套规则付出的代价，在大多数时候很小，在少数困难的场景里却可能很明显。这个代价并非来自技术限制，而是来自监管规则和厂商的合规选择。如何在安全考量和用户利益之间取得平衡，取决于监管规则如何更新，也取决于厂商如何实现。

附录：实验与分析方法

• 设备： Pixel 11 Pro（G7SWN，美国购买，Android 17，CD1A.261005.003）；小米 Redmi K40（M2012K11AC，中国大陆版）作为对照。
• 采集： 美国本土（lower 48）一处开阔场地，两台手机静止并排平放 20 分钟。采集 App 只记录 Android 公开 API 提供的数据（卫星状态、原始测量、导航电文、NMEA、系统位置），没有 root，也没有修改手机配置。
• 固件分析： 对象是 Google 公开发布的同版本 OTA 包。配置文件直接读取；connsys_gnss 固件做静态反汇编。
• 配对解算： 每颗卫星使用一个频点（GPS L1 C/A、GLONASS L1、Galileo E1、北斗 B1I），C/N0 ≥ 25 dB-Hz，仰角 ≥ 10°；使用广播星历和钟差，改正对流层延迟和地球自转；每个星座独立估计一个接收机钟差；加权最小二乘逐秒求解。没有使用电离层改正、载波平滑或差分。改用等权或加入电离层改正后，结果的方向和幅度基本一致。
• 遮挡模拟： 卫星方位和仰角由广播星历和每台手机自己解算的平均位置计算。均匀遮挡按仰角删除卫星；街道模型中，方位角 az 处的遮挡仰角为 atan(2·H/W·|sin(az − 街道方向)|)。