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 unter Android 12 ausgeführt werden, unabhängig von targetSdkVersion. Du solltest deine Anwendung testen und dann bei Bedarf anpassen, damit sie korrekt unterstützt werden.

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 für Overscroll-Ereignisse.

Unter Android 11 und niedrigerer Version werden visuelle Elemente bei einem Überscroll-Ereignis ausgeleuchtet. Unter Android 12 und höher werden sie bei einem Drag-Ereignis gedehnt und zurückgesprungen und bei einem Fling-Ereignis nach vorne geschleudert und zurückgesprungen.

Weitere Informationen finden Sie im Leitfaden zum Animieren von Wischgesten.

App-Startbildschirme

Wenn du in Android 11 oder niedriger zuvor einen benutzerdefinierten Ladebildschirm implementiert hast, musst du deine App zur SplashScreen API migrieren, damit sie ab Android 12 korrekt angezeigt wird. Wenn Sie Ihre Anwendung nicht migrieren, wird der App-Start beeinträchtigt oder unbeabsichtigt gestartet.

Eine Anleitung finden Sie unter Vorhandene Startbildschirmimplementierung zu Android 12 migrieren.

Außerdem wendet das System ab Android 12 bei Kaltstarts und Warmstarts bei allen Apps immer den neuen Standard-Ladebildschirm des Android-Systems an. 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 Startbildschirme.

Web Intent-Auflösung

Ab Android 12 (API-Level 31) wird ein allgemeiner 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 App nicht für die Domain genehmigt ist, wird der Web-Intent stattdessen an die Standardbrowser-App des Nutzers weitergeleitet.

Apps können diese Genehmigung erhalten, indem Sie einen der folgenden Schritte ausführen:

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

Verbesserungen beim immersiven Modus für die Bedienung per Geste

Android 12 konsolidiert das vorhandene Verhalten, damit Nutzer Befehle für die Bedienung über Gesten im immersiven Modus einfacher ausführen können. Außerdem bietet Android 12 Abwärtskompatibilität für den fixierten Modus.

Display#getRealSize und getRealMetrics: Einstellung und Einschränkungen

Android-Geräte sind in vielen verschiedenen Formfaktoren erhältlich, z. B. mit großen Bildschirmen, Tablets und faltbaren Geräten. Damit Inhalte für jedes Gerät richtig gerendert werden, muss deine App die Bildschirm- oder Anzeigegröße ermitteln. Im Laufe der Zeit stellt Android verschiedene APIs zum Abrufen dieser Informationen zur Verfügung. Mit Android 11 haben wir die WindowMetrics API eingeführt und die folgenden Methoden eingestellt:

Unter Android 12 empfehlen wir weiterhin die Verwendung von WindowMetrics. Die folgenden Methoden werden eingestellt:

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.

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

Für eine umfassendere 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

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

Eine Aktivität sollte für alle UI-bezogenen Aufgaben auf WindowMetrics aus einem Aktivitätskontext basieren, insbesondere für 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 Größe der Anwendung vollständig angepasst werden kann, gibt der Aktivitätskontext die richtigen Grenzen zurück. Beispiel:

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. Wenn resizeableActivity="false", wird die App bei Bedarf in den Kompatibilitätsmodus versetzt, um die Displayabmessungen zu berücksichtigen.

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 für mehrere Fenster.

Kameravorschau auf großen Bildschirmen

Kamera-Apps gehen im Allgemeinen von einer festen Beziehung zwischen der Ausrichtung des Geräts und dem Seitenverhältnis der Kameravorschau aus. Allerdings stellen große Bildschirmformfaktoren wie faltbare Geräte und Anzeigemodi wie Mehrfenstermodus und Mehrfachdisplay 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. Auf faltbaren Geräten und anderen Geräten mit Kamerahardware-Abstraktionsschicht (HAL) wird die Kameraausgabe zusätzlich gedreht, um die Ausrichtung des Kamerasensors auszugleichen. Die Ausgabe der Kamera wird 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 von Diensten im Vordergrund mit kurzer Laufzeit zu optimieren, können Geräte mit Android 12 oder höher die Anzeige von Benachrichtigungen zu Diensten im Vordergrund um 10 Sekunden verzögern. Es gibt allerdings einige Ausnahmen. 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 von allen Buckets die niedrigste Priorität (und die höchsten Einschränkungen). Die Bucket-Kategorien in absteigender Priorität:

  1. Aktiv: Die App wird gerade verwendet oder wurde vor Kurzem verwendet.
  2. Arbeitsumgebung: 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 Anwendung verbraucht große Systemressourcen oder kann unerwünschtes Verhalten aufweisen.

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.

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

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

Rufen Sie getAppStandbyBucket() auf, um zu prüfen, ob das System Ihre Anwendung im eingeschränkten Bucket platziert hat. Wenn der Rückgabewert dieser Methode STANDBY_BUCKET_RESTRICTED ist, befindet sich Ihre App im eingeschränkten Bucket.

Verhalten des eingeschränkten Buckets 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, eine übereinander
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 deine App nur Zugriff auf ungefähre Standortinformationen hat.

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 Zugriff auf den ungefähren Standort gewährt. Sie sollten beide Berechtigungen in einer einzelnen Laufzeitanfrage angeben.

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

  • Genau: Mit dieser Option können Sie auf genaue Standortinformationen zugreifen.
  • Ungefähr: Gewährt 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 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 ein-/ausschaltbaren Optionen über die Schnelleinstellungen (siehe Abbildung 1) oder über den Datenschutzbildschirm in den Systemeinstellungen aufrufen.

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

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 Anwendung den Best Practices für die Berechtigungen CAMERA und RECORD_AUDIO entspricht.

Die Kacheln für Schnelleinstellungen sind mit „Kamerazugriff“ und „Mikrofonzugriff“ beschriftet
Abbildung 2: Mikrofon- und Kameraschalter in den Schnelleinstellungen
Ein abgerundetes Rechteck in der oberen rechten Ecke, das ein Kamera- und ein Mikrofonsymbol enthält
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, eine gefilterte Ergebnismenge, die auf der Sichtbarkeit des Pakets der App in anderen Apps basiert:

BouncyCastle-Implementierung entfernt

Unter Android 12 werden viele BouncyCastle-Implementierungen von kryptografischen Algorithmen entfernt, die zuvor verworfen 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:

  • 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.

  • Ihre 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. Conscrypt erlaubt Ihrer Anwendung beispielsweise nicht, einen 64-Bit-AES-Schlüssel zu 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

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 über eine Toast-Nachricht über den Zugriff auf die Zwischenablage informiert.

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. 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 mit dieser Aktion aufzurufen:

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

  • 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 Systemdialoge unter Android 12 oder höher weiterhin schließen:

  • In Ihrer Anwendung wird ein Instrumentierungstest ausgeführt.

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

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

  • Ihre App ist auf Android 11 oder niedriger ausgerichtet und hat einen aktiven Bedienungshilfendienst. Wenn deine App auf Android 12 ausgerichtet ist und die Benachrichtigungsleiste schließen möchte, verwende stattdessen die Bedienungshilfe GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE.

Nicht vertrauenswürdige Touch-Events werden blockiert

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

Betroffene Apps

Diese Änderung betrifft Apps, die festlegen, dass Berührungen durch ihre Fenster weitergegeben werden können, z. B. mithilfe des Flags FLAG_NOT_TOUCHABLE. Hier einige 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, die das Flag FLAG_NOT_TOUCHABLE verwenden.

Ausnahmen

In den folgenden Fällen sind Berührungen mit dem Status „Durchleitung“ 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 Das Attribut 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

Führen Sie den folgenden Befehl aus, um das Verhalten auf die Standardeinstellung zurückzusetzen (nicht 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

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 Anwendungen bedeutet diese Änderung, dass Nutzer, die die Anwendung über „Zurück“ verlassen, um sie schneller aus einem Warmzustand fortsetzen zu können, anstatt sie vollständig 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.

Außerdem empfehlen wir im Allgemeinen, die AndroidX Activity APIs zu verwenden, wenn Sie eine benutzerdefinierte Zurück-Navigation bereitstellen möchten, 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

Verbesserter Wechsel der Aktualisierungsrate

In Android 12 kann es zu Änderungen der Aktualisierungsrate mit setFrameRate() kommen, unabhängig davon, ob das Display einen nahtlosen Übergang zur neuen Aktualisierungsrate unterstützt. Ein nahtloser Übergang ist ein Übergang, der keine visuellen Unterbrechungen aufweist, z. B. ein schwarzer Bildschirm für ein oder zwei Sekunden. Wenn das Display zuvor keinen nahtlosen Übergang unterstützte, wurde nach dem Aufruf von setFrameRate() in der Regel weiterhin dieselbe Bildwiederholrate verwendet. Mit getAlternativeRefreshRates() können Sie im Voraus feststellen, ob der Übergang zur neuen Aktualisierung wahrscheinlich nahtlos verläuft. Im Allgemeinen wird der Callback onDisplayChanged() nach Abschluss der Umstellung der Aktualisierungsrate aufgerufen. Bei einigen extern verbundenen Displays wird er jedoch während eines nicht nahtlosen Übergangs aufgerufen.

Hier ist ein Beispiel dafür:

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 diese Funktion nicht unterstützt, kann es keine Verbindung zu diesem Netzwerk herstellen. In diesem Fall muss ein alternatives oder Legacy-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 diese Funktion nicht unterstützt, wird die Identität nicht dekoriert und die Authentifizierung beim 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-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 benötigt, sollten Sie eine Migration zu SDK-Alternativen planen. Uns ist aber bewusst, dass es bei einigen Apps gültige Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen gibt. Wenn Sie für ein Feature 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 Updates für Nicht-SDK-Schnittstelleneinschränkungen in Android 12. Weitere Informationen zu Nicht-SDK-Schnittstellen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen.