onStop — ocultação de Activity no ciclo de vida do Android

O que é onStop no Android?

onStop — um método callback da classe AppCompatActivity (e sua antecessora Activity), chamado pelo sistema operacional Android quando a Activity deixa de estar completamente visível para o usuário. Neste momento, a Activity está oculta por outra Activity, uma janela de diálogo, o lançador do sistema ou a tela de bloqueio. Da perspectiva do ciclo de vida, onStop segue onPause e sinaliza que a Activity não está mais visível na tela, embora o objeto Activity e seu estado permaneçam na memória.

Quando a Activity transita para o estado Stopped (parada), ela mantém seu estado na RAM — todos os campos, a hierarquia de View e a ViewModel permanecem acessíveis. Isso diferencia Stopped do estado Destroyed (destruído), onde a Activity é completamente removida. A interface do sistema pode eliminar o processo do aplicativo no estado Stopped quando há falta de memória — isso é a chamada morte do processo. O desenvolvedor deve salvar dados críticos (rascunhos, posição de scroll) em onSaveInstanceState(), que é chamado antes de onStop, para garantir a restauração em caso de morte do processo.

De acordo com o Documento de Definição de Compatibilidade do Android (CDD) para a versão 14+, um processo no estado Stopped tem prioridade reduzida para ser eliminado pelo OOM Killer — menor que processos em fase Background, mas maior que processos em cache. Segundo estatísticas do Google, 68% dos casos de morte de processo ocorrem quando a Activity está no estado Stopped, não Paused.

Quando onStop é chamado: cenários e ordem

onStop é chamado quando a Activity perde completamente a visibilidade, independentemente do motivo: iniciar uma nova Activity sobre a atual, minimizar o aplicativo (pressionar Home), bloquear a tela, uma chamada recebida ou abrir um diálogo do sistema. Em todos esses casos, a Activity primeiro recebe onPause (perda parcial de foco) e depois onStop (perda total de visibilidade).

Cenários principais de chamada do onStop:

• Iniciar uma nova Activity sobre a atual — a Activity atual recebe onPause, depois onStop; a nova Activity passa por onCreate → onStart → onResume.
• Minimizar o aplicativo (Home) — a Activity transita para onPause → onStop em 200–300 ms, permanece na memória no estado Stopped.
• Bloquear a tela — o sistema chama onPause → onStop porque a tela de bloqueio cobre completamente a Activity.
• Chamada recebida — o aplicativo de telefone (Dialer) inicia sobre a atual, a Activity atual transita para onStop.
• Alternar para outro aplicativo (Recentes) — a Activity é ocultada, recebe onStop, mas permanece no cache de processos.

É importante entender que onStop não é chamado ao rotacionar a tela — neste caso, a Activity é destruída (onPause → onStop → onDestroy) e recriada (onCreate → onStart → onResume). A exceção é a flag android:configChanges="orientation" no manifesto, que impede a recriação da Activity e em vez disso chama onConfigurationChanged().

onStop no ciclo de vida da Activity

onStop ocupa um lugar central na sequência do ciclo de vida da Activity entre o estado visível e invisível. A sequência completa: onCreate → onStart → onResume → (estado ativo) → onPause → onStop → onDestroy (ou onRestart → onStart → onResume ao retornar).

*No estado Stopped, a Activity é mantida na memória, mas pode ser eliminada pelo sistema quando faltam recursos. A prioridade de eliminação de processos Stopped é a penúltima, acima apenas de processos vazios em cache.

onStop e onSaveInstanceState: O sistema chama onSaveInstanceState(Bundle) antes de onStop para salvar o estado dinâmico da interface. O desenvolvedor sobrescreve este método para salvar no Bundle os valores dos campos de entrada, a posição do RecyclerView e os itens selecionados. Mesmo se a Activity não for destruída (o usuário simplesmente minimizou e retornou), o Bundle é passado para onCreate em mudanças de configuração. O Google recomenda salvar apenas o estado transitório da interface — não os dados do repositório ou ViewModel, que vivem fora da Activity.

Quais recursos liberar em onStop

Em onStop, o desenvolvedor deve liberar todos os recursos que não são necessários quando a Activity não está visível. Isso reduz a carga da bateria, CPU e memória, e também previne ANRs ao retornar à atividade.

O que liberar em onStop:

• Animações e transições — parar ObjectAnimator, ValueAnimator, ViewPropertyAnimator. Animações em execução em uma Activity invisível desperdiçam ciclos de GPU.
• Sensores — cancelar a assinatura do SensorManager (acelerômetro, giroscópio, magnetômetro). Sensores consomem energia mesmo quando a Activity está oculta.
• Câmera e microfone — liberar Camera2 ou CameraX, parar MediaRecorder. Deixar a câmera ativa com a Activity oculta é proibido pela política do Google Play.
• LocationListener — cancelar a assinatura do FusedLocationProviderClient ou LocationManager. A geolocalização é o recurso que mais consome energia.
• Listeners de rede — fechar WebSocket, cancelar requisições HTTP que não são necessárias em segundo plano.
• MediaPlayer e ExoPlayer — pausar ou parar a reprodução se não deve continuar em segundo plano.

O que não fazer em onStop: Não execute operações longas — salvar grandes quantidades de dados no banco de dados, requisições de rede, cálculos complexos. onStop é executado na thread principal e bloqueia o retorno à Activity. Para operações longas, use WorkManager com atraso ou corrotinas em viewModelScope. Não libere recursos da ViewModel — a ViewModel sobrevive ao onStop e será usada ao retornar.

Diferença entre onStop e onPause

onPause e onStop diferem no grau de perda de visibilidade e no escopo das ações obrigatórias. onPause é chamado na perda parcial de foco (por exemplo, abrir uma janela de diálogo ou menu do sistema), onStop — na perda completa de visibilidade. Essa diferença é importante para escolher quais recursos liberar em cada etapa.

Regra geral: em onPause, libere os recursos do sistema que imediatamente afetam a experiência do usuário de outro aplicativo (câmera, player de mídia); em onStop — todos os outros recursos não necessários quando a Activity está oculta. O Google recomenda salvar dados críticos do usuário (rascunho de e-mail, configurações) em onPause, pois onStop pode não ser chamado durante uma alternância rápida.

onStop → onRestart: retorno à tela

Quando o usuário retorna a uma Activity oculta, o sistema chama onRestart → onStart → onResume. O método onRestart sinaliza que a Activity está retornando do estado Stopped. Esta é uma etapa importante para restaurar a interface e os recursos que foram liberados em onStop.

Sequência de chamadas ao retornar:

• onRestart() — a Activity é notificada de que será mostrada novamente. Ações típicas: recarregar dados, atualizar listas.
• onStart() — a Activity se torna visível mas ainda não ativa. Aqui os recursos liberados em onStop são reinicializados.
• onResume() — a Activity ganha foco e está pronta para interação. Animações são iniciadas, sensores são registrados.

Se o processo do aplicativo foi eliminado pelo sistema no estado Stopped, onCreate é chamado em vez de onRestart, e o Bundle do onSaveInstanceState é passado para restauração do estado. Este cenário (morte do processo) é uma das causas mais comuns de bugs em aplicativos Android: desenvolvedores implementam onRestart mas esquecem de considerar a restauração através de onCreate após a morte do processo.

Exemplos de código com onStop em Kotlin

Exemplo 1: Implementação básica de onStop com liberação de sensores

Demonstra o cancelamento correto de assinatura de sensores e a parada de animações ao ocultar a Activity. Ao retornar à tela, os recursos são restaurados em onStart.

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 retorna do estado Stopped")
    }

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

O código registra o sensor de acelerômetro e inicia uma animação de rotação infinita em onStart. Em onStop, o sensor é desregistrado e a animação é cancelada — isso evita o consumo de bateria quando a Activity está oculta. Após retornar via onRestart → onStart, os recursos são recriados.

Exemplo 2: onStop com preservação de estado via SavedStateHandle

Uma abordagem moderna usando ViewModel + SavedStateHandle. Os dados do formulário são salvos automaticamente durante onStop sem manipulação manual de Bundle.

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: dados salvos no SavedStateHandle")
    }
}

SavedStateHandle salva automaticamente os valores no Bundle durante onSaveInstanceState, que é chamado antes de onStop. Ao rotacionar a tela ou na morte do processo, os dados são restaurados sem perda. O Google recomenda SavedStateHandle para formulários e rascunhos em vez de onSaveInstanceState direto.

Exemplo 3: lifecycleScope para operações em onStop

Uso de lifecycleScope com corrotinas para salvar dados de forma assíncrona durante a transição para onStop. A corrotina é executada no dispatcher IO sem bloquear a thread principal.

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", "Rascunho salvo em onStop")
            }
        }
        super.onStop()
    }
}

A corrotina lifecycleScope.launch é cancelada automaticamente se o ciclo de vida da Activity termina. O uso de Dispatchers.IO garante que a escrita no banco de dados ou arquivo não bloqueie o retorno à Activity. Segundo o Google, corrotinas em lifecycleScope são a forma preferida de realizar operações assíncronas em onStop.