BeiDou Left Out of Positioning: The GNSS Geofencing Policy on Pixel Phones

TL;DR

• A Pixel 11 Pro used in the US receives BeiDou satellite signals normally and also passes BeiDou raw measurements and navigation messages to apps, but the system does not use the BeiDou constellation when computing a position.
• The restriction is written in the USswitch entry of MediaTek’s GNSS configuration file: inside a latitude/longitude rectangle that roughly covers the contiguous US, the firmware excludes BeiDou (along with Japan’s QZSS and India’s NavIC) from the position solution. GLONASS is not affected.
• Re-solving the raw data recorded by the phones shows that under open sky, adding BeiDou shrinks the position scatter by about 20%; in simulated obstructed environments, the improvement from adding BeiDou is clearly larger.
• This practice is related to the FCC’s authorization rules for foreign satellite navigation systems, but the constellations Google excludes do not fully match the constellations the FCC has not authorized.

1. Background

On Google’s Pixel hardware tech specs page, Pixel 10 and earlier models list the positioning systems separately for the US version and for other regions:

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

The US list does not include BeiDou, QZSS or NavIC. For the Pixel 11 series, this entry only says “Dual Band Multi-constellation GNSS” and does not list specific constellations.

Users have also discussed this online. In July 2023, a Pixel 6 Pro user posted in the GPSTest discussion group, reporting that BeiDou had been disabled in the US. Sean Barbeau, the author of GPSTest, noted in his reply that from an app’s point of view, how the phone ultimately computes its position is “effectively a black box”. There is a similar discussion on Reddit.

I have a Pixel 11 Pro bought in the US (Android 17, build CD1A.261005.003), so I wanted to answer three questions:

1. Does the Pixel fail to receive BeiDou signals, or does it receive them but not use them for positioning?
2. If the latter, where is the restriction and how is it implemented?
3. How much does not using the BeiDou constellation affect positioning?

2. The observation: BeiDou not used in positioning

2.1 Experimental setup

I found an open field in the contiguous US (lower 48) and laid the Pixel 11 Pro flat next to a mainland-China Xiaomi phone (Redmi K40, model M2012K11AC), about 20 cm apart, recording simultaneously for 20 minutes with the same logging app. The Xiaomi serves as the control: at the same place and time, it sees the same sky.

Android exposes several layers of publicly readable GNSS data, from “signal received” to “used in positioning”, which can be checked layer by layer:

The first three layers show that the Pixel receives BeiDou signals, and the signal quality is normal. The median BeiDou signal strength is 32 dB-Hz, comparable to the GPS (34 dB-Hz) and Galileo (31 dB-Hz) satellites used in positioning, which rules out BeiDou being filtered out for weak signals. The difference only appears in the last layer: the Pixel never uses BeiDou satellites for positioning.

2.2 Two sky plots from the same second

The figure below shows the sky seen by the two phones in the same second. The centre is the zenith and the outer ring is the horizon; filled markers are satellites used in positioning, hollow markers are satellites received but not used in positioning; orange diamonds are BeiDou satellites.

In this second, the Pixel saw 6 BeiDou satellites, all hollow; of 29 GPS, GLONASS and Galileo satellites, 26 were used in positioning. All 4 BeiDou satellites seen by the Xiaomi were used in positioning.

A few satellites of other constellations are also hollow. This is the positioning engine’s normal satellite selection: satellites with signals that are too weak or that contribute little to the geometry are not used in the computation. BeiDou is different: over the full 1,200 seconds, the Pixel never selected a single BeiDou satellite.

This also explains why apps such as GPSTest can show BeiDou satellites and their signal strength: the Pixel does not hide BeiDou from apps; it just does not use the BeiDou constellation for positioning.

3. Firmware analysis: the USswitch configuration entry

So at which step is BeiDou excluded?

3.1 Who computes the position

A phone’s position is not computed by Android. Signal acquisition, tracking, ranging and most of the position solution are done on a separate GNSS processing core running the chip vendor’s firmware. Android receives the results and passes them on to apps.

The Pixel 11’s GNSS software stack comes from MediaTek, and its positioning engine is called MNL. The GNSS hardware model string reported by the phone is MNL_VER_26061601ALPS05_8.10_00. In Google’s publicly released full OTA packages, you can find MediaTek’s GNSS service, daemon and the configuration file MNL_Config.xml.

3.2 Six numbers in a configuration file

Starting at line 133, MNL_Config.xml contains this block:

<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 is enabled (config is 1). The format line describes the six parameters:

This entry is identical on the Pixel 11, 11 Pro and 11 Pro XL, and the three models also share the same MediaTek GNSS daemon and HAL.

3.3 The extent of the geofence

Overlaying the latitude/longitude limits from the configuration on a map gives the rectangle in the figure below.

The rectangle roughly covers the 48 contiguous states, but its edges are not precise:

• Some cities in neighbouring countries fall inside the box: Toronto, Ottawa, Montreal and Victoria in Canada; Tijuana, Chihuahua and Monterrey in northern Mexico; and Nassau in the Bahamas.
• Some US territory falls outside the box: a narrow strip along the US–Canada border between 48.7°N and 49°N (for example, Bellingham, Washington), the western tip of Washington, eastern Maine (Bangor), and Minnesota’s Northwest Angle. Alaska, Hawaii and Puerto Rico are also outside the box.

The firmware contains code that compares the current position against these four boundaries: inside the box the internal region state is 3; outside it is 2. Whether the restriction applies therefore depends on where the phone is, not on which version was bought. The Google Store specs pages are consistent with this: for the same model, G7SWN, the positioning systems listed on the US page do not include BeiDou, while the Canadian page does. Rather than “US Pixels block BeiDou”, it is more accurate to say “Pixels do not use the BeiDou constellation for positioning inside this rectangle”.

Approximating a country with four numbers is simple to implement and cheap to compute, at the cost of covering parts of neighbouring countries and missing some edges of the US itself. I did not take the phone outside the rectangle to test it, so whether BeiDou takes part in positioning again after leaving the rectangle remains to be verified.

3.4 Mask 104: BeiDou, QZSS and NavIC

104 in binary is 0110 1000 (hexadecimal 0x68); the bits set are 0x08, 0x20 and 0x40.

The configuration file does not state which constellation each of these three bits corresponds to, and MediaTek’s internal constellation encoding is different from the Android API’s. I found code in the firmware that converts between internal satellite numbers and standard satellite numbers, and inferred the mapping from the number range associated with each bit:

QZSS and NavIC are regional systems whose satellites are mainly over Asia and are essentially not visible from the contiguous US; neither system’s satellites appeared in the records of the two phones I collected in the contiguous US. In the US, therefore, this mask in practice only affects BeiDou.

GLONASS is not in the mask. Like BeiDou, it has no FCC authorization for reception (see Section 5), but the Pixel 11 uses GLONASS for positioning in the US as usual: all 6 GLONASS satellites seen by the Pixel in Figure 1 were used in positioning.

3.5 How the firmware excludes BeiDou

The logic that excludes BeiDou lives mainly in MediaTek’s GNSS firmware. This firmware is packaged in the OTA’s modem partition under the name connsys_gnss, a roughly 4.8 MB block of RISC-V code. I statically disassembled it and, starting from the string USswitch, reconstructed the following process:

1. Read the configuration: after parsing USswitch, the firmware stores the six parameters in dedicated memory fields one by one.
2. Determine the region: the mode and mask are copied to runtime fields; another piece of code compares the current position with the four latitude/longitude boundaries and derives an “inside the box” or “outside the box” state.
3. Filter satellite by satellite: when processing the satellite list, if the policy is enabled, the region state is active, and the satellite’s constellation is in the mask, the firmware clears an internal flag bit (0x0008) in that satellite’s record.

In pseudocode:

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
        }
    }
}

Two other places in the firmware use the same mode, state and mask to zero out matching satellites. There is also a path that runs only in mode 2 and skips these satellites entirely when rebuilding the satellite list; the Pixel 11 currently uses mode 1.

One way to think of this mechanism: it does not unplug the antenna; it crosses certain names off the roll call. Signals are received, ranges are measured, and messages are decoded as usual, and the raw measurements are still handed to Android; BeiDou is only excluded when deciding which satellites take part in the solution. This is consistent with the measurements in Section 2. Between the internal flag 0x0008 and Android’s usedInFix there are several more layers of conversion, which I did not trace one by one.

3.6 Behaviour of earlier Pixels

This policy did not start with the Pixel 11.

• Pixel 6: In July 2024, a Google engineer submitted a configuration change for the Pixel 6/6 Pro titled “Enable Beidou measurements only in the US”, merged into the public repository in September of that year. The change adds a single line, ConstellationAutoSwitchOffNavOnly="true", meaning that when BeiDou is switched off in the US, only navigation is switched off and measurements are kept. This shows that before the change, the Pixel 6 did not even provide BeiDou measurements in the US, which also matches the 2023 user report mentioned in Section 1; after the change, its behaviour is the same as the Pixel 11’s today.
• Pixel 8a: It uses another chip vendor’s solution. Its public configuration file contains the comment # Disable BDS in the U.S. followed by bdsUsedInUSPolicy=2, with similar settings for SBAS and QZSS in the same place.

Three generations of devices use different chip solutions and different configuration syntax, yet the result is the same: the BeiDou constellation is not used for positioning in the US. This looks more like a unified Google product policy than a default setting of any one chip vendor.

3.7 Summary

The configuration file and firmware code show that, through USswitch, the Pixel 11 excludes BeiDou from the position solution inside a latitude/longitude rectangle covering the contiguous US, and the measurements are consistent with this. The constellations corresponding to 104, and whether BeiDou takes part in positioning again after leaving the rectangle, are currently inferred from the firmware; I did not modify the phone’s configuration to run an on/off comparison.

4. The cost of not using BeiDou for positioning

4.1 Method

Since the Pixel provides BeiDou raw measurements to apps, we can also run an idealized experiment: based on the collected raw data, compute positions with and without BeiDou satellites and compare how the positioning results change.

I wrote a simple single-frequency positioning solver, using the open-source RTKLIB to compute satellite orbits and clocks. Each phone’s own raw measurements are solved twice per second:

• Without BeiDou: GPS + GLONASS + Galileo.
• With BeiDou: the same data and settings, with BeiDou added.

The two solutions differ only in whether BeiDou is used; neither takes the system position or map coordinates as input. The analysis uses about 15 minutes starting 5 minutes into the session, 898 epochs in total, and both solutions produced a position at every epoch.

This solver is much simpler than the phone’s own engine: it uses only single-frequency observations and solves each second independently, without filtering or sensor fusion. The numbers below therefore reflect how much useful information the BeiDou observations themselves contain, not how much the Pixel’s positioning would improve if the restriction were lifted.

4.2 Open sky

With BeiDou added, about 4 more satellites take part in the solution each second, HDOP (a measure of satellite geometry) drops by 12%–15%, and position scatter shrinks by 17%–22%.

Scatter here is the distance from each position to the mean position of its group. It measures the stability of the positioning results (precision), not the deviation from the true position (accuracy). I do not have a professionally surveyed reference point, only the latitude and longitude of a point marked in a map app based on my actual location and the satellite imagery. After adding BeiDou, the distance between the Pixel’s mean position and this marked point did not shrink (2.37 m became 2.53 m). These results therefore show that positioning becomes more stable, not more accurate.

Under open sky, GPS, GLONASS and Galileo together already provide a dozen or more satellites, so whether BeiDou is used makes little difference. The harder scenario for positioning is when the sky is obstructed.

4.3 When the sky is obstructed

Tall buildings in cities, canyon walls and vehicle roofs all block part of the sky. I ran a set of simulations on the same data: before solving, remove the satellites blocked by a hypothetical obstruction, then compare the results with and without BeiDou.

The first simulation is the simplest: keep only satellites above a given elevation angle, equivalent to an obstruction of uniform height all around.

The heavier the obstruction, the larger the improvement from BeiDou. With the sky below 40° elevation blocked, the scatter grows to 15 m without BeiDou and is about 5 m with BeiDou.

The reason can be seen in the figure below. During this period, two BeiDou satellites (C26, C31) were close to the zenith, at about 70° elevation. The higher the surrounding obstruction, the fewer satellites remain, and the more these two high-elevation satellites matter.

The second simulation is a city street: assume the phone is on the centreline of a street of width W with buildings of height H on both sides.

On a street where building height equals street width (H/W = 1):

• East–west street: without BeiDou, only 73.5% of the Pixel’s epochs can be solved; with BeiDou, 99.1%. For the Xiaomi, the figures are 35.3% and 85.9%.
• North–south street: without BeiDou, none of the Pixel’s epochs can be solved; with BeiDou, 58% of epochs can be solved.

“Can be solved” here refers to my solver, which solves each second independently and requires at least one more observation than unknowns. The phone’s own engine has filtering and inertial sensors and does not lose its fix just because one second lacks satellites. These numbers reflect how much independent geometric information for positioning is lost.

These simulations only remove obstructed satellites; they do not model the signal attenuation, multipath and reflections of an urban environment, and they come from one location and one 15-minute data set. What they show is a trend: the more restricted the sky and the harder the positioning, the more valuable an extra constellation becomes.

5. Regulatory background: the FCC’s authorization rules

5.1 Receiving foreign satellite signals also requires authorization

Under FCC rules (47 CFR §25.115(b)(9)), equipment operating in the US that only receives signals from a foreign satellite system also needs a license in principle, unless that foreign system has been granted access to the US market. The US government’s GPS.gov states explicitly that this rule applies to equipment receiving foreign satellite navigation signals.

To date, the only foreign satellite navigation system with general FCC authorization is the EU’s Galileo:

• 2018: The FCC approved the reception of Galileo’s E1 and E5 signals by equipment in the US, but denied the E6 signal (FCC 18-158).
• March 2025: The FCC issued a Notice of Inquiry (FCC 25-20) stating explicitly that BeiDou and GLONASS signals are unauthorized and that Galileo is the only foreign GNSS constellation that has applied for and received approval. Japan’s QZSS and India’s NavIC have not received general authorization either (see the minutes of a 2024 US PNT Advisory Board meeting).

The application process was established in 2011 and can only be initiated by the foreign government operating the constellation.

5.2 The industry’s view

On March 19, 2024, the GPS Innovation Alliance (GPSIA), an industry group representing GNSS chip and device makers, issued a statement on foreign satellite navigation systems. In May of the same year, the FCC Chair said in a letter replying to inquiries from members of Congress that the FCC was investigating devices receiving and processing unauthorized GNSS signals. The main points of the GPSIA statement include:

• Over the decades, “the FCC has never acted against operators of the billions of receivers in operation”.
• The approval process was “created to advance U.S. trade policies, not to guard against security threats”.
• Multi-constellation receivers can recognize when one constellation’s signals behave abnormally and decide which signals to trust and which to discard; the more satellites a receiver can “hear”, the greater the accuracy. Relying on fewer constellations could instead incentivize adversaries to target those systems.
• The statement also quotes Jessica Rosenworcel, then an FCC Commissioner and later Chairwoman, in the 2018 Galileo decision: “[t]echnology has gotten ahead of our approval policies and it’s time for a true-up.”

GPSIA called on the FCC to update these rules.

5.3 The constellations Google excludes do not match the FCC’s authorization scope

By the FCC’s authorization status, only GPS and Galileo (E1, E5) are within the authorized scope in the US; BeiDou, GLONASS, QZSS and NavIC are all outside it.

What the Pixel 11 actually does is exclude BeiDou, QZSS and NavIC while keeping GLONASS. As early as the minutes of a 2014 US PNT Advisory Board meeting, participants pointed out that combined GPS and GLONASS positioning was already widely used; an FCC official responded at the time that using GLONASS still required authorization.

I found no public document from Google explaining this list. One possible explanation is that GLONASS entered mature multi-constellation positioning solutions early, so vendors kept a long-validated combination while setting separate regional restrictions for systems that became widespread later, such as BeiDou. This is only speculation. As it stands, USswitch is not a complete implementation of the FCC’s authorization list; and since the Japanese and Indian positioning systems are also in the mask, it cannot simply be explained as targeting only China’s positioning constellation.

6. Conclusion

The Pixel 11 can receive BeiDou signals in the US and makes BeiDou data available to apps, but the system does not use the BeiDou constellation when computing positions. The implementation is a latitude/longitude rectangle defined by four numbers and a three-bit mask. From the Pixel 6 to the Pixel 11, three generations of devices and three chip solutions have kept the same result.

Under open sky, the restriction has little impact: GPS, GLONASS and Galileo are enough, and adding BeiDou shrinks the position scatter by about 20%. But on streets lined with tall buildings, in canyons or in mountains, when most of the sky is blocked, the extra satellites BeiDou provides often determine whether the position is usable and how far off it is, and these are exactly the scenarios where users most need positioning. My simulations only considered blocked satellites, and real urban environments are more complex, but the trend is clear.

For Google, this is a trade-off between compliance and user experience. FCC rules explicitly classify BeiDou as unauthorized, and political and regulatory attention to the issue has grown since 2024; as a US company, Google’s choice not to use BeiDou for positioning within the US is an understandable, conservative approach. It also keeps a degree of openness: BeiDou raw measurements are still provided to apps, and researchers and professional applications can still use them on their own.

This approach also has debatable aspects:

• Whether the rules themselves make sense: As GPSIA and Rosenworcel said, these rules predate the spread of multi-constellation receivers. GPSIA also argues that multi-constellation reception is a security strength rather than a weakness.
• Consistency of the implementation: GLONASS, equally unauthorized, is still used in positioning, which shows that the current restriction neither fully corresponds to the FCC’s rules nor is easy to explain with a single security rationale.
• Transparency to users: The specs pages for Pixel 10 and earlier models state that the US version does not support BeiDou, while the Pixel 11 specs page no longer lists specific constellations; the restriction takes effect based on location, and the phone’s interface gives no indication, so ordinary users can hardly know their positioning is missing a constellation.

The cost US users pay for these rules is small most of the time, but can be significant in a few difficult scenarios. This cost does not come from technical limitations, but from regulatory rules and vendors’ compliance choices. How to balance security considerations against user interests depends both on how the regulatory rules are updated and on how vendors implement them.

Appendix: Experimental and analysis methods

• Devices: Pixel 11 Pro (G7SWN, bought in the US, Android 17, CD1A.261005.003); Xiaomi Redmi K40 (M2012K11AC, mainland-China version) as the control.
• Data collection: An open field in the contiguous US (lower 48); the two phones lay still side by side for 20 minutes. The logging app only recorded data provided by Android’s public APIs (satellite status, raw measurements, navigation messages, NMEA, system position), without root and without modifying the phones’ configuration.
• Firmware analysis: Performed on Google’s publicly released OTA package for the same build. The configuration file was read directly; the connsys_gnss firmware was statically disassembled.
• Paired solutions: One signal per satellite (GPS L1 C/A, GLONASS L1, Galileo E1, BeiDou B1I), C/N0 ≥ 25 dB-Hz, elevation ≥ 10°; broadcast ephemerides and clocks, with tropospheric delay and Earth rotation corrections; one receiver clock bias estimated per constellation; weighted least squares solved each second. No ionospheric correction, carrier smoothing or differential corrections were used. With equal weights or with ionospheric correction added, the direction and magnitude of the results were essentially the same.
• Obstruction simulation: Satellite azimuth and elevation were computed from broadcast ephemerides and the mean position solved from each phone’s own data. Uniform obstruction removes satellites by elevation; in the street model, the obstruction elevation at azimuth az is atan(2·H/W·|sin(az − street direction)|).