Cette page a été traduite par l'API Cloud Translation.

Multireprise

Sous Android 9 (et versions antérieures), les applications étaient passées à l'état PAUSED lorsque:

Une nouvelle activité translucide lancée au-dessus de l'application, alors que celle-ci était encore visible (et n'a donc pas été arrêté).
L'activité n'est plus au centre de l'attention, mais n'est pas masquée et l'utilisateur peut interagir avec elle. Pour Par exemple, en mode multifenêtre, un certain nombre d'activités peuvent être visibles et recevoir des commandes tactiles. simultanément.

Ces situations diffèrent au niveau de la mise en veille d'une application, mais ne peuvent pas être distinguée au niveau de l'application.

Dans Android 10, toutes les activités les plus pertinentes des piles visibles se trouvent l'état RESUMED. Cela améliore la compatibilité avec Multifenêtre et MD pour les applications qui utilisent onPause() au lieu de onStop() pour arrêter d'actualiser l'UI et d'interagir avec l'utilisateur. Autrement dit :

Les deux activités en écran partagé ont repris.
Toutes les activités visibles en haut de page en mode fenêtrage de format libre sont réactivées.
Les activités sur plusieurs écrans peuvent être réactivées en même temps.

Figure 1 : Multireprise sur un appareil pliable

Figure 2. Multireprise en mode ordinateur

Les activités peuvent se trouver à l'état PAUSED lorsqu'elles ne peuvent pas être sélectionnées ou qu'elles sont en partie cachées, par exemple:

Dans un écran partagé réduit (avec le lanceur d'applications sur le côté), l'activité supérieure n'est pas réactivée, car elle est non sélectionnable.
En mode Picture-in-picture, l'activité n'est pas réactivée, car elle n'est pas sélectionnable.
Lorsque des activités sont recouvertes par d'autres activités transparentes dans la même pile.

Cette approche indique aux applications qu'une activité peut recevoir des données d'un qu'à l'état RESUMED. Avant Android 10, les activités peuvent également recevoir des entrées à l'état PAUSED (par exemple, essayez d'appuyer sur les deux activités simultanément en écran partagé sur un appareil équipé d'Android 9).

Pour conserver le signal réactivé des versions précédentes d'Android (et pour indiquer quand les applications doivent obtenir l'accès à l'accès exclusif ou au singleton ressources), Android 10 inclut un nouveau rappel:

Activity#onTopResumedActivityChanged(boolean onTop)

Lorsqu'il est appelé, ce rappel est appelé entre Activity#onResume() et Activity#onPause(). Ce rappel est facultatif et peut être ignoré. Ainsi, une activité peut passer de l'état RESUMED à l'état PAUSED. sans devenir le sommet du système. (en mode multifenêtre, par exemple). Ce rappel étant facultatif, il ne fait pas partie de l'objet Activity Lifecycle et doit être rarement utilisé.

L'activité précédente réactivée reçoit et termine l'exécution de onTopResumedActivity(false) avant la prochaine activité la plus réactivée reçoit onTopResumedActivity(true), sauf si l'activité précédente met trop de temps à gérer l'appel de méthode et atteint le délai avant expiration de 500 ms.

Compatibilité

Pour maintenir la compatibilité lors de l'implémentation de la multireprise, tenez compte de ces de Google Cloud.

Plusieurs activités réactivées dans un même processus d'application

Problème. Sous Android 9 et versions antérieures, une seule activité dans le système reprise à la fois. Toutes les transitions entre les activités impliquent de mettre en pause avant d'en reprendre une autre. Certains frameworks et applications (comme Flutter, LocalActivityManager d'Android) utilisent ce fait et stockent l'état de la reprise dans les singletons.
Solution : Sous Android 9 et versions antérieures, si deux activités du même processus sont toutes deux réactivées, le système ne reprend que l'activité dont le niveau est le plus élevé dans l'ordre Z. Les applis ciblant Android 10 peuvent prendre en charge plusieurs activités en cours de reprise en même temps.

Accès simultané à la caméra

Problèmes : Ces problèmes sont également présents dans Android 9 et moins élevée. Par exemple, une activité en plein écran et une reprise d'activité peuvent perdre la mise au point une activité interrompue en mode Picture-in-picture, une adoption plus large des modes multifenêtre et multi-écran
- En raison des modifications apportées à l'état RESUME, les applications peuvent être déconnecté de la caméra, même en cas de reprise de l'activité. Pour résoudre ce problème, les applications doit pouvoir se déconnecter sans planter. Une fois déconnectées, les applications reçoivent une un rappel déconnecté et tous les appels vers l'API commencent à générer CameraAccessException
- resizeableActivity=false ne garantit pas l'exclusivité de la caméra. car les autres applis utilisant l'appareil photo peuvent être ouvertes sur d'autres écrans.
Solutions : Les développeurs doivent intégrer une logique pour déterminer quand une application est déconnectée de la caméra. Si une application est déconnectée de la caméra, doit regarder les rappels de disponibilité de la caméra pour essayer de se reconnecter et de continuer l'utilisation de l'appareil photo. En plus des Rappel de CameraManager#AvailabilityCallback#onCameraAvailable(), Android 10 ajouté CameraManager#AvailabilityCallback#onCameraAccessPrioritiesChanged(), qui couvre le cas où la mise au point (et la priorité de l'appareil photo) alternent entre plusieurs reprise des activités. Les développeurs d'applications doivent utiliser ces deux rappels pour déterminer le bon moment pour essayer d'accéder à la caméra.

Multireprise

Sous Android 10, l'état du cycle de vie d'une activité est déterminé par la visibilité et Ordre de plan. Pour garantir le bon état après la mise à jour de la visibilité sur une et évaluer l'état du cycle de vie applicable, appelez la méthode méthode ActivityRecord#makeActiveIfNeeded() de différentes emplacements. Dans Android 10, "actif" signifie soit RESUMED, soit PAUSED et ne fonctionne que dans ces deux cas.

Sous Android 10, la reprise d'une activité est suivie séparément dans chaque pile et non à un seul endroit dans le système. En effet, plusieurs les transitions d'activités peuvent être effectuées simultanément en mode multifenêtre. Pour détails, voir ActivityStack#mInResumeTopActivity.

Rappel de l'activité la plus réactivée

Après des actions pouvant entraîner une modification majeure de l'activité (par exemple, un lancement, une reprise ou un changement d'ordre de plan), ActivityStackSupervisor#updateTopResumedActivityIfNeeded() est appelé. Ce vérifie si l'activité la plus réactivée a changé et effectue la mise à jour si nécessaires. Si l'activité précédente ayant été le mieux relancée n'a pas libéré l'activité la plus réactivée l'état de reprise, un message de perte d'état de reprise est envoyé et un délai d'inactivité est planifiée côté serveur (ActivityStackSupervisor#scheduleTopResumedStateLossTimeout()). Un rapport sur l'état de reprise est envoyé à l'activité suivante après l'activité précédente l'une d'elles a libéré l'état ou quand un délai a été atteint (voir les utilisations de:

ActivityStackSupervisor#scheduleTopResumedActivityStateIfNeeded()

Un nouvel élément de transaction TopResumedActivityChangeItem a été ajouté pour signaler les changements d'état les plus repris aux clients et s'appuie sur Architecture ActivityLifecycler d'Android 9.

L'état de reprise est stocké côté client. Chaque fois que l'activité passe à RESUMED ou PAUSED, elle aussi vérifie si le rappel onTopResumedActivityChanged() doit être invoquée. Cela permet une certaine dissociation dans la communication des états du cycle de vie et l'état de reprise après sinistre entre les côtés serveur et côté client.