Design and Implementation of a DR+GNSS Playback Tool for Amap Car Navigation on Android

Introduction

DR (Dead Reckoning) uses sensors such as gyroscopes, wheel speed, vehicle speed pulses, and 3D accelerometers to estimate position. In vehicle navigation, dead‑reckoning calculates the current position based on a previously known location, the distance traveled, and the heading. Because DR accumulates error over time, it must be corrected with GNSS data.

In many OEM pre‑installation projects, manufacturers adopt a DR+GNSS solution to provide more accurate positioning. Existing GPS playback apps only handle GNSS data, requiring on‑vehicle road tests for verification, which is costly and time‑consuming. Not every project can afford real‑vehicle testing.

This article introduces the DR+GNSS playback solution for Amap’s Android car‑navigation platform.

Gaode Car Navigation DR Mode

Frontend Fusion Mode

DR is divided into frontend and backend fusion. In frontend fusion, the hardware or system side performs sensor fusion, and the navigation app only handles map matching. The navigation system receives already‑fused signals, which may include data even when the vehicle is not yet positioned. Frontend fusion can also include an MMF (Map‑Matching Feedback) mode that corrects drift, especially in tunnels, by feeding back map‑matching information.

Fusion signals combine GPS, gyroscope, accelerometer, and pulse data into a trajectory.

Backend Fusion Mode

In backend fusion, the navigation engine itself performs sensor fusion using raw inputs (GPS, gyroscope, pulse, accelerometer). The fused signal is tightly coupled with map data and the navigation protocol. GPS is used only at startup; during driving, the inertial navigation system provides the primary position, with GPS corrections applied only when needed, allowing accurate navigation even when GPS signals are degraded or lost.

Previous Android playback tools recorded latitude/longitude and fed them to the native mock‑location API, which only supports GPS mode. DR playback requires sensor data, which Android does not natively mock.

Limitations

The native mock‑location approach only supports GPS and cannot simulate the sensor data needed for DR.

The prior QA verification flow for DR required on‑vehicle testing, which was labor‑intensive.

Solution Design

The playback tool mimics the original inter‑process communication used by Gaode’s navigation system, running in a separate process.

Both frontend and backend fusion playback use a custom AIDL protocol.

Playback File Selection

Two file sources are supported: (1) custom‑format logs saved by the HMI, and (2) existing navigation engine log files. The latter was chosen to avoid extra storage overhead on the head‑unit.

Playback Implementation Options

Option 1: Use cross‑process AIDL to transmit data to the navigation app. Option 2: Integrate the playback feature directly into the navigation app as an easter‑egg.

The pros and cons of each option are illustrated below.

We selected the independent‑process approach.

The tool reuses the JSON format of Gaode’s backend‑fusion protocol to faithfully reproduce the signal flow.

With this tool, QA can verify positioning issues in as little as 0.5 hour instead of a 2‑hour road test, and remote issues can be reproduced locally.

Feedback on the Old Solution and New Optimizations

Old Solution Issues

The previous tool was widely used but had several problems:

Five manual steps were required to start playback.

Restoring the positioning context often failed without clear diagnostics.

Custom data paths on different head‑units forced users to adjust the tool each time.

Optimization Plan

We reduced the workflow to a single‑click playback, added an AIDL call to retrieve the custom data path automatically, and improved error handling for permission‑related failures.

Conclusion

The playback tool dramatically reduces the time and manpower required for positioning problem verification and road‑test reproduction on Gaode’s Android car‑navigation platform, improving the efficiency of both R&D and QA teams.