Use RTK Positioning in Android Apps

After Kalmix Scope has established a corrected RTK solution and Android Mock Location is enabled, compatible Android apps can reuse the injected system location without implementing their own USB or NTRIP workflow.

This guide demonstrates the system-level injection path with two examples: QField for GIS fieldwork and Google Maps as a basic consumer-app check. Use Quick Evaluation with Kalmix Scope first if the bridge workflow is not already running.

Architecture context

This page follows Architecture B: System-level injection. Kalmix Scope publishes the corrected position through Android Mock Location. Apps that consume Android system location can then reuse the injected coordinates. App behavior can vary: some applications use their own positioning stack, reject mock locations, or do not expose RTK-quality metadata.

Before you start

Complete the Scope quick-evaluation workflow before testing downstream applications.

Kalmix Scope is running Keep the bridge app active while testing another Android application.
RTK Fix has been verified Use Scope to confirm the corrected solution before judging an application-side result.
Mock Location is enabled Assign Kalmix Scope as the Android mock-location provider.
The target app is installed Start with QField or Google Maps, then evaluate other compatible Android apps.

Choose an application example

These two examples demonstrate different uses of the same injected system location. They do not require a new NTRIP connection inside the downstream app.

QField: use the injected Android system location

QField supports internal and saved external GNSS positioning devices. In this workflow, select Internal receiver so QField consumes the Android system location published by Kalmix Scope. Do not configure a separate external GNSS connection inside QField for this path.

01

Open a QField project

Launch QField and open an existing project or create a project for your field workflow.

QField launch screen on Android.
Fig. 1: Launch QField.
QField project opened on Android.
Fig. 2: Open a QField project.
02

Select the internal receiver

Open the QField settings, navigate to the positioning section, and select Internal receiver. In this architecture, “internal” means the Android system location source, which Scope has already updated through Mock Location.

QField settings entry.
Fig. 3: Open QField settings.
QField positioning settings screen.
Fig. 4: Open the positioning settings.
QField internal receiver selected as the positioning source.
Fig. 5: Select Internal receiver.
03

Activate positioning and review the result

Return to the map, activate positioning, and open the GNSS information panel. Use Scope as the primary source for RTK Fix verification; use QField to confirm that the injected system location is available inside the field application.

QField map view with positioning activated.
Fig. 6: Activate positioning in QField.
QField GNSS information panel.
Fig. 7: Review the QField GNSS panel.
QField map view using the injected Android system location.
Fig. 8: Continue the QField workflow with the injected position.

Why this page does not configure an external GNSS device in QField

QField can also connect to saved external GNSS devices through supported NMEA connection methods. That is a different integration path. This guide intentionally demonstrates Android system-level injection through Scope and Mock Location.

Google Maps: check a standard consumer app

Google Maps does not need a separate receiver connection or NTRIP setup in this workflow. Open the app and check whether the displayed position follows the injected Android system location.

01

Open Google Maps and center the position

Launch Google Maps and tap the location control to center the map on the current Android system location.

Google Maps opened on Android.
Fig. 9: Open Google Maps.
Google Maps centered on the current Android system location.
Fig. 10: Center the map on the current position.

Use Scope, not the base map, to verify RTK quality

Google Maps is useful as a consumer-app check, but it is not a centimeter-level validation tool. The map imagery, road geometry, UI rendering, and location marker may not expose the receiver’s RTK status or represent the corrected coordinate with survey-grade precision.

What other Android apps can use this workflow?

Mock Location is most useful when an application reads the Android system location and does not require its own external-receiver connection. Test each target app before deployment because app behavior can vary.

Suitable starting point Apps that consume Android system location and do not manage their own NTRIP workflow.
Verify in Scope first Confirm RTK Fix in the bridge app before evaluating downstream application behavior.
Test the target app Some apps may reject mock locations, use a separate positioning stack, or hide accuracy metadata.

Continue with Android integration

Need help validating a specific Android application? Contact Kalmix support →

Product selection

Choosing between SCOUT and SCOUT PRO?

Compare the two receiver configurations and choose the right starting point for your integration.