Mehrere Wiederholungen

Unter Android 9 und niedriger wurden Apps in den Status PAUSED versetzt, wenn:

  • Eine neue, halbtransparente Aktivität wurde über der App gestartet, während die App noch sichtbar war (und daher nicht beendet wurde).
  • Der Fokus wurde von der Aktivität aufgehoben, sie war aber nicht verdeckt und der Nutzer konnte mit ihr interagieren. Im Multifenstermodus können beispielsweise mehrere Aktivitäten sichtbar sein und gleichzeitig Toucheingaben erhalten.

Diese Situationen unterscheiden sich hinsichtlich der Pausierung, die eine App vornehmen muss, können aber nicht auf App-Ebene unterschieden werden.

In Android 10 befinden sich alle Aktivitäten, die sich in sichtbaren Stapeln auf den ersten Plätzen befinden, im Status RESUMED. Dadurch wird die Kompatibilität mit den Modi Multi-Window und MD für Apps verbessert, die onPause() anstelle von onStop() verwenden, um die Aktualisierung der Benutzeroberfläche zu beenden und mit dem Nutzer zu interagieren. Das bedeutet:

  • Beide Aktivitäten im Splitscreen werden fortgesetzt.
  • Alle am besten sichtbaren Aktivitäten im Windowing-Modus im freien Format werden fortgesetzt.
  • Aktivitäten auf mehreren Bildschirmen können gleichzeitig fortgesetzt werden.

Abbildung 1. Multi-Resume auf einem faltbaren Gerät

Abbildung 2: Multi-Resume im Desktop-Modus

Aktivitäten können den Status PAUSED haben, wenn sie nicht scharfgestellt werden können oder teilweise verdeckt sind, z. B.:

  • Bei einem minimierten geteilten Bildschirm (mit Launcher an der Seite) wird die Hauptaktivität nicht fortgesetzt, da sie nicht fokussierbar ist.
  • Im Bild-im-Bild-Modus wird die Aktivität nicht fortgesetzt, weil sie nicht fokussierbar ist.
  • Wenn Aktivitäten von anderen transparenten Aktivitäten im selben Stack abgedeckt werden.

Bei diesem Ansatz wird Apps mitgeteilt, dass eine Aktivität nur im Status RESUMED Eingaben von einem Nutzer erhalten kann. Vor Android 10 konnten Aktivitäten auch im Status PAUSED Eingaben erhalten. Versuchen Sie beispielsweise, auf einem Gerät mit Android 9 gleichzeitig beide Aktivitäten im Splitscreen-Modus zu berühren.

Um das Signal resumed aus früheren Android-Releases beizubehalten und zu kommunizieren, wann Apps Zugriff auf Ressourcen mit exklusivem Zugriff oder Singleton-Ressourcen erhalten sollen, enthält Android 10 einen neuen Rückruf:

Activity#onTopResumedActivityChanged(boolean onTop)

Wenn dieser Callback aufgerufen wird, wird er zwischen Activity#onResume() und Activity#onPause() aufgerufen. Dieser Rückruf ist optional und kann übersprungen werden. So kann eine Aktivität von einem RESUMED- in einen PAUSED-Status wechseln, ohne dass sie im System an oberster Stelle steht. Zum Beispiel im Mehrfenstermodus. Da dieser Rückruf optional ist, ist er nicht Teil des Aktivitätszyklus und sollte selten verwendet werden.

Die vorherige Aktivität, die zuletzt fortgesetzt wurde, empfängt und führt die Ausführung von onTopResumedActivity(false) aus, bevor die nächste Aktivität, die zuletzt fortgesetzt wurde, onTopResumedActivity(true) empfängt, es sei denn, die vorherige Aktivität benötigt zu viel Zeit für die Verarbeitung des Methodenaufrufs und erreicht die Zeitüberschreitung von 500 ms.

Kompatibilität

Berücksichtigen Sie diese Lösungen, um die Kompatibilität bei der Implementierung von mehreren Lebensläufen aufrechtzuerhalten.

Mehrere wiederaufgenommene Aktivitäten in einem App-Prozess

  • Problem. Unter Android 9 und niedriger wird jeweils nur eine Aktivität im System fortgesetzt. 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 der LocalActivityManager von Android) nutzen diesen Umstand und speichern den Status der fortgesetzten Aktivität in Singletons.
  • Lösung. Wenn unter Android 9 und niedriger zwei Aktivitäten desselben Prozesses fortgesetzt werden, wird nur die Aktivität fortgesetzt, die in der Z-Reihenfolge höher ist. Apps, die auf Android 10 ausgerichtet sind, können mehrere Aktivitäten gleichzeitig unterstützen.

Gleichzeitiger Kamerazugriff

  • Probleme Diese Probleme treten auch unter Android 9 und niedriger auf. So kann beispielsweise der Kamerafokus bei einer Vollbild- und fortgesetzten Aktivität im Bild-im-Bild-Modus auf eine pausierte Aktivität oben gelenkt werden. Mit der zunehmenden Verbreitung von Mehrfenster- und Mehrfachanzeigemodi wird die Aktivität jedoch besser sichtbar.
    • Aufgrund von Änderungen am RESUME-Status werden Apps möglicherweise auch bei fortgesetzter Wiedergabe von der Kamera getrennt. Apps müssen daher eine Kameratrennung verarbeiten, ohne abzustürzen. Wenn die Verbindung getrennt wird, erhalten Apps einen Callback und alle Aufrufe an die API werfen CameraAccessException.
    • resizeableActivity=false ist keine Garantie für den exklusiven Zugriff auf die Kamera, da andere Apps, die die Kamera verwenden, auf anderen Displays geöffnet werden können.
  • Lösungen Entwickler sollten Logik für den Fall angeben, dass eine App von der Kamera getrennt ist. Wenn die Verbindung einer App zur Kamera getrennt wird, sollte sie Callbacks zur Kameraverfügbarkeit beobachten, um eine erneute Verbindung herzustellen und die Kamera weiter zu verwenden. Zusätzlich zum vorhandenen CameraManager#AvailabilityCallback#onCameraAvailable()-Callback wurde in Android 10 CameraManager#AvailabilityCallback#onCameraAccessPrioritiesChanged() hinzugefügt. Dieser wird aufgerufen, wenn der Fokus (und die Kamerapriorität) zwischen mehreren fortgesetzten Aktivitäten wechselt. App-Entwickler sollten beide Callbacks verwenden, um den richtigen Zeitpunkt für den Zugriff auf die Kamera zu bestimmen.

Mehrere Fortsetzungen

In Android 10 wird der Aktivitätslebenszyklusstatus durch Sichtbarkeit und Z-Reihenfolge bestimmt. Damit der korrekte Status nach der Aktualisierung einer Aktivität sichergestellt und bewertet wird, welcher Lebenszyklusstatus anwendbar ist, rufen Sie die Methode ActivityRecord#makeActiveIfNeeded() von verschiedenen Speicherorten aus auf. In Android 10 bedeutet „aktiv“ entweder RESUMED oder PAUSED und funktioniert nur in diesen beiden Fällen.

In Android 10 wird das Fortsetzen einer Aktivität separat in jedem Stack und nicht an einem einzigen Ort im System verfolgt. Das liegt daran, dass im Mehrfenstermodus mehrere Aktivitätsübergänge gleichzeitig ausgeführt werden können. Weitere Informationen finden Sie unter ActivityStack#mInResumeTopActivity.

Rückruf für die am häufigsten fortgesetzte Aktivität

Nach Aktionen, die zu einer Änderung der Top-Aktivität führen können, z. B. Starten, Fortsetzen oder Änderung der Z-Reihenfolge einer Aktivität, wird ActivityStackSupervisor#updateTopResumedActivityIfNeeded() aufgerufen. Bei dieser Methode wird geprüft, ob sich die oberste fortgesetzte Aktivität geändert hat, und bei Bedarf wird eine Aktualisierung durchgeführt. Wenn die vorherige Aktivität mit dem Status „Top-fortgesetzt“ den Status nicht freigegeben hat, wird eine Nachricht zum Verlust des Status „Top-fortgesetzt“ an sie gesendet und auf der Serverseite wird ein Zeitlimit festgelegt (ActivityStackSupervisor#scheduleTopResumedStateLossTimeout()). Nachdem die vorherige Aktivität den Status freigegeben hat oder ein Zeitlimit erreicht wurde, wird ein Bericht zum Status „Top-fortgesetzt“ an die nächste Aktivität gesendet (siehe Verwendung von:

ActivityStackSupervisor#scheduleTopResumedActivityStateIfNeeded()

Es wurde ein neues Transaktionselement vom Typ TopResumedActivityChangeItem hinzugefügt, um Änderungen am Status „Top-fortgesetzt“ an Clients zu melden. Dabei wird die ActivityLifecycler-Architektur von Android 9 genutzt.

Der Top-Fortsetzungszustand wird clientseitig gespeichert. Jedes Mal, wenn die Aktivität zu RESUMED oder PAUSED übergeht, wird auch geprüft, ob der onTopResumedActivityChanged()-Callback aufgerufen werden soll. Dies ermöglicht eine gewisse Entkopplung bei der Kommunikation der Lebenszyklusstatus und des Top-Resumed-Status zwischen der Server- und der Clientseite.