Hintergrund-Standort: Richtlinien, Privatsphäre und Nutzervertrauen

Hintergrund-Standort gehört zu den mächtigsten Werkzeugen, die dir Android bietet – und gleichzeitig zu den gefährlichsten, wenn du ihn leichtfertig einsetzt. Wer ACCESS_BACKGROUND_LOCATION ohne triftigen Grund anfordert, riskiert nicht nur eine Ablehnung durch Google Play, sondern beschädigt auch das Vertrauen seiner Nutzerinnen und Nutzer dauerhaft. Das Thema lässt sich deshalb nicht auf technische Details reduzieren: Es ist genauso eine Frage der Haltung und des Designprozesses. Auf deiner Roadmap von Beginner zu Senior ist der Umgang mit dieser Berechtigung ein Reifezeichen – nicht weil die API komplex ist, sondern weil sie dich zwingt, Policy und Datenschutz als gleichrangige Anforderungen neben dem Funktionieren der App zu behandeln.

Was ist das?

Hintergrund-Standort beschreibt die Fähigkeit einer App, den geografischen Standort des Geräts abzufragen, auch wenn die App nicht im Vordergrund aktiv ist – also weder auf dem Bildschirm zu sehen ist noch als Foreground Service mit sichtbarer Benachrichtigung läuft.

Bis Android 9 reichte eine einzige Berechtigung (ACCESS_FINE_LOCATION oder ACCESS_COARSE_LOCATION) für Standortzugriff in allen Situationen. Ab Android 10 (API Level 29) hat Google diese Stufen getrennt: Vordergrund- und Hintergrund-Zugriff sind seither zwei unabhängige Berechtigungen. Eine App muss erst ACCESS_FINE_LOCATION oder ACCESS_COARSE_LOCATION erhalten, bevor sie überhaupt ACCESS_BACKGROUND_LOCATION beantragen darf – ein sequenzieller Prozess ohne Abkürzung.

Im Permission-Modell erscheint für den Hintergrund-Zugriff kein einfacher Zustimmungs-Dialog mehr. Stattdessen leitet Android den Nutzer in die Systemeinstellungen weiter, wo er explizit „Immer zulassen” auswählen muss. Das ist bewusst reibungsreich gestaltet. Die Hürde soll sicherstellen, dass nur Apps diese Stufe erreichen, bei denen kontinuierlicher Standortzugriff wirklich notwendig ist – Fitness-Tracking, Flottenmanagement, Familien-Ortung oder Geofencing.

Wie funktioniert es?

Zweistufige Berechtigungs-Anfrage

Das System erzwingt einen strikten Zweischritt-Prozess. Du kannst beide Berechtigungen nicht gleichzeitig anfordern:

1. Vordergrund-Berechtigung anfordern: Bitte zuerst um ACCESS_FINE_LOCATION (oder ACCESS_COARSE_LOCATION) und warte auf die Zustimmung.
2. Hintergrund-Berechtigung anfordern: Erst nach Zustimmung, mit ausreichend Kontext, forderst du ACCESS_BACKGROUND_LOCATION an.

Im Manifest deklarierst du beide Berechtigungen:

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />

Im Kotlin-Code löst du die Anfragen nacheinander aus:

// Schritt 1: Vordergrund-Standort anfragen
ActivityCompat.requestPermissions(
    this,
    arrayOf(Manifest.permission.ACCESS_FINE_LOCATION),
    REQUEST_FOREGROUND_LOCATION
)

// Schritt 2: Erst nach Zustimmung den Hintergrund-Zugriff anfragen
ActivityCompat.requestPermissions(
    this,
    arrayOf(Manifest.permission.ACCESS_BACKGROUND_LOCATION),
    REQUEST_BACKGROUND_LOCATION
)

Foreground Service als häufigere Alternative

Viele Anwendungsfälle, die sich auf den ersten Blick nach Hintergrund-Standort anfühlen, lassen sich mit einem Foreground Service vom Typ location lösen. Der entscheidende Unterschied: Ein Foreground Service zeigt eine persistente Benachrichtigung und benötigt nur ACCESS_FINE_LOCATION, nicht ACCESS_BACKGROUND_LOCATION. Das ist aus Datenschutz- und Play-Policy-Sicht deutlich einfacher zu begründen und führt in der Praxis seltener zu Ablehnungen.

<service
    android:name=".LocationTrackingService"
    android:foregroundServiceType="location" />

Google Play Policy und Declarations

Google verlangt für Apps, die ACCESS_BACKGROUND_LOCATION nutzen, eine Permissions Declaration Form im Play Console und prüft den angegebenen Anwendungsfall manuell. Apps ohne überzeugenden Use-Case werden abgelehnt oder im laufenden Betrieb aus dem Store entfernt. Zulässige Kategorien umfassen Navigation, Flottenmanagement, Sicherheits-Apps und ähnliche Szenarien mit klarer Begründung für den Dauerzugriff.

In der Praxis

Konkretes Beispiel: Geofencing-Alarm

Ein typischer, legitimer Fall ist eine App, die den Nutzer benachrichtigt, sobald er einen bestimmten Bereich betritt oder verlässt – etwa eine Einkaufslisten-App, die an Läden in der Nähe erinnert. Hier ist ACCESS_BACKGROUND_LOCATION zusammen mit der Geofencing-API aus Jetpack tatsächlich notwendig:

val geofence = Geofence.Builder()
    .setRequestId("supermarkt_mitte")
    .setCircularRegion(48.1374, 11.5754, 200f)
    .setExpirationDuration(Geofence.NEVER_EXPIRE)
    .setTransitionTypes(Geofence.GEOFENCE_TRANSITION_ENTER)
    .build()

val request = GeofencingRequest.Builder()
    .setInitialTrigger(GeofencingRequest.INITIAL_TRIGGER_ENTER)
    .addGeofence(geofence)
    .build()

Für diesen Use-Case musst du dem Nutzer vor der Berechtigungs-Anfrage klar kommunizieren, warum der Hintergrund-Zugriff nötig ist. Ein Permission-Rationale-Dialog ist nicht optional – er ist entscheidend dafür, dass der Nutzer die Berechtigung versteht und ihr zustimmt.

Typische Stolperfalle: zu früh anfragen

Der häufigste Fehler ist, ACCESS_BACKGROUND_LOCATION direkt beim App-Start anzufordern, bevor der Nutzer überhaupt den entsprechenden Feature-Bereich betreten hat. Das Ergebnis: Der Nutzer lehnt ab, weil er den Kontext nicht versteht, und du erhältst die Berechtigung nie mehr. Noch schlimmer – viele Nutzer deinstallieren die App sofort, wenn sie eine unerwartete Standort-Anfrage sehen.

Faustregel: Frage die Berechtigung erst an, wenn der Nutzer aktiv einen Workflow startet, der Hintergrund-Standort explizit erfordert. Erkläre in eigenen Worten – nicht in technischem Jargon –, welchen konkreten Vorteil der Nutzer davon hat. Vermeide Formulierungen wie „wird für die App benötigt” und nutze stattdessen „damit wir dich benachrichtigen können, sobald du in der Nähe eines gespeicherten Ortes bist”.

Zusätzlich solltest du sicherstellen, dass deine App sauber degradiert, wenn die Berechtigung verweigert wird. Zeige dem Nutzer eine verständliche Erklärung und biete eine Möglichkeit an, die Funktion manuell auszulösen – das ist sowohl aus UX- als auch aus Play-Policy-Sicht erwartet.

Fazit

Hintergrund-Standort ist kein Feature, das du beiläufig aktivierst. Es ist eine Verantwortung gegenüber dem Nutzer und eine ernsthafte Hürde im Play-Store-Review-Prozess. Nimm dir in deiner nächsten Code-Review-Runde bewusst Zeit, um zu hinterfragen, ob deine App ACCESS_BACKGROUND_LOCATION wirklich braucht oder ob ein Foreground Service dieselbe Nutzererfahrung liefern kann. Schreibe außerdem einen instrumentierten Test, der prüft, dass deine App beim Fehlen der Berechtigung sauber degradiert und dem Nutzer eine hilfreiche Erklärung anzeigt – denn in einer datenschutzbewussten Welt ist das genau der Fall, mit dem du am häufigsten konfrontiert wirst.