onStop — Ausblenden der Activity im Android-Lebenszyklus

Was ist onStop in Android?

onStop — eine Callback-Methode der Klasse AppCompatActivity (und ihres Vorgängers Activity), die vom Android-Betriebssystem aufgerufen wird, wenn die Activity für den Benutzer nicht mehr vollständig sichtbar ist. Zu diesem Zeitpunkt wird die Activity von einer anderen Activity, einem Dialogfenster, dem System-Launcher oder dem Sperrbildschirm verdeckt. Aus Lebenszyklus-Perspektive folgt onStop auf onPause und signalisiert, dass die Activity nicht mehr auf dem Bildschirm sichtbar ist, obwohl das Activity-Objekt und sein Zustand im Speicher verbleiben.

Wenn die Activity in den Stopped-Zustand übergeht, behält sie ihren Zustand im RAM — alle Felder, die View-Hierarchie und ViewModel bleiben zugänglich. Dies unterscheidet Stopped vom Destroyed-Zustand, in dem die Activity vollständig entfernt wird. Die System-UI kann den App-Prozess im Stopped-Zustand bei Speichermangel beenden — dies wird als Prozessabbruch bezeichnet. Der Entwickler muss kritische Daten (Entwürfe, Scrollposition) in onSaveInstanceState() speichern, das vor onStop aufgerufen wird, um die Wiederherstellung bei Prozessabbruch zu gewährleisten.

Gemäß dem Android Compatibility Definition Document (CDD) für Version 14+ hat ein Prozess im Stopped-Zustand eine reduzierte Priorität für die Beendigung durch den OOM-Killer — niedriger als Prozesse in der Background-Phase, aber höher als zwischengespeicherte Prozesse. Laut Google-Statistik treten 68 % der Prozessabbrüche auf, wenn sich die Activity im Stopped-Zustand befindet, nicht im Paused-Zustand.

Wann wird onStop aufgerufen: Szenarien und Reihenfolge

onStop wird bei vollständigem Sichtbarkeitsverlust der Activity aufgerufen, unabhängig vom Grund: Starten einer neuen Activity über der aktuellen, Minimieren der App (Home-Taste), Sperren des Bildschirms, eingehender Anruf oder Öffnen eines Systemdialogs. In all diesen Fällen erhält die Activity zunächst onPause (teilweiser Fokusverlust) und dann onStop (vollständiger Sichtbarkeitsverlust).

Hauptszenarien für den onStop-Aufruf:

• Starten einer neuen Activity über der aktuellen — die aktuelle Activity erhält onPause, dann onStop; die neue Activity durchläuft onCreate → onStart → onResume.
• Minimieren der App (Home) — die Activity wechselt innerhalb von 200–300 ms zu onPause → onStop, verbleibt im Speicher im Stopped-Zustand.
• Sperren des Bildschirms — das System ruft onPause → onStop auf, da der Sperrbildschirm die Activity vollständig überdeckt.
• Eingehender Anruf — die Telefon-App (Dialer) wird darüber gestartet, die aktuelle Activity wechselt zu onStop.
• Wechsel zu einer anderen App (Letzte Apps) — die Activity wird ausgeblendet, erhält onStop, bleibt aber im Prozess-Cache.

Es ist wichtig zu verstehen, dass onStop bei Bildschirmdrehung nicht aufgerufen wird — in diesem Fall wird die Activity zerstört (onPause → onStop → onDestroy) und neu erstellt (onCreate → onStart → onResume). Die Ausnahme ist das Flag android:configChanges="orientation" im Manifest, das die Neuerstellung der Activity verhindert und stattdessen onConfigurationChanged() aufruft.

onStop im Activity-Lebenszyklus

onStop nimmt eine zentrale Stelle in der Activity-Lebenszyklus-Sequenz zwischen sichtbarem und unsichtbarem Zustand ein. Die vollständige Sequenz: onCreate → onStart → onResume → (aktiver Zustand) → onPause → onStop → onDestroy (oder onRestart → onStart → onResume bei Rückkehr).

*Im Stopped-Zustand wird die Activity im Speicher gehalten, kann aber bei Ressourcenmangel vom System beendet werden. Die Priorität der Beendigung von Stopped-Prozessen ist die vorletzte, nur über zwischengespeicherten leeren Prozessen.

onStop und onSaveInstanceState: Das System ruft onSaveInstanceState(Bundle) vor onStop auf, um den dynamischen UI-Zustand zu speichern. Der Entwickler überschreibt diese Methode, um Eingabefeldwerte, RecyclerView-Position und ausgewählte Elemente im Bundle zu speichern. Selbst wenn die Activity nicht zerstört wird (der Benutzer hat sie nur minimiert und kehrte zurück), wird das Bundle bei Konfigurationsänderungen an onCreate übergeben. Google empfiehlt, nur den transienten UI-Zustand zu speichern — nicht Repository-Daten oder ViewModel, die außerhalb der Activity leben.

Welche Ressourcen in onStop freigeben

In onStop muss der Entwickler alle Ressourcen freigeben, die nicht benötigt werden, wenn die Activity nicht sichtbar ist. Dies reduziert die Belastung von Akku, CPU und Speicher und verhindert zudem ANRs bei der Rückkehr zur Aktivität.

Was in onStop freizugeben ist:

• Animationen und Übergänge — ObjectAnimator, ValueAnimator, ViewPropertyAnimator stoppen. Laufende Animationen bei unsichtbarer Activity verschwenden GPU-Zyklen.
• Sensoren — Abmeldung vom SensorManager (Beschleunigungssensor, Gyroskop, Magnetometer). Sensoren verbrauchen auch bei ausgeblendeter Activity Energie.
• Kamera und Mikrofon — Camera2 oder CameraX freigeben, MediaRecorder stoppen. Die Kamera bei ausgeblendeter Activity aktiv zu lassen, ist durch die Google Play-Richtlinie verboten.
• LocationListener — Abmeldung von FusedLocationProviderClient oder LocationManager. Geolokalisierung ist die energieintensivste Ressource.
• Netzwerk-Listener — WebSocket schließen, HTTP-Anfragen abbrechen, die im Hintergrund nicht benötigt werden.
• MediaPlayer und ExoPlayer — Wiedergabe pausieren oder stoppen, wenn sie im Hintergrund nicht fortgesetzt werden soll.

Was in onStop nicht zu tun ist: Führen Sie keine langwierigen Operationen durch — große Datenmengen in der Datenbank speichern, Netzwerkanfragen, komplexe Berechnungen. onStop wird im Hauptthread ausgeführt und blockiert die Rückkehr zur Activity. Für langwierige Operationen verwenden Sie WorkManager mit Verzögerung oder Coroutinen in viewModelScope. Geben Sie keine ViewModel-Ressourcen frei — ViewModel überlebt onStop und wird bei der Rückkehr verwendet.

Unterschied zwischen onStop und onPause

onPause und onStop unterscheiden sich im Grad des Sichtbarkeitsverlusts und im Umfang der erforderlichen Maßnahmen. onPause wird bei teilweisem Fokusverlust aufgerufen (z. B. Öffnen eines Dialogfensters oder Systemmenüs), onStop — bei vollständigem Sichtbarkeitsverlust. Dieser Unterschied ist wichtig für die Wahl, welche Ressourcen in jeder Phase freigegeben werden.

Allgemeine Regel: Geben Sie in onPause Systemressourcen frei, die sofort die Benutzererfahrung einer anderen App beeinflussen (Kamera, Mediaplayer); in onStop — alle anderen Ressourcen, die bei ausgeblendeter Activity nicht benötigt werden. Google empfiehlt, kritische Benutzerdaten (E-Mail-Entwurf, Einstellungen) in onPause zu speichern, da onStop bei schnellem Wechsel möglicherweise nicht aufgerufen wird.

onStop → onRestart: Rückkehr zum Bildschirm

Wenn der Benutzer zu einer ausgeblendeten Activity zurückkehrt, ruft das System onRestart → onStart → onResume auf. Die Methode onRestart signalisiert, dass die Activity aus dem Stopped-Zustand zurückkehrt. Dies ist eine wichtige Phase zur Wiederherstellung der Benutzeroberfläche und der in onStop freigegebenen Ressourcen.

Aufrufsequenz bei der Rückkehr:

• onRestart() — die Activity wird benachrichtigt, dass sie erneut angezeigt wird. Typische Aktionen: Daten neu laden, Listen aktualisieren.
• onStart() — die Activity wird sichtbar, ist aber noch nicht aktiv. Hier werden die in onStop freigegebenen Ressourcen neu initialisiert.
• onResume() — die Activity erhält den Fokus und ist zur Interaktion bereit. Animationen werden gestartet, Sensoren werden registriert.

Wenn der App-Prozess vom System im Stopped-Zustand beendet wurde, wird onCreate anstelle von onRestart aufgerufen und das Bundle von onSaveInstanceState zur Zustandswiederherstellung übergeben. Dieses Szenario (Prozessabbruch) ist eine der häufigsten Ursachen für Fehler in Android-Apps: Entwickler implementieren onRestart, vergessen aber die Wiederherstellung über onCreate nach einem Prozessabbruch zu berücksichtigen.

Codebeispiele mit onStop in Kotlin

Beispiel 1: Grundlegende onStop-Implementierung mit Sensorfreigabe

Zeigt die korrekte Sensor-Abmeldung und das Stoppen von Animationen beim Ausblenden der Activity. Bei Rückkehr zum Bildschirm werden die Ressourcen in onStart wiederhergestellt.

class MainActivity : AppCompatActivity() {
    private lateinit var sensorManager: SensorManager
    private var accelerometer: Sensor? = null
    private var rotationAnimator: ObjectAnimator? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        sensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager
        accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)
    }

    override fun onStart() {
        super.onStart()
        accelerometer?.let {
            sensorManager.registerListener(sensorListener, it, SensorManager.SENSOR_DELAY_NORMAL)
        }
        rotationAnimator = ObjectAnimator.ofFloat(findViewById(R.id.icon), "rotation", 0f, 360f)
        rotationAnimator?.apply {
            duration = 3000
            repeatMode = ValueAnimator.RESTART
            repeatCount = ValueAnimator.INFINITE
            start()
        }
    }

    override fun onStop() {
        super.onStop()
        sensorManager.unregisterListener(sensorListener)
        rotationAnimator?.cancel()
    }

    override fun onRestart() {
        super.onRestart()
        Log.d("MainActivity", "Activity kehrt aus dem Stopped-Zustand zurück")
    }

    private val sensorListener = SensorEventListener { event, _ ->
        Log.d("MainActivity", "Beschl: x=${event.values[0]}, y=${event.values[1]}, z=${event.values[2]}")
    }
}

Der Code registriert den Beschleunigungssensor und startet eine unendliche Rotationsanimation in onStart. In onStop wird der Sensor abgemeldet und die Animation abgebrochen — dies verhindert Batterieverbrauch bei ausgeblendeter Activity. Nach der Rückkehr über onRestart → onStart werden die Ressourcen neu erstellt.

Beispiel 2: onStop mit Zustandserhaltung über SavedStateHandle

Ein moderner Ansatz mit ViewModel + SavedStateHandle. Formulardaten werden während onStop automatisch gespeichert, ohne manuelle Bundle-Behandlung.

class FormViewModel(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {
    var email: String
        get() = savedStateHandle["email"] ?: ""
        set(value) { savedStateHandle["email"] = value }

    var message: String
        get() = savedStateHandle["message"] ?: ""
        set(value) { savedStateHandle["message"] = value }
}

class FormActivity : AppCompatActivity() {
    private val viewModel: FormViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_form)
        Log.d("FormActivity", "onCreate: email=${viewModel.email}")
    }

    override fun onStop() {
        super.onStop()
        Log.d("FormActivity", "onStop: Daten in SavedStateHandle gespeichert")
    }
}

SavedStateHandle speichert automatisch Werte im Bundle während onSaveInstanceState, das vor onStop aufgerufen wird. Bei Bildschirmdrehung oder Prozessabbruch werden Daten ohne Verlust wiederhergestellt. Google empfiehlt SavedStateHandle für Formulare und Entwürfe anstelle von direktem onSaveInstanceState.

Beispiel 3: lifecycleScope für Operationen in onStop

Verwendung von lifecycleScope mit Coroutinen zum asynchronen Speichern von Daten beim Übergang zu onStop. Die Coroutine wird im IO-Dispatcher ausgeführt, ohne den Hauptthread zu blockieren.

class NoteActivity : AppCompatActivity() {
    private val noteRepository = NoteRepository()

    override fun onStop() {
        lifecycleScope.launch(Dispatchers.IO) {
            val text = findViewById<EditText>(R.id.note_content).text.toString()
            noteRepository.saveDraft(text)
            withContext(Dispatchers.Main) {
                Log.d("NoteActivity", "Entwurf in onStop gespeichert")
            }
        }
        super.onStop()
    }
}

Die lifecycleScope.launch-Coroutine wird automatisch abgebrochen, wenn der Activity-Lebenszyklus endet. Die Verwendung von Dispatchers.IO stellt sicher, dass Datenbank- oder Dateischreibvorgänge die Rückkehr zur Activity nicht blockieren. Laut Google sind Coroutinen in lifecycleScope die bevorzugte Methode zur Durchführung asynchroner Operationen in onStop.