Mehrere Fortsetzungen

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 Mehrfenstermodus können beispielsweise mehrere Aktivitäten sichtbar sein und gleichzeitig Toucheingaben erhalten.

Diese Situationen unterscheiden sich hinsichtlich der Dauer 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 Benutzeroberfläche nicht mehr zu aktualisieren und nicht mehr mit dem Nutzer zu interagieren. Das bedeutet:

  • Beide Aktivitäten im Splitscreen werden fortgesetzt.
  • Alle oben sichtbaren Aktivitäten im Modus für kostenlos platzierbare Fenster 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.:

  • In einem minimierten Splitscreen (mit Launcher an der Seite) wird die oberste Aktivität nicht fortgesetzt, da sie nicht fokussiert werden kann.
  • Im Bild-im-Bild-Modus wird die Aktivität nicht fortgesetzt, da sie nicht fokussiert werden kann.
  • Wenn Aktivitäten von anderen transparenten Aktivitäten im selben Stack abgedeckt werden.

Mit 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)

Dieser Callback wird 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

Um die Kompatibilität bei der Implementierung von Multi-Resume beizubehalten, sollten Sie die folgenden Lösungen in Betracht ziehen.

Mehrere fortgesetzte 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 diese Tatsache 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, setzt das System nur die Aktivität fort, die in der Z-Reihenfolge höher ist. Apps, die auf Android 10 ausgerichtet sind, können mehrere Aktivitäten gleichzeitig fortsetzen.

Gleichzeitiger Kamerazugriff

  • Probleme Diese Probleme treten auch unter Android 9 und niedriger auf. Beispielsweise kann 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 Status RESUME werden Apps möglicherweise auch während der Wiederaufnahme 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 eine Logik für den Fall einschließen, dass die Verbindung einer App zur Kamera getrennt wird. 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. Rufen Sie die Methode ActivityRecord#makeActiveIfNeeded() an verschiedenen Stellen auf, um sicherzustellen, dass nach Aktualisierungen der Sichtbarkeit einer Aktivität der richtige Status angezeigt wird, und um zu prüfen, welcher Lebenszyklusstatus zutrifft. Unter Android 10 bedeutet „aktiv“ entweder RESUMED oder PAUSED und funktioniert nur in diesen beiden Fällen.

Unter Android 10 wird die Fortsetzung einer Aktivität in jedem Stack separat erfasst, anstatt an einem einzigen Ort im System. Das liegt daran, dass im Modus mit mehreren Fenstern 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 des Status „Top-fortgesetzt“ an Clients zu melden. Dabei wird die ActivityLifecycler-Architektur von Android 9 genutzt.

Der Top-Fortgesetzt-Status wird auf der Clientseite gespeichert. Jedes Mal, wenn die Aktivität zu RESUMED oder PAUSED wechselt, 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.