Ripresa multipla

In Android 9 (e versioni precedenti), le app venivano inserite nello stato PAUSED quando:

• Una nuova attività traslucida avviata sopra l'app, mentre l'app era ancora visibile (e, pertanto, non è stata interrotta).
• L'attività ha perso il focus, ma non era oscurata e l'utente poteva interagire. Ad esempio, in modalità multi-finestra, diverse attività possono essere visibili e ricevere input tattili contemporaneamente.

Queste situazioni differiscono nella quantità di pause che un'app deve eseguire, ma non possono essere distinte a livello di app.

In Android 10, tutte le attività principali negli stack visibili risiedono nello stato RESUMED . Ciò migliora la compatibilità con le modalità Multi-Window e MD per le app che utilizzano onPause() anziché onStop() per interrompere l'aggiornamento dell'interfaccia utente e l'interazione con l'utente. Questo significa:

• Vengono riprese entrambe le attività a schermo diviso.
• Tutte le attività più visibili nella modalità a finestre in formato libero vengono riprese.
• Le attività su più schermi possono essere riprese contemporaneamente.

Figura 1. Curriculum multiplo su un dispositivo pieghevole

Figura 2. Riprendi multiplo in modalità desktop

Le attività possono risiedere nello stato PAUSED quando non è possibile focalizzarle o sono parzialmente occluse, come ad esempio:

• In uno schermo diviso ridotto a icona (con il programma di avvio a lato), l'attività principale non viene ripresa perché non è attivabile.
• In modalità immagine nell'immagine, l'attività non viene ripresa perché non è possibile focalizzarla.
• Quando le attività sono coperte da altre attività trasparenti nello stesso stack.

Questo approccio indica alle app che un'attività può ricevere input da un utente solo nello stato RESUMED . Prima di Android 10, le attività potevano ricevere input anche nello stato PAUSED (ad esempio, prova a toccare entrambe le attività contemporaneamente su schermo diviso su un dispositivo con Android 9).

Per preservare il segnale di ripresa dalle versioni precedenti di Android (e per comunicare quando le app dovrebbero ottenere l'accesso alle risorse ad accesso esclusivo o singleton), Android 10 include un nuovo callback:

Activity#onTopResumedActivityChanged(boolean onTop)

Quando richiamato, questo callback viene chiamato tra Activity#onResume() e Activity#onPause() . Questa richiamata è facoltativa e può essere ignorata, pertanto un'attività può passare dallo stato RESUMED allo stato PAUSED senza diventare la più in alto nel sistema. Ad esempio, in modalità multi-finestra. Poiché questa richiamata è facoltativa, non fa parte del ciclo di vita dell'attività e deve essere utilizzata raramente.

L'attività con ripresa in alto precedente riceve e termina l'esecuzione di onTopResumedActivity(false) prima che la successiva attività con ripresa in alto riceva onTopResumedActivity(true) a meno che l'attività precedente non impieghi troppo tempo per gestire la chiamata al metodo e raggiunga il timeout di 500 ms.

Compatibilità

Per mantenere la compatibilità quando si implementa il curriculum multiplo, prendere in considerazione queste soluzioni.

Più attività riprese in un unico processo dell'app

• Problema. In Android 9 e versioni precedenti, viene ripresa solo un'attività del sistema alla volta. Tutte le transizioni tra le attività implicano la sospensione di un'attività prima di riprenderne un'altra. Alcune app e framework (come Flutter o LocalActivityManager di Android) utilizzano questo fatto e memorizzano lo stato dell'attività ripresa in singleton.
• Soluzione. In Android 9 e versioni precedenti, se vengono riprese due attività dello stesso processo, il sistema riprende solo l'attività superiore nell'ordine Z. Le app destinate ad Android 10 possono supportare la ripresa di più attività contemporaneamente.

Accesso simultaneo alla telecamera

• Problemi . Questi problemi sono presenti anche in Android 9 e versioni precedenti. Ad esempio, un'attività a schermo intero ripresa può perdere la messa a fuoco della fotocamera a favore di un'attività in pausa in alto in modalità immagine nell'immagine, ma diventare più esposta con una più ampia adozione delle modalità multi-finestra e multi-display.
  • A causa delle modifiche apportate allo stato RESUME , le app potrebbero essere disconnesse dalla fotocamera anche durante la ripresa . Per risolvere questo problema, le app devono gestire la disconnessione della fotocamera senza arresti anomali. Quando sono disconnesse, le app ricevono una richiamata disconnessa e tutte le chiamate nell'API iniziano a lanciare CameraAccessException .
  • resizeableActivity=false non è una garanzia di accesso esclusivo alla fotocamera, perché altre app che utilizzano la fotocamera possono essere aperte su altri display.
• Soluzioni. Gli sviluppatori dovrebbero includere la logica per quando un'app viene disconnessa dalla fotocamera. Se un'app viene disconnessa dalla fotocamera, dovrebbe monitorare le richiamate di disponibilità della fotocamera per provare a riconnettersi e continuare a utilizzare la fotocamera. Oltre al callback CameraManager#AvailabilityCallback#onCameraAvailable() esistente, Android 10 ha aggiunto CameraManager#AvailabilityCallback#onCameraAccessPrioritiesChanged() , che copre il caso in cui lo stato attivo (e la priorità della fotocamera) passa tra diverse attività riprese. Gli sviluppatori di app dovrebbero utilizzare entrambi questi callback per determinare il momento opportuno per provare ad accedere alla fotocamera.

Curriculum multiplo

In Android 10, lo stato del ciclo di vita dell'attività è determinato dalla visibilità e dall'ordine Z. Per garantire che lo stato corretto dopo l'aggiornamento della visibilità su un'attività e valutare quale stato del ciclo di vita sia applicabile, richiamare il metodo ActivityRecord#makeActiveIfNeeded() da posizioni diverse. In Android 10, attivo significa RESUMED o PAUSED e funziona solo in questi due casi.

In Android 10, la ripresa di un'attività viene tracciata separatamente in ogni stack anziché in un'unica posizione nel sistema. Questo perché diverse transizioni di attività possono essere eseguite simultaneamente in modalità multi-finestra. Per maggiori dettagli, consulta ActivityStack#mInResumeTopActivity .

Richiamata dell'attività principale ripresa

Dopo le azioni che possono comportare una modifica dell'attività principale (come l'avvio, la ripresa o la modifica dell'ordine Z dell'attività), viene richiamato ActivityStackSupervisor#updateTopResumedActivityIfNeeded() . Questo metodo controlla se l'attività ripresa più in alto è cambiata ed esegue l'aggiornamento, se necessario. Se la precedente attività di massima ripresa non ha rilasciato lo stato di massima ripresa, le viene inviato un messaggio di perdita dello stato di massima ripresa e viene pianificato un timeout sul lato server ( ActivityStackSupervisor#scheduleTopResumedStateLossTimeout() ). Un report dello stato ripreso in alto viene inviato all'attività successiva dopo che quella precedente ha rilasciato lo stato o quando si è verificato un timeout (vedere gli usi di:

ActivityStackSupervisor#scheduleTopResumedActivityStateIfNeeded()

È stato aggiunto un nuovo elemento di transazione TopResumedActivityChangeItem per segnalare ai client le modifiche di stato più ripristinate e sfrutta l'architettura ActivityLifecycler di Android 9.

Lo stato top-resumed viene archiviato sul lato client e ogni volta che l'attività passa a RESUMED o PAUSED controlla anche se è necessario richiamare il callback onTopResumedActivityChanged() . Ciò consente un certo disaccoppiamento nella comunicazione degli stati del ciclo di vita e dello stato di ripresa superiore tra il lato server e quello client.