Multi-currículum

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

• Se lanzó 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 estaba oculta y el usuario podía interactuar con ella. Por ejemplo, en el modo de ventanas múltiples, varias actividades pueden ser visibles y recibir entradas táctiles simultáneamente.

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

En Android 10, todas las actividades en las que se puede enfocar desde arriba en pilas visibles residen en el estado RESUMED . Esto mejora la compatibilidad con los modos multiventana 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 visibles en la parte superior en el modo de ventanas de forma libre.
• Las actividades en varias pantallas se pueden reanudar al mismo tiempo.

Figura 1. Curriculum vitae múltiple en un dispositivo plegable

Figura 2. Curriculum vitae múltiple en modo de escritorio

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

• En una pantalla dividida minimizada (con el lanzador al costado), la actividad principal no se reanuda porque no se puede enfocar.
• En un 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 de acceso exclusivo o singleton), Android 10 incluye una nueva devolución de llamada:

Activity#onTopResumedActivityChanged(boolean onTop)

Cuando se invoca, esta devolución de llamada se llama 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 parte superior del sistema. Por ejemplo, en el modo multiventana. Debido a que esta devolución de llamada es opcional, no es parte del ciclo de vida de la actividad y debe usarse con poca frecuencia.

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

Compatibilidad

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

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

• Tema. 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 es superior en 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

• problemas Estos problemas también están presentes en Android 9 y versiones anteriores. Por ejemplo, una actividad de pantalla completa y reanudada puede perder el enfoque de la cámara a una actividad pausada en la parte superior en el modo de imagen en imagen, pero quedar más expuesta con una adopción más amplia de 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 reanudan . Para abordar esto, las aplicaciones deben manejar una desconexión de la cámara sin bloquearse. Cuando se desconectan, las aplicaciones obtienen una devolución de llamada desconectada y todas las llamadas a la API comienzan a CameraAccessException .
  • resizeableActivity=false no es una 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 una 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 ver 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 CameraManager#AvailabilityCallback#onCameraAvailable() existente, Android 10 agregó CameraManager#AvailabilityCallback#onCameraAccessPrioritiesChanged() , que cubre el caso cuando el enfoque (y la prioridad de la cámara) cambia entre varias actividades reanudadas. Los desarrolladores de aplicaciones deben usar ambas devoluciones de llamada para determinar un buen momento para intentar obtener acceso a la cámara.

Multicurrículum

En Android 10, el estado del ciclo de vida de la actividad está determinado por la visibilidad y el orden Z. Para asegurarse de que el estado correcto después de las actualizaciones de visibilidad en 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 PAUSED RESUMED solo funciona en estas dos instancias.

En Android 10, la reanudación de una actividad se rastrea por separado en cada pila en lugar de en la ubicación única 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 las acciones que pueden resultar en un cambio de actividad superior (como el inicio de la actividad, la reanudación o el cambio de orden Z), se invoca ActivityStackSupervisor#updateTopResumedActivityIfNeeded() . Este método verifica si la actividad reanudada superior cambió y realiza la actualización si es necesario. Si la actividad anterior más reanudada no ha liberado el estado de máxima reanudación, se le envía un mensaje de pérdida de estado de máxima reanudación y se programa un tiempo de espera en el lado del servidor ( ActivityStackSupervisor#scheduleTopResumedStateLossTimeout() ). Se envía un informe del estado superior reanudado a la siguiente actividad después de que la anterior liberó el estado, o cuando se agotó el tiempo de espera (consulte los usos de:

ActivityStackSupervisor#scheduleTopResumedActivityStateIfNeeded()

Se agregó un nuevo elemento de transacción TopResumedActivityChangeItem para informar los cambios de estado más reanudados a los clientes 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 de reanudación superior entre el lado del servidor y el del cliente.