Verhaltensänderungen: alle Apps

Die Android 12-Plattform umfasst Verhaltensänderungen, die sich auf deine App auswirken können. Die folgenden Änderungen gelten für alle Apps, wenn sie unter Android 12 ausgeführt werden, unabhängig von targetSdkVersion. Sie sollten Ihre Anwendung testen und dann bei Bedarf so ändern, dass sie ordnungsgemäß unterstützt wird.

Sieh dir unbedingt auch die Liste der Änderungen des Verhaltens, die sich nur auf Apps auswirken, die auf Android 12 ausgerichtet sind an.

Nutzererfahrung

Overscroll-Effekt dehnen

Auf Geräten mit Android 12 und höher ändert sich das visuelle Verhalten für Overscroll-Ereignisse.

Unter Android 11 und niedriger sorgt ein Overscroll-Ereignis dafür, dass die visuellen Elemente leuchten. Unter Android 12 und höher werden die visuellen Elemente bei einem Drag-Ereignis gestreckt und zurückspringen, sodass sie bei einem FLing-Ereignis schleudern und zurückspringen.

Weitere Informationen findest du in der Anleitung zum Animieren von Scrollgesten.

App-Ladebildschirme

Wenn Sie bereits unter Android 11 oder niedriger einen benutzerdefinierten Ladebildschirm implementiert haben, müssen Sie Ihre App zur SplashScreen API migrieren, damit sie ab Android 12 korrekt angezeigt wird. Wenn Sie Ihre App nicht migrieren, führt dies zu einer verschlechterten oder unbeabsichtigten Einführung der App.

Eine Anleitung dazu findest du unter Vorhandene Implementierung des Ladebildschirms zu Android 12 migrieren.

Außerdem wird ab Android 12 bei allen Apps bei Kaltstart und Warmstart immer der neue Standard-Ladebildschirm des Android-Systems angewendet. Dieser Standardstartbildschirm des Systems wird standardmäßig aus dem Element des Launcher-Symbols Ihrer App und dem windowBackground Ihres Designs erstellt (falls es eine einfarbige Farbe ist).

Weitere Informationen finden Sie im Entwicklerleitfaden für Startbildschirme.

Web Intent-Auflösung

Ab Android 12 (API-Level 31) löst ein generischer Web-Intent nur dann eine Aktivität in Ihrer App auf, wenn Ihre App für die Domain genehmigt ist, die in diesem Web Intent enthalten ist. Wenn Ihre Anwendung nicht für die Domain genehmigt wird, wird der Web Intent stattdessen zur Standard-Browseranwendung des Nutzers aufgelöst.

Um diese Genehmigung zu erhalten, führen Sie einen der folgenden Schritte aus:

• Bestätigen Sie die Domain über Android-App-Links.

  Bei Apps, die auf Android 12 oder höher ausgerichtet sind, ändert das System die automatische Überprüfung der Android-App-Links Ihrer App. Achten Sie in den Intent-Filtern Ihrer App darauf, dass die Kategorie BROWSABLE enthalten ist und das Schema https unterstützt wird.

  Unter Android 12 oder höher können Sie die Android-App-Links Ihrer App manuell bestätigen, um zu testen, wie sich die aktualisierte Logik auf Ihre App auswirkt.

• Fordern Sie den Nutzer auf, Ihre Anwendung in den Systemeinstellungen mit der Domain zu verknüpfen.

Wenn Ihre App Web Intents aufruft, sollten Sie eine Aufforderung oder ein Dialogfeld hinzufügen, in dem der Nutzer aufgefordert wird, die Aktion zu bestätigen.

Verbesserungen des immersiven Modus für die Bedienung über Gesten

In Android 12 wird das vorhandene Verhalten konsolidiert, damit Nutzer Befehle der Gestensteuerung im immersiven Modus einfacher ausführen können. Darüber hinaus bietet Android 12 Abwärtskompatibilität für den fixierten immersiven Modus.

Display#getRealSize und getRealMetrics: Einstellung und Einschränkungen

Android-Geräte sind in vielen verschiedenen Formfaktoren erhältlich, z. B. große Bildschirme, Tablets und faltbare Smartphones. Damit Inhalte für jedes Gerät richtig gerendert werden können, muss deine App die Bildschirm- oder Displaygröße bestimmen. Im Laufe der Zeit hat Android verschiedene APIs zum Abrufen dieser Informationen bereitgestellt. In Android 11 haben wir die WindowMetrics API eingeführt und die folgenden Methoden eingestellt:

• Display.getSize()
• Display.getMetrics()

Für Android 12 empfehlen wir weiterhin die Verwendung von WindowMetrics und stellen folgende Methoden ein:

• Display.getRealSize()
• Display.getRealMetrics()

Android 12 schränkt bei Apps, deren Größe nicht vollständig geändert werden kann, die von den APIs zurückgegebenen Werte ein, um das Verhalten von Apps zu mindern, die Display APIs zum Abrufen der Anwendungsgrenzen verwenden. Dies könnte sich auf Apps auswirken, die diese Informationen mit MediaProjection verwenden.

Anwendungen sollten die WindowMetrics APIs verwenden, um die Grenzen ihres Fensters abzufragen, und Configuration.densityDpi, um die aktuelle Dichte abzufragen.

Für eine bessere Kompatibilität mit älteren Android-Versionen können Sie die Jetpack-Bibliothek WindowManager verwenden. Sie enthält eine WindowMetrics-Klasse, die Android 4.0 (API-Level 14) und höher unterstützt.

Beispiele für die Verwendung von WindowMetrics

Prüfen Sie zuerst, ob die Größe Ihrer App-Aktivitäten vollständig veränderbar ist.

Eine Aktivität sollte für UI-bezogene Aufgaben auf WindowMetrics aus einem Aktivitätskontext basieren, insbesondere auf WindowManager.getCurrentWindowMetrics() oder das WindowMetricsCalculator.computeCurrentWindowMetrics() von Jetpack.

Wenn Ihre Anwendung eine MediaProjection erstellt, müssen die Grenzen richtig groß sein, da die Projektion die Bildschirmpartition erfasst, in der die Projektoranwendung ausgeführt wird.

Wenn die Größe der Anwendung vollständig angepasst werden kann, gibt der Aktivitätskontext die korrekten Grenzen wie folgt zurück:

val projectionMetrics: WindowMetrics = activityContext
      .getSystemService(WindowManager::class.java).maximumWindowMetrics

WindowMetrics projectionMetrics = activityContext
      .getSystemService(WindowManager.class).getMaximumWindowMetrics();

Wenn die Größe der Anwendung nicht vollständig angepasst werden kann, muss sie von einer WindowContext-Instanz abfragen und den WindowMetrics der Aktivitätsgrenzen mithilfe von WindowManager.getMaximumWindowMetrics() oder der Jetpack-Methode WindowMetricsCalculator.computeMaximumWindowMetrics() abrufen.

val windowContext = context.createWindowContext(mContext.display!!,
      WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
      .maximumWindowMetrics

Context windowContext = context.createWindowContext(mContext.getDisplay(),
      WindowManager.LayoutParams.TYPE_APPLICATION, null);
WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class)
      .getMaximumWindowMetrics();

Alle Apps im Mehrfenstermodus

Unter Android 12 wird der Mehrfenstermodus standardmäßig verwendet.

Auf großen Bildschirmen (ab 600 dp) unterstützt die Plattform alle Apps im Mehrfenstermodus, unabhängig von der App-Konfiguration. Wenn resizeableActivity="false" festgelegt ist, wird die App bei Bedarf in den Kompatibilitätsmodus versetzt, um die Anzeigeabmessungen anzupassen.

Auf kleinen Bildschirmen (sw < 600 dp) prüft das System minWidth und minHeight einer Aktivität, um festzustellen, ob die Aktivität im Mehrfenstermodus ausgeführt werden kann. Wenn resizeableActivity="false" festgelegt ist, wird die Ausführung der App im Mehrfenstermodus unabhängig von der Mindestbreite und -höhe verhindert.

Weitere Informationen finden Sie unter Unterstützung des Mehrfenstermodus.

Kameravorschau auf großen Bildschirmen

Kamera-Apps gehen in der Regel von einer festen Beziehung zwischen der Ausrichtung des Geräts und dem Seitenverhältnis der Kameravorschau aus. Aber Faktoren wie faltbare Geräte und Anzeigemodi wie Mehrfenster- und Mehrfachdisplays stellen diese Annahme infrage.

Unter Android 12 wechseln Kamera-Apps, die eine bestimmte Bildschirmausrichtung anfordern und deren Größe nicht geändert werden kann (resizeableActivity="false"), automatisch in den integrierten Hochformat, wodurch die richtige Ausrichtung und das richtige Seitenverhältnis der Kameravorschau sichergestellt werden. Bei faltbaren Geräten und anderen Geräten mit einer Kamera-Hardware-Abstraktionsschicht (HAL) wird die Kameraausgabe zusätzlich gedreht, um die Ausrichtung des Kamerasensors auszugleichen. Die Ausgabe wird dann auf das Seitenverhältnis der Kameravorschau der App zugeschnitten. Das Zuschneiden und die zusätzliche Drehung sorgen für eine korrekte Darstellung der Kameravorschau unabhängig von der Geräteausrichtung und dem zugeklappten oder aufgeklappten Zustand des Geräts.

UX-Verzögerung für Benachrichtigungen zu Diensten im Vordergrund

Damit Dienste im Vordergrund kurzzeitig ausgeführt werden, kann auf Geräten, auf denen Android 12 oder höher ausgeführt wird, die Anzeige von Benachrichtigungen zu Diensten im Vordergrund mit wenigen Ausnahmen um 10 Sekunden verzögert werden. Durch diese Änderung können kurzlebige Aufgaben abgeschlossen werden, bevor die Benachrichtigungen angezeigt werden.

Leistung

Eingeschränkter App-Standby-Bucket

Unter Android 11 (API-Level 30) wurde der eingeschränkte Bucket als App-Standby-Bucket eingeführt. Ab Android 12 ist dieser Bucket standardmäßig aktiv. Der eingeschränkte Bucket hat die niedrigste Priorität (und die höchsten Einschränkungen) aller Buckets. Die nach Priorität geordneten Buckets sind:

1. Aktiv: Die App wird gerade oder erst vor Kurzem verwendet.
2. Arbeitssatz: App wird regelmäßig verwendet.
3. Häufig: Apps werden oft verwendet, aber nicht täglich.
4. Selten: Die App wird nicht häufig verwendet.
5. Eingeschränkt: Die Anwendung verbraucht viele Systemressourcen oder kann ein unerwünschtes Verhalten zeigen.

Das System berücksichtigt neben den Nutzungsmustern auch das Verhalten Ihrer Anwendung, um zu entscheiden, ob Ihre Anwendung in den eingeschränkten Bucket aufgenommen wird.

Es ist weniger wahrscheinlich, dass Ihre Anwendung in dem eingeschränkten Bucket abgelegt wird, wenn sie Systemressourcen verantwortungsvoller nutzt. Außerdem platziert das System Ihre Anwendung in einem weniger restriktiven Bucket, wenn der Nutzer direkt mit Ihrer Anwendung interagiert.

Prüfen, ob sich Ihre Anwendung im eingeschränkten Bucket befindet

Wenn Sie prüfen möchten, ob Ihre App vom System in den eingeschränkten Bucket aufgenommen wurde, rufen Sie getAppStandbyBucket() auf. Wenn der Rückgabewert dieser Methode STANDBY_BUCKET_RESTRICTED ist, befindet sich Ihre Anwendung im eingeschränkten Bucket.

Verhalten des eingeschränkten Buckets testen

Wenn Sie testen möchten, wie sich die Anwendung verhält, wenn das System Ihre Anwendung in den eingeschränkten Bucket platziert, können Sie die Anwendung manuell in diesen Bucket verschieben. Führen Sie dazu den folgenden Befehl in einem Terminalfenster aus:

adb shell am set-standby-bucket PACKAGE_NAME restricted

Sicherheit & Datenschutz

Ungefährer Standort

Auf Geräten mit Android 12 oder höher können Nutzer anfordern, dass Ihre App nur Zugriff auf Informationen zum ungefähren Standort hat.

Wenn Ihre App die Laufzeitberechtigung ACCESS_FINE_LOCATION anfordert, sollten Sie auch die Berechtigung ACCESS_COARSE_LOCATION anfordern, falls der Nutzer ungefähren Standortzugriff auf Ihre App gewährt. Nehmen Sie beide Berechtigungen in einer einzigen Laufzeitanfrage auf.

Das Dialogfeld für Systemberechtigungen enthält die folgenden Optionen für den Nutzer, wie in Abbildung 1 dargestellt:

• Genau: Bietet Zugriff auf genaue Standortinformationen.
• Annähernd: Bietet nur Zugriff auf ungefähre Standortinformationen.

Ein-/Aus-Schaltflächen für Mikrofon und Kamera

Auf unterstützten Geräten mit Android 12 oder höher können Nutzer den Kamera- und Mikrofonzugriff für alle Apps auf dem Gerät durch Drücken einer Ein/Aus-Schaltfläche aktivieren und deaktivieren. Nutzer können die Umschaltoptionen über die Schnelleinstellungen (siehe Abbildung 1) oder über den Datenschutzbildschirm in den Systemeinstellungen aufrufen.

Informieren Sie sich über diese Ein/Aus-Schaltfläche und darüber, wie Sie prüfen können, ob Ihre Anwendung den Best Practices zu den Berechtigungen CAMERA und RECORD_AUDIO entspricht.

Mikrofon- und Kameraanzeigen

Auf Geräten mit Android 12 oder höher wird in der Statusleiste ein Symbol angezeigt, wenn eine App auf das Mikrofon oder die Kamera zugreift.

Weitere Informationen zu diesen Indikatoren und dazu, wie Sie prüfen können, ob Ihre Anwendung den Best Practices zu den Berechtigungen CAMERA und RECORD_AUDIO entspricht.

Sichtbarkeit von Berechtigungspaketen

Auf Geräten mit Android 12 oder höher erhalten Apps, die auf Android 11 (API-Level 30) oder höher ausgerichtet sind und eine der folgenden Methoden aufrufen, basierend auf der Paketsichtbarkeit der App in anderen Apps einen gefilterten Satz von Ergebnissen:

• getAllPermissionGroups()
• getPermissionGroupInfo()
• getPermissionInfo()
• queryPermissionsByGroup()

BouncyCastle-Implementierung entfernt

Unter Android 12 wurden viele BouncyCastle-Implementierungen von kryptografischen Algorithmen entfernt, die zuvor verworfen wurden, einschließlich aller AES-Algorithmen. Das System verwendet stattdessen die Conscrypt-Implementierungen dieser Algorithmen.

Diese Änderung wirkt sich in folgenden Fällen auf Ihre App aus:

• Deine App verwendet 512-Bit-Schlüsselgrößen. Conscrypt unterstützt diese Schlüsselgröße nicht. Aktualisieren Sie bei Bedarf die Kryptografielogik Ihrer App, um unterschiedliche Schlüsselgrößen zu verwenden.

• Deine App verwendet ungültige Schlüsselgrößen mit KeyGenerator. Die KeyGenerator-Implementierung von Conscrypt führt im Vergleich zu BouncyCastle zusätzliche Validierungen für Schlüsselparameter durch. Conscrypt lässt beispielsweise nicht zu, dass Ihre Anwendung einen 64-Bit-AES-Schlüssel generiert, da AES nur Schlüssel mit 128, 192 und 256 Bit unterstützt.

  BouncyCastle ermöglicht das Generieren von Schlüsseln mit ungültiger Größe, schlägt jedoch später fehl, wenn diese Schlüssel mit einem Cipher verwendet werden. Conscrypt schlägt zuvor fehl.

• Sie initialisieren Ihre GCM-Chiffren (Galois/Counter Mode) mit einer anderen Größe als 12 Byte. Die GcmParameterSpec-Implementierung von Conscrypt erfordert eine Initialisierung von 12 Byte, die von NIST empfohlen wird.

Benachrichtigungen für den Zugriff auf die Zwischenablage

Wenn eine App unter Android 12 und höher zum ersten Mal getPrimaryClip() aufruft, um auf Clipdaten aus einer anderen App zuzugreifen, wird der Nutzer mit einem Toast über den Zugriff auf die Zwischenablage benachrichtigt.

Der Text in der Toast-Nachricht hat das folgende Format: APP pasted from your clipboard.

Informationen zu Text in Clipbeschreibungen

Unter Android 12 und höher kann getPrimaryClipDescription() die folgenden Details erkennen:

• Stilisierter Text mit isStyledText()
• Verschiedene Textklassifizierungen, z. B. URLs, mit getConfidenceScore().

Apps können Systemdialoge nicht schließen

Um die Nutzersteuerung bei der Interaktion mit Apps und dem System zu verbessern, wird die Intent-Aktion ACTION_CLOSE_SYSTEM_DIALOGS ab Android 12 eingestellt. Abgesehen von einigen Sonderfällen führt das System je nach SDK-Zielversion Ihrer App einen der folgenden Schritte aus, wenn Ihre App versucht, einen Intent aufzurufen, der diese Aktion enthält:

• Wenn Ihre App auf Android 12 oder höher ausgerichtet ist, wird ein SecurityException ausgelöst.

• Wenn Ihre App auf Android 11 (API-Level 30) oder niedriger ausgerichtet ist, wird der Intent nicht ausgeführt und die folgende Meldung wird in Logcat angezeigt:

  E ActivityTaskManager Permission Denial: \
  android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \
  com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \
  dropping broadcast.
  

Ausnahmen

In den folgenden Fällen kann eine App unter Android 12 oder höher weiterhin Systemdialogfelder schließen:

• Ihre Anwendung führt einen Instrumentierungstest aus.

• Ihre App ist auf Android 11 oder niedriger ausgerichtet und zeigt ein Fenster über der Benachrichtigungsleiste.

• Deine App ist auf Android 11 oder niedriger ausgerichtet. Darüber hinaus hat der Nutzer mit einer Benachrichtigung interagiert, möglicherweise über die Aktionsschaltflächen der Benachrichtigung, und Ihre Anwendung verarbeitet als Reaktion auf diese Nutzeraktion einen Dienst oder Broadcast-Empfänger.

• Ihre App ist auf Android 11 oder niedriger ausgerichtet und hat einen aktiven Dienst für Bedienungshilfen. Wenn deine App auf Android 12 ausgerichtet ist und die Benachrichtigungsleiste schließen soll, verwende stattdessen die Bedienungshilfen-Aktion GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE.

Nicht vertrauenswürdige Touch-Ereignisse werden blockiert

Um die Systemsicherheit und eine gute Nutzerfreundlichkeit zu gewährleisten, hindert Android 12 Apps daran, Touch-Ereignisse zu nutzen, bei denen die App durch ein Overlay unsicher verdeckt wird. Mit anderen Worten: Das System blockiert Berührungen, die sich durch bestimmte Fenster bewegen, mit wenigen Ausnahmen.

Betroffene Apps

Diese Änderung betrifft Apps, bei denen Berührungen durch ihre Fenster passieren dürfen, z. B. durch Verwendung des Flags FLAG_NOT_TOUCHABLE. Hier einige Beispiele:

• Overlays, für die die Berechtigung SYSTEM_ALERT_WINDOW erforderlich ist, z. B. Fenster, in denen TYPE_APPLICATION_OVERLAY verwendet wird und bei denen das Flag FLAG_NOT_TOUCHABLE verwendet wird
• Aktivitätsfenster, die das Flag FLAG_NOT_TOUCHABLE verwenden.

Ausnahmen

In den folgenden Fällen sind Pass-through-Berührungen zulässig:

• Interaktionen innerhalb Ihrer App: Das Overlay wird in Ihrer App angezeigt und nur dann eingeblendet, wenn der Nutzer mit Ihrer App interagiert.

• Vertrauenswürdige Fenster Zu diesen Zeitfenstern gehören unter anderem:

  • Fenster für Bedienungshilfen
  • Fenster für den Eingabemethoden-Editor (IME)
  • Assistant-Fenster

• Unsichtbare Fenster Die Stammansicht des Fensters ist GONE oder INVISIBLE.

• Völlig transparente Fenster. Das Attribut alpha hat für das Fenster den Wert 0.0.

• Ausreichend transparente Systembenachrichtigungsfenster. Das System stuft eine Reihe von Systembenachrichtigungsfenstern als ausreichend durchsichtig ein, wenn die kombinierte Deckkraft kleiner oder gleich der maximalen verdeckten Deckkraft für Berührungen des Systems ist. In Android 12 beträgt diese maximale Deckkraft standardmäßig 0, 8.

Erkennen, wenn eine nicht vertrauenswürdige Berührung blockiert wird

Wenn eine Berührungsaktion vom System blockiert wird, protokolliert Logcat die folgende Meldung:

Untrusted touch due to occlusion by PACKAGE_NAME

Änderung testen

Nicht vertrauenswürdige Berührungen werden auf Geräten mit Android 12 oder höher standardmäßig blockiert. Um nicht vertrauenswürdige Berührungen zuzulassen, führen Sie den folgenden ADB-Befehl in einem Terminalfenster aus:

# A specific app
adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
# If you'd still like to see a Logcat message warning when a touch would be
# blocked, use 1 instead of 0.
adb shell settings put global block_untrusted_touches 0

Führen Sie den folgenden Befehl aus, um das Verhalten auf die Standardeinstellung zurückzusetzen (vertrauenswürdige Berührungen werden blockiert):

# A specific app
adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
adb shell settings put global block_untrusted_touches 2

Aktivitätslebenszyklus

Root-Launcher-Aktivitäten sind beim Drücken der Rücktaste nicht mehr beendet

In Android 12 wird die Standardbehandlung für das Drücken der Taste „Zurück“ für Launcher-Aktivitäten geändert, die sich am Stamm der Aufgaben befinden. In früheren Versionen hat das System diese Aktivitäten beim Drücken der Rücktaste abgeschlossen. In Android 12 verschiebt das System die Aktivität und ihre Aufgabe jetzt in den Hintergrund, anstatt die Aktivität zu beenden. Das neue Verhalten entspricht dem aktuellen Verhalten beim Navigieren aus einer App über die Startbildschirmtaste oder Touch-Geste.

Für die meisten Anwendungen bedeutet diese Änderung, dass Nutzer, die zum Verlassen der Anwendung „Zurück“ verwenden, die Anwendung im warmen Zustand schneller fortsetzen können, anstatt sie vollständig aus einem kalten Zustand neu zu starten.

Wir empfehlen Ihnen, Ihre Apps mit dieser Änderung zu testen. Wenn Ihre App derzeit onBackPressed() überschreibt, um die Zurück-Navigation zu verarbeiten und die Activity abzuschließen, aktualisieren Sie Ihre Implementierung so, dass sie nicht den Vorgang abschließt, sondern an super.onBackPressed() aufruft. Durch den Aufruf von super.onBackPressed() werden die Aktivität und die zugehörige Aufgabe gegebenenfalls in den Hintergrund verschoben. So wird den Nutzern in allen Apps eine einheitlichere Navigation ermöglicht.

Außerdem empfehlen wir, zum Bereitstellen einer benutzerdefinierten Zurücknavigation die AndroidX Activity APIs zu verwenden, anstatt onBackPressed() zu überschreiben. Die AndroidX Activity APIs wenden sich automatisch an das entsprechende Systemverhalten an, wenn keine Komponenten die Rücktaste des Systems abfangen.

Grafiken und Bilder

Verbesserter Wechsel der Aktualisierungsrate

Bei Android 12 können Änderungen der Aktualisierungsrate mithilfe von setFrameRate() unabhängig davon auftreten, ob das Display einen nahtlosen Übergang zur neuen Aktualisierungsrate unterstützt. Ein nahtloser Übergang ist ein Vorgang, bei dem es keine visuellen Unterbrechungen gibt, z. B. ein schwarzer Bildschirm für ein oder zwei Sekunden. Wenn die Anzeige bisher keinen nahtlosen Übergang unterstützt hat, wird normalerweise weiterhin dieselbe Aktualisierungsrate verwendet, nachdem setFrameRate() aufgerufen wurde. Durch Aufrufen von getAlternativeRefreshRates() können Sie im Voraus bestimmen, ob der Übergang zur neuen Aktualisierung wahrscheinlich reibungslos verläuft. Im Allgemeinen wird der Callback onDisplayChanged() aufgerufen, nachdem die Aktualisierungsrate umgestellt wurde. Bei einigen extern verbundenen Displays wird er jedoch während eines nicht nahtlosen Übergangs aufgerufen.

Hier ein Beispiel für die Implementierung:

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
val refreshRates = this.display?.mode?.alternativeRefreshRates
val willBeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate)

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
Display display = context.getDisplay(); // API 30+
Display.Mode mode = display.getMode();
float[] refreshRates = mode.getAlternativeRefreshRates();
boolean willBeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate);

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);

Konnektivität

Passpoint-Updates

Die folgenden APIs wurden in Android 12 hinzugefügt:

• isPasspointTermsAndConditionsSupported(): Nutzungsbedingungen sind eine Passpoint-Funktion, mit der Netzwerkbereitstellungen unsichere Captive Portals, die offene Netzwerke verwenden, durch ein sicheres Passpoint-Netzwerk ersetzen können. Der Nutzer erhält eine Benachrichtigung, wenn die Nutzungsbedingungen akzeptiert werden müssen. Apps, die Passpoint-Netzwerke vorschlagen, die durch Nutzungsbedingungen geschützt sind, müssen zuerst diese API aufrufen, um sicherzustellen, dass das Gerät die Funktion unterstützt. Wenn das Gerät diese Funktion nicht unterstützt, kann keine Verbindung zu diesem Netzwerk hergestellt werden und es muss ein alternatives oder altes Netzwerk vorgeschlagen werden.

• isDecoratedIdentitySupported(): Bei der Authentifizierung bei Netzwerken mit Präfixdekoration können Netzwerkbetreiber mit dem dekorierten Identitätspräfix den Network Access Identifier (NAI) aktualisieren, um explizites Routing über mehrere Proxys innerhalb eines AAA-Netzwerks durchzuführen. Weitere Informationen dazu finden Sie unter RFC 7542.

  Unter Android 12 wird diese Funktion gemäß der WBA-Spezifikation für PPS-MO-Erweiterungen implementiert. Apps, die Passpoint-Netzwerke vorschlagen, die eine dekorierte Identität erfordern, müssen zuerst diese API aufrufen, um sicherzustellen, dass das Gerät die Funktion unterstützt. Wenn das Gerät diese Funktion nicht unterstützt, wird die Identität nicht dekoriert und die Authentifizierung beim Netzwerk kann fehlschlagen.

Zum Erstellen eines Passpoint-Vorschlags müssen Anwendungen die Klassen PasspointConfiguration, Credential und HomeSp verwenden. Diese Klassen beschreiben das Passpoint-Profil, das in der Passpoint-Spezifikation der Wi-Fi Alliance definiert ist.

Weitere Informationen finden Sie unter Wi-Fi Suggest API für Internetverbindung.

Aktualisierte Nicht-SDK-Schnittstelleneinschränkungen

Android 12 enthält aktualisierte Listen eingeschränkter Nicht-SDK-Schnittstellen, die auf der Zusammenarbeit mit Android-Entwicklern und den neuesten internen Tests basieren. Wann immer möglich, achten wir darauf, dass öffentliche Alternativen verfügbar sind, bevor wir Nicht-SDK-Schnittstellen einschränken.

Wenn deine App nicht auf Android 12 ausgerichtet ist, betreffen dich einige dieser Änderungen möglicherweise nicht sofort. Sie können derzeit zwar einige Nicht-SDK-Schnittstellen verwenden (abhängig vom Ziel-API-Level Ihrer App), aber die Verwendung von Nicht-SDK-Methoden oder -Feldern birgt immer ein hohes Risiko für Probleme mit Ihrer App.

Wenn Sie sich nicht sicher sind, ob Ihre Anwendung Nicht-SDK-Schnittstellen verwendet, können Sie die Anwendung testen. Wenn Ihre App Nicht-SDK-Schnittstellen verwendet, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Trotzdem können einige Apps für die Verwendung von Nicht-SDK-Schnittstellen infrage kommen. Wenn Sie für eine Funktion in Ihrer App keine Alternative zur Verwendung einer Nicht-SDK-Schnittstelle finden, sollten Sie eine neue öffentliche API anfordern.

Weitere Informationen zu den Änderungen in diesem Android-Release finden Sie unter Aktualisierungen der Einschränkungen für Nicht-SDK-Schnittstellen in Android 12. Weitere Informationen zu Nicht-SDK-Schnittstellen im Allgemeinen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen.