The Android Emulator provides three ways to set a fake GPS location: the Extended Controls UI in Android Studio, the geo fix command over a console connection, and the adb emu command from a terminal. Each approach serves a different workflow, from quick manual testing to scripted CI pipelines. This article covers all three methods with working examples, explains how to simulate routes, and addresses the common issues developers encounter.

Method 1: Extended Controls UI

This is the fastest approach for manual testing. It provides a map interface for picking locations visually.

1. Launch your AVD from the AVD Manager in Android Studio.
2. Click the three-dot menu (...) in the emulator toolbar to open Extended Controls.
3. Select the Location tab.
4. Enter latitude and longitude manually, or click a point on the map.
5. Click Send to push the location to the emulator.

The emulator also supports loading GPX and KML route files from this panel. Drag a GPX file onto the map area or use the Load GPX/KML button to import a route, then play it back at configurable speed. This is the easiest way to test driving navigation, fitness tracking, or geofencing scenarios.

Setting a Location Programmatically in Tests

If you are running instrumented tests and need to mock location, use the FusedLocationProviderClient test API rather than the emulator controls:

1import com.google.android.gms.location.FusedLocationProviderClient
2import com.google.android.gms.location.LocationServices
3
4val fusedClient: FusedLocationProviderClient =
5    LocationServices.getFusedLocationProviderClient(context)
6
7val mockLocation = Location("mock").apply {
8    latitude = 37.4220
9    longitude = -122.0841
10    accuracy = 10f
11    time = System.currentTimeMillis()
12    elapsedRealtimeNanos = SystemClock.elapsedRealtimeNanos()
13}
14
15fusedClient.setMockMode(true)
16fusedClient.setMockLocation(mockLocation)

This approach works in both emulator and physical device test runs (with developer options enabled).

Method 2: Console geo fix Command

For scripted testing, connect to the emulator's console over TCP and send geo fix commands. This is useful for CI pipelines or shell scripts that need to change location programmatically.

# Connect to the emulator console
# The default port for the first emulator is 5554
adb emu geo fix -122.0841 37.4220

Note the parameter order: longitude comes first, then latitude. This is the opposite of what most mapping APIs use and is a frequent source of confusion.

If you need to use the raw telnet interface:

1# First, get the auth token
2cat ~/.emulator_console_auth_token
3
4# Connect and authenticate
5telnet localhost 5554
6auth <paste-token-here>
7geo fix -122.0841 37.4220

To simulate movement, send a sequence of geo fix commands with a delay between each:

1#!/bin/bash
2# Simulate walking along a street
3locations=(
4    "-122.0841 37.4220"
5    "-122.0845 37.4222"
6    "-122.0850 37.4225"
7    "-122.0855 37.4228"
8    "-122.0860 37.4230"
9)
10
11for loc in "${locations[@]}"; do
12    adb emu geo fix $loc
13    sleep 2
14done

Method 3: ADB Shell Commands

You can also set mock location through ADB shell commands, which is useful when you need to broadcast location changes to apps that listen for location intents:

1# Set mock location via the emulator console through ADB
2adb emu geo fix -122.0841 37.4220
3
4# Alternatively, use the Android shell to set system properties
5adb shell settings put secure mock_location 1

For automated test suites that run on CI, the adb emu approach is preferred because it does not require establishing a separate telnet connection.

Comparison of Methods

Setting Up GPX Route Files

GPX files let you define a series of waypoints with timestamps. The emulator plays them back in order, simulating real movement.

1<?xml version="1.0" encoding="UTF-8"?>
2<gpx version="1.1" creator="manual">
3  <trk>
4    <name>Test Route</name>
5    <trkseg>
6      <trkpt lat="37.4220" lon="-122.0841">
7        <time>2025-01-01T00:00:00Z</time>
8      </trkpt>
9      <trkpt lat="37.4225" lon="-122.0845">
10        <time>2025-01-01T00:00:10Z</time>
11      </trkpt>
12      <trkpt lat="37.4230" lon="-122.0850">
13        <time>2025-01-01T00:00:20Z</time>
14      </trkpt>
15    </trkseg>
16  </trk>
17</gpx>

Load this file in the Extended Controls Location tab. The emulator interpolates between waypoints based on the timestamps, producing a realistic movement pattern.

Testing Edge Cases

Location-based apps should be tested against several boundary conditions:

1# Equator / Prime Meridian intersection
2adb emu geo fix 0.0 0.0
3
4# International Date Line
5adb emu geo fix 180.0 0.0
6adb emu geo fix -180.0 0.0
7
8# North Pole
9adb emu geo fix 0.0 90.0
10
11# South Pole
12adb emu geo fix 0.0 -90.0
13
14# High altitude (include altitude as third parameter, in meters)
15adb emu geo fix -105.9378 39.7392 4300

Test that your app handles rapid location changes gracefully:

1# Simulate teleportation (location jump)
2adb emu geo fix -122.4194 37.7749  # San Francisco
3sleep 1
4adb emu geo fix 2.3522 48.8566     # Paris

Your app should detect the impossible speed and either filter the jump or handle it as a new session.

Permissions and Runtime Checks

Before testing location features, ensure the emulator AVD has Google Play Services (or Google APIs) in its system image. Location testing also requires that the app has declared and been granted location permissions:

<!-- AndroidManifest.xml -->
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />

1// Request permissions at runtime (Android 6.0+)
2if (ContextCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION)
3    != PackageManager.PERMISSION_GRANTED) {
4    ActivityCompat.requestPermissions(
5        this,
6        arrayOf(Manifest.permission.ACCESS_FINE_LOCATION),
7        LOCATION_PERMISSION_REQUEST
8    )
9}

Common Pitfalls

• Reversing latitude and longitude in geo fix. The command takes longitude first, unlike most APIs that expect latitude first.
• Forgetting the emulator console auth token. Since Android Studio 2.0, the console requires authentication. Read the token from ~/.emulator_console_auth_token.
• Testing on an AVD without Google APIs. The FusedLocationProviderClient requires Google Play Services, which is not included in plain AOSP system images.
• Not granting location permissions before sending mock coordinates. The emulator will accept the location, but the app will not receive updates if it lacks permissions.
• Expecting geo fix to produce continuous movement. Each geo fix call sets a single point. For continuous movement, send a sequence of points or use a GPX file.
• Using the emulator's built-in location on a physical device. The Extended Controls UI and geo fix only work with emulators. For physical devices, use setMockLocation() with developer options enabled.

Summary

• Use the Extended Controls UI for quick manual testing with a visual map and GPX/KML route playback.
• Use adb emu geo fix <longitude> <latitude> for scripted and CI-driven location testing. Remember that longitude comes first.
• Use setMockLocation() in instrumented tests for deterministic, in-process location mocking.
• Test boundary conditions (poles, date line, altitude, teleportation) to catch edge cases in location handling.
• Always verify that the AVD has Google APIs and that the app has been granted location permissions.