Multicurrículum

En Android 9 (y versiones anteriores), las aplicaciones entraban en estado PAUSED cuando:

• Se inició una nueva actividad translúcida en la parte superior de la aplicación, mientras la aplicación aún estaba visible (y, por lo tanto, no se detuvo).
• La actividad perdió el foco, pero no quedó oculta y el usuario pudo interactuar con ella. Por ejemplo, en el modo de ventanas múltiples, varias actividades pueden ser visibles y recibir entrada táctil simultáneamente.

Estas situaciones difieren en la cantidad de pausa que debe hacer una aplicación, pero no se pueden distinguir a nivel de aplicación.

En Android 10, todas las actividades de mayor enfoque en pilas visibles residen en el estado RESUMED . Esto mejora la compatibilidad con los modos Multi-Window y MD para aplicaciones que usan onPause() en lugar de onStop() para dejar de actualizar la interfaz de usuario e interactuar con el usuario. Esto significa:

• Se reanudan ambas actividades en pantalla dividida.
• Se reanudan todas las actividades más visibles en el modo de ventana de formato libre.
• Las actividades en varias pantallas se pueden reanudar al mismo tiempo.

Figura 1. Currículum múltiple en un dispositivo plegable

Figura 2. Reanudación múltiple en modo escritorio

Las actividades pueden residir en el estado PAUSED cuando no se puede enfocar en ellas o están parcialmente ocluidas, como por ejemplo:

• En una pantalla dividida minimizada (con el iniciador a un lado), la actividad principal no se reanuda porque no se puede enfocar.
• En el modo de imagen en imagen, la actividad no se reanuda porque no se puede enfocar.
• Cuando las actividades están cubiertas por otras actividades transparentes en la misma pila.

Este enfoque indica a las aplicaciones que una actividad puede recibir información de un usuario solo en el estado RESUMED . Antes de Android 10, las actividades también podían recibir entradas en el estado PAUSED (por ejemplo, intente tocar ambas actividades en pantalla dividida simultáneamente en un dispositivo con Android 9).

Para preservar la señal reanudada de versiones anteriores de Android (y para comunicar cuándo las aplicaciones deben obtener acceso a recursos únicos o de acceso exclusivo), Android 10 incluye una nueva devolución de llamada:

Activity#onTopResumedActivityChanged(boolean onTop)

Cuando se invoca, esta devolución de llamada se realiza entre Activity#onResume() y Activity#onPause() . Esta devolución de llamada es opcional y se puede omitir, por lo que una actividad puede pasar de un estado RESUMED a un estado PAUSED sin convertirse en la principal del sistema. Por ejemplo, en modo de ventanas múltiples. Debido a que esta devolución de llamada es opcional, no forma parte del ciclo de vida de la actividad y rara vez debe usarse.

La actividad más reanudada anterior recibe y finaliza la ejecución de onTopResumedActivity(false) antes de que la siguiente actividad más reanudada reciba onTopResumedActivity(true) a menos que la actividad anterior demore demasiado tiempo en manejar la llamada al método y alcance el tiempo de espera de 500 ms.

Compatibilidad

Para mantener la compatibilidad al implementar currículums múltiples, considere estas soluciones.

Múltiples actividades reanudadas en un proceso de aplicación

• Asunto. En Android 9 y versiones anteriores, solo se reanuda una actividad en el sistema a la vez. Todas las transiciones entre actividades implican pausar una actividad antes de reanudar otra. Algunas aplicaciones y marcos (como Flutter o LocalActivityManager de Android) utilizan este hecho y almacenan el estado de la actividad reanudada en singletons.
• Solución. En Android 9 y versiones anteriores, si se reanudan dos actividades del mismo proceso, el sistema solo reanuda la actividad que esté más arriba en el orden Z. Las aplicaciones destinadas a Android 10 pueden admitir la reanudación de múltiples actividades al mismo tiempo.

Acceso simultáneo a la cámara

• Asuntos . Estos problemas también están presentes en Android 9 y versiones anteriores. Por ejemplo, una actividad en pantalla completa y reanudada puede perder el enfoque de la cámara debido a una actividad pausada en la parte superior en el modo de imagen en imagen, pero queda más expuesta con una adopción más amplia de los modos de múltiples ventanas y múltiples pantallas.
  • Debido a los cambios realizados en el estado RESUME , es posible que las aplicaciones se desconecten de la cámara incluso mientras se reanuda . Para solucionar esto, las aplicaciones deben manejar la desconexión de la cámara sin fallar. Cuando se desconectan, las aplicaciones reciben una devolución de llamada desconectada y todas las llamadas a la API comienzan a generar CameraAccessException .
  • resizeableActivity=false no es garantía de acceso exclusivo a la cámara, porque otras aplicaciones que usan la cámara se pueden abrir en otras pantallas.
• Soluciones. Los desarrolladores deben incluir lógica para cuando una aplicación se desconecta de la cámara. Si una aplicación se desconecta de la cámara, debería observar las devoluciones de llamada de disponibilidad de la cámara para intentar volver a conectarse y continuar usando la cámara. Además de la devolución de llamada existente CameraManager#AvailabilityCallback#onCameraAvailable() , Android 10 agregó CameraManager#AvailabilityCallback#onCameraAccessPrioritiesChanged() , que cubre el caso en el que el enfoque (y la prioridad de la cámara) cambia entre varias actividades reanudadas. Los desarrolladores de aplicaciones deben utilizar ambas devoluciones de llamada para determinar un buen momento para intentar acceder a la cámara.

CV múltiple

En Android 10, el estado del ciclo de vida de la actividad está determinado por la visibilidad y el orden Z. Para garantizar que se muestre el estado correcto después de que se actualice la visibilidad de una actividad y evaluar qué estado del ciclo de vida es aplicable, invoque el método ActivityRecord#makeActiveIfNeeded() desde diferentes ubicaciones. En Android 10, activo significa RESUMED o PAUSED y funciona solo en estos dos casos.

En Android 10, la reanudación de una actividad se rastrea por separado en cada pila en lugar de en una única ubicación del sistema. Esto se debe a que se pueden realizar varias transiciones de actividad simultáneamente en modos de ventanas múltiples. Para obtener más información, consulte ActivityStack#mInResumeTopActivity .

Devolución de llamada de actividad más reanudada

Después de acciones que pueden resultar en un cambio de actividad principal (como el inicio de una actividad, su reanudación o un cambio de orden Z), se invoca ActivityStackSupervisor#updateTopResumedActivityIfNeeded() . Este método comprueba si la actividad reanudada más importante cambió y realiza la actualización si es necesario. Si la actividad de reanudación superior anterior no ha liberado el estado de reanudación superior, se le envía un mensaje de pérdida de estado de reanudación superior y se programa un tiempo de espera en el lado del servidor ( ActivityStackSupervisor#scheduleTopResumedStateLossTimeout() ). Se envía un informe del estado de reanudación superior a la siguiente actividad después de que la anterior liberó el estado, o cuando se alcanzó un tiempo de espera (consulte los usos de:

ActivityStackSupervisor#scheduleTopResumedActivityStateIfNeeded()

Se agregó un nuevo elemento de transacción TopResumedActivityChangeItem para informar a los clientes los cambios de estado más reanudados y aprovecha la arquitectura ActivityLifecycler de Android 9.

El estado de reanudación superior se almacena en el lado del cliente, y cada vez que la actividad pasa a RESUMED o PAUSED , también verifica si se debe invocar la devolución de llamada onTopResumedActivityChanged() . Esto permite cierto desacoplamiento en la comunicación de los estados del ciclo de vida y el estado superior reanudado entre el lado del servidor y el del cliente.