Mehrere Fortsetzungen

In Android 9 und niedriger wechselten Apps in den Status PAUSED, wenn:

  • Eine neue, durchscheinende Aktivität wurde über der App gestartet, während die App noch sichtbar war und daher nicht beendet wurde.
  • Die Aktivität hat den Fokus verloren, war aber nicht verdeckt und der Nutzer konnte mit ihr interagieren. Im Mehrfenstermodus können beispielsweise mehrere Aktivitäten gleichzeitig sichtbar sein und Touch-Eingaben empfangen.

Diese Situationen unterscheiden sich in der Häufigkeit, mit der eine App pausiert werden muss, können aber nicht auf App-Ebene unterschieden werden.

In Android 10 befinden sich alle Aktivitäten, die im Vordergrund angezeigt werden können, in sichtbaren Stacks im Status RESUMED. Dadurch wird die Kompatibilität mit Multi-Window- und MD-Modi für Apps verbessert, die onPause() anstelle von onStop() verwenden, um das Aktualisieren der Benutzeroberfläche und die Interaktion mit dem Nutzer zu beenden. Das heißt:

  • Beide Aktivitäten im Splitscreen werden fortgesetzt.
  • Alle Aktivitäten, die im Freiformfenstermodus oben sichtbar sind, 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 sich im Status PAUSED befinden, wenn sie nicht im Fokus stehen oder teilweise verdeckt sind, z. B.:

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

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

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

Activity#onTopResumedActivityChanged(boolean onTop)

Wenn dieser Callback aufgerufen wird, geschieht das zwischen Activity#onResume() und Activity#onPause(). Dieser Callback ist optional und kann übersprungen werden. Eine Aktivität kann also vom Status RESUMED in den Status PAUSED wechseln, ohne dass sie im System ganz oben angezeigt wird. Zum Beispiel im Mehrfenstermodus. Da dieser Callback optional ist, ist er nicht Teil des Activity-Lebenszyklus und sollte nur selten verwendet werden.

Die vorherige Aktivität im Vordergrund erhält und führt onTopResumedActivity(false) aus, bevor die nächste Aktivität im Vordergrund onTopResumedActivity(true) erhält, es sei denn, die vorherige Aktivität benötigt zu viel Zeit für die Verarbeitung des Methodenaufrufs und erreicht das Zeitlimit von 500 ms.

Kompatibilität

Wenn du die Funktion „Fortsetzen“ implementierst und die Kompatibilität beibehalten möchtest, kannst du 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 pausiert, bevor eine andere fortgesetzt wird. Einige Apps und Frameworks (z. B. Flutter oder LocalActivityManager von Android) nutzen diese Tatsache und speichern den Status der fortgesetzten Aktivität in Singletons.
  • Lösung Unter Android 9 und niedriger wird, wenn zwei Aktivitäten aus demselben Prozess fortgesetzt werden, nur die Aktivität fortgesetzt, die in der Z-Reihenfolge höher steht. Apps, die auf Android 10 ausgerichtet sind, können unterstützen, dass mehrere Aktivitäten gleichzeitig fortgesetzt werden.

Gleichzeitiger Kamerazugriff

  • Probleme Diese Probleme treten auch unter Android 9 und niedriger auf. Beispiel: Eine im Vollbildmodus ausgeführte und fortgesetzte Aktivität kann den Kamerafokus an eine pausierte Aktivität im Bild-im-Bild-Modus verlieren, wird aber bei einer breiteren Einführung von Mehrfenster- und Mehrfachanzeigemodi stärker genutzt.
    • Aufgrund von Änderungen am RESUME-Status werden Apps möglicherweise von der Kamera getrennt, auch wenn sie fortgesetzt werden. Um dieses Problem zu beheben, müssen Apps einen Kamera-Disconnect ohne Absturz verarbeiten können. Wenn die Verbindung getrennt wird, erhalten Apps einen Callback für die getrennte Verbindung und bei allen Aufrufen der API wird CameraAccessException ausgegeben.
    • resizeableActivity=false bietet 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 Logik dafür einbauen, wann eine App von der Kamera getrennt wird. Wenn eine App von der Kamera getrennt wird, sollte sie auf Rückrufe zur Kameraverfügbarkeit warten, um die Verbindung wiederherzustellen und die Kamera weiter zu verwenden. Zusätzlich zum vorhandenen CameraManager#AvailabilityCallback#onCameraAvailable()-Callback wurde in Android 10 CameraManager#AvailabilityCallback#onCameraAccessPrioritiesChanged() eingeführt, das den Fall abdeckt, in dem der Fokus (und die Kamerapriorität) zwischen mehreren fortgesetzten Aktivitäten wechselt. App-Entwickler sollten beide Rückrufe verwenden, um einen guten Zeitpunkt für den Zugriff auf die Kamera zu ermitteln.

Multi-Resume

In Android 10 wird der Aktivitätslebenszyklusstatus durch die Sichtbarkeit und die Z-Reihenfolge bestimmt. Damit der richtige Status nach Sichtbarkeitsaktualisierungen für eine Aktivität festgelegt und der zutreffende Lebenszyklusstatus ermittelt wird, rufen Sie die Methode ActivityRecord#makeActiveIfNeeded() von verschiedenen Stellen aus auf. In Android 10 bedeutet „aktiv“ entweder RESUMED oder PAUSED und funktioniert nur in diesen beiden Fällen.

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

Callback für die am häufigsten fortgesetzte Aktivität

Nach Aktionen, die zu einer Änderung der obersten Aktivität führen können (z. B. Starten, Fortsetzen oder Ändern der Z-Reihenfolge einer Aktivität), wird ActivityStackSupervisor#updateTopResumedActivityIfNeeded() aufgerufen. Mit dieser Methode wird geprüft, ob sich die oberste fortgesetzte Aktivität geändert hat. Falls erforderlich, wird die Aktualisierung durchgeführt. Wenn die vorherige Aktivität, die im Vordergrund fortgesetzt wurde, den Status „top-resumed“ nicht freigegeben hat, wird eine Nachricht zum Verlust des Status „top-resumed“ an sie gesendet und serverseitig ein Zeitlimit festgelegt (ActivityStackSupervisor#scheduleTopResumedStateLossTimeout()). Ein Bericht zum Status „top-resumed“ wird an die nächste Aktivität gesendet, nachdem die vorherige den Status freigegeben hat oder wenn ein Zeitlimit erreicht wurde (siehe Verwendungen von:

ActivityStackSupervisor#scheduleTopResumedActivityStateIfNeeded()

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

Der Status „Top-resumed“ wird auf der Clientseite gespeichert. Jedes Mal, wenn die Aktivität in den Status RESUMED oder PAUSED wechselt, wird auch geprüft, ob der onTopResumedActivityChanged()-Callback aufgerufen werden soll. Dadurch wird die Kommunikation von Lebenszyklusstatus und dem Status „Top-Resumed“ zwischen Server und Client entkoppelt.