Verhaltensänderungen: alle Apps

Die Android 12-Plattform enthält Verhaltensänderungen, die sich auf Ihre App auswirken können. Die folgenden Verhaltensänderungen gelten für alle Apps, die auf Android 12 ausgeführt werden, unabhängig von targetSdkVersion. Sie sollten Ihre App testen und sie gegebenenfalls so anpassen, dass sie diese Funktionen unterstützt.

Sieh dir auch die Liste der Verhaltensänderungen an, die nur Apps betreffen, die auf Android 12 ausgerichtet sind.

Nutzererfahrung

Stretch-Effekt beim Überscrollen

Auf Geräten mit Android 12 und höher ändert sich das visuelle Verhalten bei Overscroll-Ereignissen.

Unter Android 11 und niedriger sorgt ein Overscroll-Ereignis dafür, dass die visuellen Elemente ein Leuchten erscheinen. Bei Android 12 und höher werden die visuellen Elemente gestreckt und von einem Drag-Ereignis zurückgeprallt.

Weitere Informationen finden Sie im Leitfaden zum Animieren von Wischgesten.

App-Startbildschirme

Wenn Sie bereits einen benutzerdefinierten Ladebildschirm für Android 11 oder niedriger 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, kann das zu einer Beeinträchtigung oder zu unbeabsichtigten Problemen beim Starten der App führen.

Eine Anleitung dazu findest du unter Bestehende Implementierung für den Ladebildschirm zu Android 12 migrieren.

Außerdem wird ab Android 12 der neue Standard-Startbildschirm des Android-Systems bei Kaltstarts und Warmstarts für alle Apps verwendet. Standardmäßig wird dieser System-Startbildschirm mit dem Launcher-Symbolelement Ihrer App und der windowBackground Ihres Designs erstellt (sofern es eine einfarbige Farbe hat).

Weitere Informationen finden Sie im Entwicklerleitfaden für Splashscreens.

Web-Intent-Auflösung

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

Apps können diese Genehmigung auf eine der folgenden Arten erhalten:

Wenn Ihre App Web-Intents aufruft, sollten Sie einen Prompt oder ein Dialogfeld hinzufügen, in dem der Nutzer die Aktion bestätigen muss.

Verbesserungen beim immersiven Modus für die Bedienung per Geste

In Android 12 wird das bisherige Verhalten konsolidiert, damit Nutzer Gestenbefehle im Vollbildmodus leichter ausführen können. Außerdem 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 verfügbar, z. B. große Bildschirme, Tablets und faltbare Geräte. Damit Inhalte für jedes Gerät richtig gerendert werden können, muss Ihre App die Bildschirm- oder Displaygröße ermitteln. Im Laufe der Zeit hat Android verschiedene APIs zum Abrufen dieser Informationen bereitgestellt. In Android 11 haben wir die WindowMetrics API eingeführt und diese Methoden eingestellt:

In Android 12 empfehlen wir weiterhin die Verwendung von WindowMetrics und stellen die folgenden Methoden ein:

Um das Verhalten von Apps zu mildern, die Display-APIs zum Abrufen der Begrenzungen der App verwenden, werden in Android 12 die von den APIs zurückgegebenen Werte für Apps eingeschränkt, die nicht vollständig skalierbar sind. Dies kann sich auf Apps auswirken, die diese Informationen mit MediaProjection verwenden.

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

Für eine größere 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-Ebene 14) und höher unterstützt.

Beispiele für die Verwendung von WindowMetrics

Achten Sie zuerst darauf, dass die Aktivitäten Ihrer App vollständig skalierbar sind.

Für alle UI-bezogenen Arbeiten sollte eine Aktivität auf WindowMetrics aus einem Aktivitätskontext zurückgreifen, insbesondere auf WindowManager.getCurrentWindowMetrics() oder WindowMetricsCalculator.computeCurrentWindowMetrics() von Jetpack.

Wenn Ihre App eine MediaProjection erstellt, müssen die Begrenzungen die richtige Größe haben, da die Projektion die Displaypartition erfasst, in der die Projektor-App ausgeführt wird.

Wenn die App vollständig skalierbar ist, gibt der Aktivitätskontext die richtigen Ränder zurück:

Kotlin

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

Java

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

Wenn die App nicht vollständig skalierbar ist, muss sie eine WindowContext-Instanz abfragen und die WindowMetrics der Aktivitätsgrenzen mit WindowManager.getMaximumWindowMetrics() oder der Jetpack-Methode WindowMetricsCalculator.computeMaximumWindowMetrics() abrufen.

Kotlin

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

Java

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 ist der Mehrfenstermodus standardmäßig aktiviert.

Auf großen Bildschirmen (sw >= 600 dp) unterstützt die Plattform alle Apps unabhängig von der App-Konfiguration im Multifenstermodus. Bei resizeableActivity="false" wird die App bei Bedarf in den Kompatibilitätsmodus versetzt, um die Displayabmessungen anzupassen.

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

Weitere Informationen finden Sie unter Unterstützung des Mehrfenstermodus.

Kameravorschau auf großen Bildschirmen

Kamera-Apps gehen in der Regel von einem festen Verhältnis zwischen der Ausrichtung des Geräts und dem Seitenverhältnis der Kameravorschau aus. Aber Formfaktoren mit großen Displays wie faltbare Geräte und Displaymodi wie Multifenster- und Multidisplay stellen diese Annahme infrage.

Unter Android 12 wechseln Kamera-Apps, die eine bestimmte Bildschirmausrichtung anfordern und nicht skalierbar sind (resizeableActivity="false"), automatisch in den eingeblendeten Porträtmodus. Dadurch wird die richtige Ausrichtung und das richtige Seitenverhältnis der Kameravorschau sichergestellt. 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 zu kompensieren. Außerdem wird die Kameraausgabe so zugeschnitten, dass sie dem Seitenverhältnis der Kameravorschau der App entspricht. Durch das Zuschneiden und die zusätzliche Drehung wird die korrekte Darstellung der Kameravorschau unabhängig von der Geräteausrichtung und dem auf- oder zugeklappten Zustand des Geräts sichergestellt.

UX-Verzögerung bei Benachrichtigungen für Dienste im Vordergrund

Um die Nutzung kurz laufender Dienste im Vordergrund zu optimieren, kann auf Geräten mit Android 12 oder höher die Anzeige von Benachrichtigungen für Dienste im Vordergrund mit einigen Ausnahmen um 10 Sekunden verzögert werden. Durch diese Änderung haben Sie die Möglichkeit, kurzlebige Aufgaben abzuschließen, bevor die zugehörigen Benachrichtigungen angezeigt werden.

Leistung

Bucket für Apps im Standby-Modus mit eingeschränktem Zugriff

Mit 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 Bucket-Kategorien in absteigender Priorität:

  1. Aktiv: Die App wird gerade verwendet oder wurde vor Kurzem verwendet.
  2. Arbeitssatz: Die App wird regelmäßig verwendet.
  3. Häufig: Die App wird oft, aber nicht jeden Tag verwendet.
  4. Selten: Die App wird nicht häufig verwendet.
  5. Eingeschränkt: Die App verbraucht viele Systemressourcen oder weist unerwünschtes Verhalten auf.

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

Die Wahrscheinlichkeit, dass Ihre App in den eingeschränkten Bucket verschoben wird, ist geringer, wenn Sie die Systemressourcen Ihrer App verantwortungsvoller nutzen. Außerdem wird Ihre App in einen weniger restriktiven Bucket verschoben, wenn der Nutzer direkt mit Ihrer App interagiert.

Prüfen, ob Ihre App im eingeschränkten Bereich ist

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

Verhalten von Bucket mit eingeschränktem Zugriff testen

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

adb shell am set-standby-bucket PACKAGE_NAME restricted

Sicherheit und Datenschutz

Ungefährer Standort

Das Dialogfeld enthält zwei Optionen, die übereinander angeordnet sind.
Abbildung 1: Dialogfeld für Systemberechtigungen, über das der Nutzer den ungefähren Standort angeben kann.

Auf Geräten mit Android 12 oder höher können Nutzer anfordern, dass Ihre App nur auf ungefähre Standortinformationen zugreifen darf.

Wenn Ihre App die Laufzeitberechtigung ACCESS_FINE_LOCATION anfordert, sollten Sie auch die Berechtigung ACCESS_COARSE_LOCATION anfordern, um den Fall zu behandeln, dass der Nutzer Ihrer App den Zugriff auf den ungefähren Standort gewährt. Sie sollten beide Berechtigungen in einer einzigen Laufzeitanfrage angeben.

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

  • Genau: Bietet Zugriff auf genaue Standortinformationen.
  • Ungefähr: Mit dieser Option wird nur auf den ungefähren Standort zugegriffen.

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

Auf unterstützten Geräten mit Android 12 oder höher können Nutzer den Zugriff auf Kamera und Mikrofon für alle Apps auf dem Gerät mit nur einer einzigen Ein-/Aus-Schaltfläche aktivieren und deaktivieren. Nutzer können die Optionen zum Ein- und Ausschalten wie in Abbildung 1 gezeigt über die Schnelleinstellungen oder über den Datenschutzbildschirm in den Systemeinstellungen aufrufen.

Weitere Informationen zu diesen Schaltern und dazu, wie Sie prüfen können, ob Ihre App die Best Practices für die Berechtigungen CAMERA und RECORD_AUDIO einhält, finden Sie hier.

Mikrofon- und Kameraanzeigen

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

Weitere Informationen zu diesen Indikatoren und dazu, wie Sie prüfen können, ob Ihre App die Best Practices für die Berechtigungen CAMERA und RECORD_AUDIO einhält

Die Kacheln in den Schnelleinstellungen sind mit „Kamerazugriff“ und „Mikrofonzugriff“ gekennzeichnet.
Abbildung 2: Mikrofon- und Kameraschalter in den Schnelleinstellungen
Ein abgerundetes Rechteck oben rechts mit einem Kamera- und einem Mikrofonsymbol
Abbildung 3 Mikrofon- und Kameraanzeigen, die den letzten Datenzugriff anzeigen.

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, einen gefilterten Satz von Ergebnissen, abhängig von der Paketsichtbarkeit der App in anderen Apps:

BouncyCastle-Implementierung entfernt

In Android 12 wurden viele BouncyCastle-Implementierungen von kryptografischen Algorithmen entfernt, die zuvor eingestellt wurden, einschließlich aller AES-Algorithmen. Stattdessen verwendet das System die Conscrypt-Implementierungen dieser Algorithmen.

Diese Änderung wirkt sich auf Ihre App aus, wenn eine der folgenden Bedingungen zutrifft:

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

  • Deine App verwendet ungültige Schlüsselgrößen mit KeyGenerator. Die Implementierung von KeyGenerator in Conscrypt führt im Vergleich zu BouncyCastle eine zusätzliche Validierung der Schlüsselparameter durch. Mit Conscrypt kann Ihre App beispielsweise keinen 64-Bit-AES-Schlüssel generieren, da AES nur 128-, 192- und 256-Bit-Schlüssel unterstützt.

    BouncyCastle ermöglicht das Generieren von Schlüsseln mit ungültigen Größen, schlägt aber später fehl, wenn diese Schlüssel mit einem Cipher verwendet werden. Conscrypt schlägt früher fehl.

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

Benachrichtigungen zum Zugriff auf die Zwischenablage

Unter Android 12 und höher wird der Nutzer über eine Toast-Mitteilung über den Zugriff auf die Zwischenablage informiert, wenn eine App zum ersten Mal getPrimaryClip() aufruft, um auf Zwischenablagedaten aus einer anderen App zuzugreifen.

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

Informationen zum Text in der Clipbeschreibung

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

Apps können keine Systemdialogfelder 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. Außer in einigen Sonderfällen führt das System, wenn Ihre App versucht, einen Intent aufzurufen, der diese Aktion enthält, je nach Ziel-SDK-Version Ihrer App einen der folgenden Schritte aus:

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

  • Wenn Ihre App auf Android 11 (API-Level 30) oder niedriger ausgerichtet ist, wird die 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 Systemdialoge schließen:

  • In Ihrer Anwendung wird ein Instrumentierungstest ausgeführt.

  • Ihre App ist auf Android 11 oder niedriger ausgerichtet und zeigt ein Fenster an, das über dem Benachrichtigungs-Schieberegler liegt.

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

  • Ihre App ist auf Android 11 oder niedriger ausgerichtet und hat einen aktiven Bedienungshilfendienst. Wenn Ihre App auf Android 12 ausgerichtet ist und die Benachrichtigungsleiste geschlossen werden soll, verwenden Sie stattdessen die Aktion für Barrierefreiheit GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE.

Nicht vertrauenswürdige Touch-Ereignisse werden blockiert

Um die Systemsicherheit und eine gute Nutzererfahrung zu gewährleisten, verhindert Android 12, dass Apps Touch-Ereignisse verbrauchen, wenn ein Overlay die App auf unsichere Weise verdeckt. Mit anderen Worten: Das System blockiert Touch-Gesten, die bestimmte Fenster passieren, mit einigen Ausnahmen.

Betroffene Apps

Diese Änderung betrifft Apps, die Berührungen durch ihre Fenster hindurchlassen, z. B. durch Verwendung des Flags FLAG_NOT_TOUCHABLE. Beispiele:

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

Ausnahmen

In den folgenden Fällen sind „Durchlauf“-Berührungen zulässig:

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

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

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

  • Vollständig transparente Fenster: Die Property alpha hat für das Fenster den Wert „0,0“.

  • Ausreichend durchscheinende Systembenachrichtigungsfenster Das System erachtet eine Reihe von Systembenachrichtigungsfenstern als ausreichend durchscheinend, wenn die kombinierte Deckkraft kleiner oder gleich der maximalen Deckkraft des Systems für Berührungen 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 Touch-Aktion vom System blockiert wird, wird in Logcat die folgende Meldung protokolliert:

Untrusted touch due to occlusion by PACKAGE_NAME

Änderung testen

Auf Geräten mit Android 12 oder höher werden nicht vertrauenswürdige Berührungen standardmäßig blockiert. Wenn Sie nicht vertrauenswürdige Touch-Gesten zulassen möchten, führen Sie in einem Terminalfenster den folgenden ADB-Befehl 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

Wenn Sie das Verhalten auf die Standardeinstellung zurücksetzen möchten (nicht vertrauenswürdige Berührungen werden blockiert), führen Sie den folgenden Befehl aus:

# 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

Aktivitäten des Root-Launchers werden nicht mehr durch Drücken der Rücktaste beendet

Mit Android 12 wird die Standardbehandlung der Systemaktivitäten geändert, bei denen die Zurückdrücke auf Launcher ausgeführt werden, die den Aufgaben des Systems zugrunde liegen. In früheren Versionen beendete das System diese Aktivitäten beim Drücken der Taste „Backdrück“. Unter Android 12 verschiebt das System die Aktivität und ihre Aufgabe jetzt in den Hintergrund, anstatt sie zu beenden. Das neue Verhalten entspricht dem aktuellen Verhalten, wenn Sie eine App über die Startbildschirmtaste oder eine Geste verlassen.

Für die meisten Apps bedeutet diese Änderung, dass Nutzer, die die Schaltfläche „Zurück“ verwenden, um die App zu verlassen, die App schneller aus einem warmen Zustand fortsetzen können, anstatt sie aus einem kalten Zustand neu starten zu müssen.

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 zu beenden, aktualisieren Sie Ihre Implementierung, damit super.onBackPressed() aufgerufen wird, anstatt die Activity zu beenden. Durch das Aufrufen von super.onBackPressed() werden die Aktivität und die zugehörige Aufgabe gegebenenfalls in den Hintergrund verschoben. Dadurch wird eine einheitlichere Navigation für die Nutzer zwischen Apps ermöglicht.

Beachten Sie außerdem, dass wir im Allgemeinen empfehlen, die AndroidX Activity APIs für die Bereitstellung benutzerdefinierter Rücknavigation zu verwenden, anstatt onBackPressed() zu überschreiben. Die AndroidX Activity APIs übergeben das System automatisch an das entsprechende Systemverhalten, wenn keine Komponenten die rückwärtige Taste des Systems abfangen.

Grafiken und Bilder

Verbessertes Wechseln der Aktualisierungsrate

Unter Android 12 können Änderungen der Bildwiederholrate mit setFrameRate() erfolgen, unabhängig davon, ob das Display einen nahtlosen Übergang zur neuen Bildwiederholrate unterstützt. Ein nahtloser Übergang ist ein Übergang ohne visuelle Unterbrechungen, z. B. ein schwarzer Bildschirm für ein bis zwei Sekunden. Wenn das Display bisher keinen nahtlosen Übergang unterstützt, wurde nach dem Aufruf von setFrameRate() normalerweise weiterhin die gleiche Aktualisierungsrate verwendet. Mit getAlternativeRefreshRates() können Sie im Voraus feststellen, ob der Übergang zur neuen Aktualisierung wahrscheinlich nahtlos verläuft. Normalerweise wird der Rückruf onDisplayChanged() nach Abschluss der Umstellung der Bildwiederholrate aufgerufen. Bei einigen extern angeschlossenen Displays wird er jedoch während einer nicht nahtlosen Umstellung aufgerufen.

Hier ist ein Beispiel, wie Sie dies implementieren können:

Kotlin

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

Java

// 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

In Android 12 werden die folgenden APIs hinzugefügt:

  • isPasspointTermsAndConditionsSupported(): Nutzungsbedingungen ist eine Passpoint-Funktion, mit der bei Netzwerkbereitstellungen unsichere Captive Portals, die offene Netzwerke verwenden, durch ein sicheres Passpoint-Netzwerk ersetzt werden können. Wenn Nutzungsbedingungen akzeptiert werden müssen, wird dem Nutzer eine Benachrichtigung angezeigt. Apps, die Passpoint-Netzwerke vorschlagen, die durch Nutzungsbedingungen eingeschränkt sind, müssen zuerst diese API aufrufen, um sicherzustellen, dass das Gerät die Funktion unterstützt. Wenn das Gerät die Funktion nicht unterstützt, kann es keine Verbindung zu diesem Netzwerk herstellen. Es muss dann ein alternatives oder älteres Netzwerk vorgeschlagen werden.

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

    In Android 12 wird diese Funktion implementiert, um der WBA-Spezifikation für PPS-MO-Erweiterungen zu entsprechen. Apps, die Passpoint-Netzwerke vorschlagen, für die eine dekorierte Identität erforderlich ist, müssen zuerst diese API aufrufen, um sicherzustellen, dass das Gerät die Funktion unterstützt. Wenn das Gerät die Funktion nicht unterstützt, wird die Identität nicht dekoriert und die Authentifizierung im Netzwerk schlägt möglicherweise fehl.

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 Suggestion API für Internetverbindungen.

Aktualisierte Einschränkungen für Nicht-SDK-Schnittstellen

Android 12 enthält aktualisierte Listen eingeschränkter nicht SDK-basierter Schnittstellen, die auf der Zusammenarbeit mit Android-Entwicklern und den neuesten internen Tests basieren. Wir sorgen nach Möglichkeit dafür, dass öffentliche Alternativen verfügbar sind, bevor wir Nicht-SDK-Schnittstellen einschränken.

Wenn Ihre App nicht auf Android 12 ausgerichtet ist, wirken sich einige dieser Änderungen möglicherweise nicht sofort auf Sie aus. Sie können zwar derzeit einige Nicht-SDK-Schnittstellen verwenden (je nach Ziel-API-Level Ihrer App), aber bei Verwendung von Nicht-SDK-Methoden und -Feldern besteht immer ein hohes Risiko, dass Ihre App nicht mehr funktioniert.

Wenn du nicht sicher bist, ob deine App Nicht-SDK-Schnittstellen verwendet, kannst du die App testen, um es herauszufinden. Wenn Ihre App Nicht-SDK-Schnittstellen verwendet, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Uns ist jedoch bewusst, dass es für einige Apps gültige Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen gibt. Wenn Sie keine Alternative zur Verwendung einer Nicht-SDK-Benutzeroberfläche für eine Funktion in Ihrer App finden, sollten Sie eine neue öffentliche API anfordern.

Weitere Informationen zu den Änderungen in dieser Android-Version finden Sie unter Änderungen an den Einschränkungen für Nicht-SDK-Schnittstellen in Android 12. Weitere Informationen zu Nicht-SDK-Schnittstellen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen.