Mehrfacher Lebenslauf

In Android 9 (und niedriger) wurden Apps in den PAUSED Zustand versetzt, wenn:

  • Eine neue, durchsichtige Aktivität wurde über der App gestartet, während die App noch sichtbar war (und daher nicht gestoppt wurde).
  • Die Aktivität verlor den Fokus, war jedoch nicht verdeckt und konnte vom Benutzer interagiert werden. Beispielsweise können im Multi-Window-Modus mehrere Aktivitäten sichtbar sein und gleichzeitig Berührungseingaben erhalten.

Diese Situationen unterscheiden sich in der Menge an Pausen , die eine App durchführen muss, können aber nicht auf App-Ebene unterschieden werden.

In Android 10 befinden sich alle oben fokussierbaren Aktivitäten in sichtbaren Stapeln im Status RESUMED . Dies verbessert die Kompatibilität mit den Multi-Window- und MD-Modi für Apps, die onPause() anstelle von onStop() verwenden, um die Aktualisierung der Benutzeroberfläche und die Interaktion mit dem Benutzer zu stoppen. Das heisst:

  • Beide Aktivitäten im Splitscreen werden fortgesetzt.
  • Alle oben sichtbaren Aktivitäten im Freiform-Fenstermodus werden fortgesetzt.
  • Aktivitäten auf mehreren Bildschirmen können gleichzeitig fortgesetzt werden.

Abbildung 1. Mehrfach-Lebenslauf auf einem faltbaren Gerät

Abbildung 2. Mehrfach-Lebenslauf im Desktop-Modus

Aktivitäten können sich im Status PAUSED befinden, wenn sie nicht fokussiert werden können oder teilweise verdeckt sind, wie zum Beispiel:

  • Bei einem minimierten geteilten Bildschirm (mit Launcher an der Seite) wird die oberste Aktivität nicht fortgesetzt, da sie nicht fokussierbar ist.
  • Im Bild-in-Bild-Modus wird die Aktivität nicht fortgesetzt, da sie nicht fokussierbar ist.
  • Wenn Aktivitäten durch andere transparente Aktivitäten im selben Stapel abgedeckt werden.

Dieser Ansatz zeigt Apps an, dass eine Aktivität nur im Status RESUMED Eingaben von einem Benutzer empfangen kann. Vor Android 10 konnten Aktivitäten auch im PAUSED Zustand Eingaben empfangen (versuchen Sie beispielsweise, beide Aktivitäten gleichzeitig im geteilten Bildschirm auf einem Gerät mit Android 9 zu berühren).

Um das wiederaufgenommene Signal früherer Android-Versionen beizubehalten (und um zu kommunizieren, wann Apps Zugriff auf Exklusivzugriffs- oder Singleton-Ressourcen erhalten sollen), enthält Android 10 einen neuen Rückruf:

Activity#onTopResumedActivityChanged(boolean onTop)

Beim Aufruf wird dieser Rückruf zwischen Activity#onResume() und Activity#onPause() aufgerufen. Dieser Rückruf ist optional und kann übersprungen werden, sodass eine Aktivität von einem RESUMED Zustand in einen PAUSED Zustand wechseln kann, ohne zur obersten im System zu werden. Zum Beispiel im Mehrfenstermodus. Da dieser Rückruf optional ist, ist er nicht Teil des Aktivitätslebenszyklus und sollte selten verwendet werden.

Die vorherige Top-Resumed-Aktivität empfängt und beendet die Ausführung von onTopResumedActivity(false) , bevor die nächste Top-Resumed-Aktivität onTopResumedActivity(true) empfängt, es sei denn, die vorherige Aktivität benötigt zu viel Zeit für die Verarbeitung des Methodenaufrufs und erreicht das 500-ms-Timeout.

Kompatibilität

Um die Kompatibilität bei der Implementierung mehrerer Lebensläufe aufrechtzuerhalten, sollten Sie diese Lösungen in Betracht ziehen.

Mehrere wiederaufgenommene Aktivitäten in einem App-Prozess

  • Ausgabe. In Android 9 und niedriger wird jeweils nur eine Aktivität im System wieder aufgenommen. Bei allen Übergängen zwischen Aktivitäten wird eine Aktivität angehalten, bevor eine andere fortgesetzt wird. Einige Apps und Frameworks (z. B. Flutter oder LocalActivityManager von Android) nutzen diese Tatsache und speichern den Status der wieder aufgenommenen Aktivität in Singletons.
  • Lösung. Wenn in Android 9 und niedriger zwei Aktivitäten aus demselben Prozess fortgesetzt werden, setzt das System nur die Aktivität fort, die in Z-Reihenfolge höher liegt. Apps für Android 10 können die gleichzeitige Wiederaufnahme mehrerer Aktivitäten unterstützen.

Gleichzeitiger Kamerazugriff

  • Probleme . Diese Probleme treten auch in Android 9 und niedriger auf. Beispielsweise kann eine im Vollbildmodus ausgeführte und fortgesetzte Aktivität im Bild-in-Bild-Modus den Fokus der Kamera auf eine angehaltene Aktivität darüber verlieren, durch die zunehmende Verwendung von Multi-Window- und Multi-Display-Modi jedoch stärker sichtbar werden.
    • Aufgrund von Änderungen am RESUME Status werden Apps möglicherweise auch im fortgesetzten Zustand von der Kamera getrennt. Um dieses Problem zu beheben, müssen Apps eine Trennung der Kamera ohne Absturz bewältigen. Wenn die Verbindung getrennt wird, erhalten Apps einen getrennten Rückruf und alle Aufrufe an die API beginnen, CameraAccessException auszulösen.
    • resizeableActivity=false ist keine Garantie für den exklusiven Kamerazugriff, da andere Apps, die die Kamera verwenden, auf anderen Displays geöffnet werden können.
  • Lösungen. Entwickler sollten eine Logik für den Fall einbauen, dass eine App von der Kamera getrennt wird. Wenn eine App von der Kamera getrennt wird, sollte sie Rückrufe zur Kameraverfügbarkeit beobachten, um zu versuchen, die Verbindung wiederherzustellen und die Kameraverwendung fortzusetzen. Zusätzlich zum vorhandenen CameraManager#AvailabilityCallback#onCameraAvailable() -Rückruf wurde in Android 10 CameraManager#AvailabilityCallback#onCameraAccessPrioritiesChanged() hinzugefügt, das den Fall abdeckt, dass der Fokus (und die Kamerapriorität) zwischen mehreren wieder aufgenommenen Aktivitäten wechselt. App-Entwickler sollten diese beiden Rückrufe nutzen, um einen geeigneten Zeitpunkt für den Zugriffsversuch auf die Kamera zu ermitteln.

Mehrfacher Lebenslauf

In Android 10 wird der Aktivitätslebenszyklusstatus durch Sichtbarkeit und Z-Reihenfolge bestimmt. Um sicherzustellen, dass nach der Sichtbarkeitsaktualisierung einer Aktivität der richtige Status angezeigt wird, und um zu bewerten, welcher Lebenszyklusstatus anwendbar ist, rufen Sie die Methode ActivityRecord#makeActiveIfNeeded() von verschiedenen Standorten aus auf. In Android 10 bedeutet „Aktiv“ entweder RESUMED “ oder PAUSED und funktioniert nur in diesen beiden Fällen.

In Android 10 wird die Wiederaufnahme einer Aktivität separat in jedem Stapel statt an einem einzigen Ort im System verfolgt. Dies liegt daran, dass im Mehrfenstermodus mehrere Aktivitätsübergänge gleichzeitig durchgeführt werden können. Einzelheiten finden Sie unter ActivityStack#mInResumeTopActivity .

Rückruf der am häufigsten wiederaufgenommenen Aktivität

Nach Aktionen, die zu einer Änderung der Top-Aktivität führen können (z. B. Aktivitätsstart, Wiederaufnahme oder Änderung der Z-Reihenfolge), wird ActivityStackSupervisor#updateTopResumedActivityIfNeeded() aufgerufen. Diese Methode prüft, ob sich die oberste wiederaufgenommene Aktivität geändert hat, und führt bei Bedarf die Aktualisierung durch. Wenn die vorherige Top-Resumed-Aktivität den Top-Resumed-Status nicht freigegeben hat, wird eine Top-Resumed-State-Loss-Nachricht an sie gesendet und ein Timeout auf der Serverseite geplant ( ActivityStackSupervisor#scheduleTopResumedStateLossTimeout() ). Ein Bericht über den wiederaufgenommenen Status wird an die nächste Aktivität gesendet, nachdem die vorherige Aktivität den Status freigegeben hat oder wenn ein Timeout erreicht wurde (siehe Verwendungen von:

ActivityStackSupervisor#scheduleTopResumedActivityStateIfNeeded()

Ein neues TopResumedActivityChangeItem -Transaktionselement wurde hinzugefügt, um Clients Statusänderungen der obersten Wiederaufnahme zu melden und nutzt die ActivityLifecycler Architektur von Android 9.

Der Top-Resumed-Status wird auf der Clientseite gespeichert und jedes Mal, wenn die Aktivität in RESUMED oder PAUSED übergeht, wird außerdem geprüft, ob der Rückruf onTopResumedActivityChanged() aufgerufen werden sollte. Dies ermöglicht eine gewisse Entkopplung bei der Kommunikation der Lebenszykluszustände und des wieder aufgenommenen Zustands zwischen der Server- und der Clientseite.