Standort-Grundlagen in Android: GPS, ungenaue Ortung und Fused Provider

Ortung gehört zu den mächtigsten – und gleichzeitig heikelsten – Fähigkeiten eines Android-Geräts. Ob du eine Navigations-App, einen Fitness-Tracker oder standortbasierte Benachrichtigungen baust: Bevor du auch nur eine Zeile Code schreibst, solltest du verstehen, welche Ortungs-APIs Android bereitstellt, was sie voneinander unterscheidet und welche Auswirkungen sie auf Akku, Datenschutz und Nutzervertrauen haben.

Was ist das?

Android stellt dir drei grundlegende Quellen für Standortdaten zur Verfügung: GPS (Global Positioning System), Netzwerkortung über WLAN-Netzwerke und Mobilfunkmasten sowie passive Ortung, bei der deine App Standortdaten mitnutzt, die andere Prozesse bereits angefordert haben. Seit Android 4.2 bündelt Google diese Quellen im Fused Location Provider (FLP) aus den Google Play Services. Statt selbst zwischen GPS und Netzwerk zu wechseln, gibst du dem FLP deine gewünschte Genauigkeit und Akku-Priorität an – er wählt die passende Quelle eigenständig aus.

Seit Android 12 (API 31) unterscheidet das System außerdem explizit zwischen ungefährer Ortung (ACCESS_COARSE_LOCATION) und genauer Ortung (ACCESS_FINE_LOCATION). Die ungefähre Variante liefert einen Radius von etwa 3 km – ausreichend für Wetter-Apps oder regionale Inhalte. Die genaue Ortung nutzt GPS und liefert metergenaue Daten, kostet aber deutlich mehr Energie. Diese Unterscheidung ist nicht nur technisch relevant: Nutzer können dir ab Android 12 gezielt nur die grobe Variante erlauben, selbst wenn du beide Berechtigungen anforderst. Deine App muss darauf vorbereitet sein.

Wie funktioniert es?

Der zentrale Einstiegspunkt ist FusedLocationProviderClient aus dem Paket com.google.android.gms.location. Du erhältst eine Instanz über LocationServices.getFusedLocationProviderClient(context).

Für eine einmalige Abfrage nutzt du getLastLocation() – ein schneller, akkuschonender Aufruf, der den zuletzt gecachten Standort zurückgibt. Benötigst du regelmäßige Updates, rufst du requestLocationUpdates() mit einem LocationRequest-Objekt auf. Darin steuerst du drei wesentliche Parameter:

• priority – z. B. Priority.PRIORITY_BALANCED_POWER_ACCURACY für Netzwerkortung oder Priority.PRIORITY_HIGH_ACCURACY für GPS
• intervalMillis – bevorzugtes Update-Intervall in Millisekunden
• minUpdateDistanceMeters – minimaler Standortwechsel in Metern, bevor ein Update geliefert wird

Das Berechtigungsmodell läuft zweigleisig: ACCESS_COARSE_LOCATION oder ACCESS_FINE_LOCATION müssen zur Laufzeit über ActivityResultContracts.RequestMultiplePermissions angefordert werden. Fehlt die Berechtigung zum Aufrufzeitpunkt, wirft getLastLocation() eine SecurityException. Ab Android 10 (API 29) kommt ACCESS_BACKGROUND_LOCATION für Hintergrundortung hinzu – die Zustimmungsrate ist hier besonders niedrig, da der Play Store eine zusätzliche Prüfung verlangt. Fordere Hintergrundortung deshalb nur an, wenn sie für dein Kernfeature wirklich unverzichtbar ist.

In der Praxis

Das folgende Beispiel zeigt eine typische Einmalanfrage in einem Compose-basierten ViewModel. Die Berechtigung wird außerhalb des ViewModels über einen ActivityResultLauncher verwaltet; das ViewModel reagiert erst auf den Aufruf von fetchLastKnownLocation(), nachdem die Berechtigung erteilt wurde.

class LocationViewModel(application: Application) : AndroidViewModel(application) {

    private val fusedClient =
        LocationServices.getFusedLocationProviderClient(application)

    private val _location = MutableStateFlow<Location?>(null)
    val location: StateFlow<Location?> = _location.asStateFlow()

    @SuppressLint("MissingPermission")
    fun fetchLastKnownLocation() {
        fusedClient.lastLocation
            .addOnSuccessListener { location ->
                // location kann null sein – explizit behandeln!
                _location.value = location
            }
            .addOnFailureListener {
                _location.value = null
            }
    }
}

Typische Stolperfallen

getLastLocation() gibt null zurück. Das passiert, wenn das Gerät seit dem letzten Neustart noch keinen Standort ermittelt hat – zum Beispiel auf einem frisch gestarteten Emulator oder nach dem Deaktivieren der Standortdienste. Fange diesen Fall explizit ab. Ist null das Ergebnis, starte einen kurzen requestLocationUpdates()-Aufruf, um einen frischen Wert zu erzwingen, und stoppe danach sofort wieder.

Zu weitreichende Berechtigung anfragen. ACCESS_FINE_LOCATION anzufordern, obwohl deine App nur einen Stadtteil benötigt, kostet unnötig Akku, löst auf neueren Geräten eine ausführlichere Datenschutzmeldung aus und senkt die Zustimmungsrate spürbar. Starte immer mit der schwächsten Berechtigung, die für deinen Use Case ausreicht, und skaliere nur bei echtem Bedarf hoch.

Callback nicht abmelden. Wenn du requestLocationUpdates() verwendest, musst du den LocationCallback in onStop() oder beim Beenden des viewModelScope wieder über removeLocationUpdates() abmelden. Vergisst du das, läuft die Ortung im Hintergrund weiter und leert den Akku – ein häufig übersehener Fehler, der erst im Feld auffällt. Das LocationRequest.Builder-Muster aus Play Services 21+ macht die Konfiguration ausdrucksstärker als der veraltete LocationRequest.create()-Ansatz und sollte in neuem Code bevorzugt werden.

Fazit

Standortabfragen in Android sind mehr als ein API-Aufruf – sie sind ein Versprechen gegenüber dem Nutzer. Mit jeder Anfrage entscheidest du, wie viel Akku du verbrauchst, wie viele Daten du sammelst und wie viel Vertrauen du in Anspruch nimmst. Öffne nach diesem Artikel deine App im Code-Review und stelle dir drei Fragen: Ist FINE_LOCATION wirklich nötig, oder reicht COARSE? Werden alle Callbacks im richtigen Lifecycle-Moment abgemeldet? Zeigt das UI einen sinnvollen Fallback, wenn lastLocation null ist? Wer diese drei Punkte sauber beantwortet, hat die Grundlagen der Android-Ortung nicht nur gelesen, sondern wirklich verstanden.