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

Overscroll-Effekt strecken

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 ein Leuchten erscheinen. Unter Android 12 und höher werden die visuellen Elemente gestreckt und von einem Drag-Ereignis zurückgeprallt.

Weitere Informationen finden Sie in der Anleitung zum Animieren von Scroll-Gesten.

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 dazu findest du unter Bestehende Implementierung für den Ladebildschirm 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 der Ladebildschirm des Systems aus dem Launcher-Symbolelement Ihrer App und dem windowBackground Ihres Designs (wenn es eine Farbe ist) verwendet.

Weitere Informationen finden Sie im Entwicklerleitfaden für Startbildschirme.

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 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 im immersiven Modus für die Bedienung über Gesten

In Android 12 wird das vorhandene Verhalten konsolidiert, damit Nutzer im immersiven Modus Befehle zur Bedienung über Gesten 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 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 deine App die Bildschirm- oder Anzeigegröße ermitteln. Im Laufe der Zeit stellt Android verschiedene APIs zum Abrufen dieser Informationen zur Verfügung. 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 Anwendungen zu verringern, die Display-APIs zum Abrufen der Anwendungsgrenzen verwenden, schränkt Android 12 die von den APIs zurückgegebenen Werte für Anwendungen ein, deren Größe nicht vollständig angepasst werden kann. 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

Prüfen Sie zuerst, ob die Größe der Aktivitäten in Ihrer App vollständig angepasst werden kann.

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 Anwendung eine MediaProjection erstellt, müssen die Grenzen die richtige Größe haben, da die Projektion die Anzeigepartition 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 Größe der Anwendung nicht vollständig angepasst werden kann, muss sie von einer WindowContext-Instanz aus 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 (mindestens 600 dp) unterstützt die Plattform alle Apps im Mehrfenstermodus, unabhängig von der App-Konfiguration. 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 Mehrfenstermodus ausgeführt werden kann. Mit resizeableActivity="false" wird die Ausführung der Anwendung 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 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 Vermutung infrage.

Unter Android 12 aktivieren Kamera-Apps, die eine bestimmte Bildschirmausrichtung anfordern und deren Größe nicht angepasst werden kann (resizeableActivity="false"), automatisch in das Hochformat. So wird die richtige Ausrichtung und das richtige Seitenverhältnis für die 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 für Benachrichtigungen zu Diensten 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 können kurzlebige Aufgaben abgeschlossen werden, bevor ihre 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 von allen Buckets die niedrigste Priorität (und die höchsten Einschränkungen). Die Gruppen sind in der Reihenfolge der Priorität (von hoch nach niedrig) geordnet:

  1. Aktiv: Die App wird gerade oder erst vor Kurzem verwendet.
  2. Arbeitsumgebung: Die App wird regelmäßig verwendet.
  3. Häufig: Die App wird häufig genutzt, aber nicht täglich.
  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 Anwendung, um zu entscheiden, ob die Anwendung in den eingeschränkten Bucket aufgenommen werden soll.

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 restriktiven 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 die Anwendung im eingeschränkten Bucket.

Verhalten des eingeschränkten Buckets testen

Wenn Sie testen möchten, wie sich Ihre 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

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: 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 Kamera- und Mikrofonzugriff für alle Apps auf dem Gerät durch Drücken einer einzigen Ein/Aus-Schaltfläche aktivieren und deaktivieren. Nutzer können auf die ein-/ausschaltbaren Optionen in den Schnelleinstellungen (siehe Abbildung 1) oder über den Datenschutzbildschirm in den Systemeinstellungen zugreifen.

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

Auf Geräten mit Android 12 oder höher wird ein Symbol in der Statusleiste 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 für die Berechtigungen CAMERA und RECORD_AUDIO entspricht.

Die Kacheln für Schnelleinstellungen sind mit „Kamerazugriff“ und „Mikrofonzugriff“ beschriftet
Abbildung 2: Ein-/Aus-Schaltflächen für Mikrofon und Kamera 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 des Berechtigungspakets

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, gefilterte Ergebnisse basierend auf der Paketsichtbarkeit der App in anderen Apps:

BouncyCastle-Implementierung entfernt

Unter Android 12 werden 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 betrifft Ihre App, wenn einer der folgenden Punkte 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.

  • Deine App verwendet ungültige Schlüsselgrößen mit KeyGenerator. Die Conscrypt-Implementierung von KeyGenerator führt im Vergleich zu BouncyCastle zusätzliche Validierungen für 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 lässt das Generieren von Schlüsseln ungültiger Größen zu, aber schlägt später fehl, wenn diese Schlüssel mit einem Cipher verwendet werden. Conscrypt schlägt früher fehl.

  • Sie initialisieren Ihre Galois-/Zählermodus-Chiffren (GCM) mit einer anderen Größe als 12 Byte. Die Implementierung von GcmParameterSpec in Conscrypt erfordert eine Initialisierung von 12 Byte, die NIST empfiehlt.

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 innerhalb der Toast-Nachricht hat das folgende Format: APP pasted from your clipboard.

Informationen zu Text in der Clipbeschreibung

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

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

  • 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 der Intent nicht ausgeführt und in Logcat wird die folgende Meldung 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 ü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 eine aktive Bedienungshilfe. 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. Das System blockiert also mit ein paar Ausnahmen Berührungen, die durch bestimmte Fenster geleitet werden.

Betroffene Apps

Diese Änderung betrifft Apps, die festlegen, dass Berührungen durch ihre Fenster weitergegeben werden dürfen, 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 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. Führen Sie den folgenden ADB-Befehl in einem Terminalfenster aus, um nicht vertrauenswürdige Berührungen zuzulassen:

# 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

Root-Launcher-Aktivitäten werden beim Drücken der Taste „Zurück“ nicht mehr beendet.

Mit Android 12 wird die Standardbehandlung der Systemaktivitäten geändert, bei denen die Taste „Auf den Launcher tippen“ gedrückt wird, die den Aufgaben zugrunde liegt. In früheren Versionen beendete das System diese Aktivitäten beim Drücken der Taste „Backdrück“. In Android 12 verschiebt das System die Aktivität und ihre Aufgabe in den Hintergrund, anstatt die Aktivität abzuschließen. Das neue Verhalten entspricht dem aktuellen Verhalten beim Verlassen einer App über die Startbildschirmtaste oder Touch-Gesten.

Für die meisten Anwendungen bedeutet diese Änderung, dass Nutzer, die die Anwendung über „Zurück“ verlassen, um sie schneller aus einem Warmzustand fortsetzen 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 deine App derzeit onBackPressed() für die Rückwärtsnavigation überschreibt und die Activity beendet, aktualisiere deine Implementierung so, dass der Aufruf von super.onBackPressed() statt des Abschlusses erfolgt. 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 richten sich automatisch nach dem entsprechenden Systemverhalten, wenn keine Komponenten das System „Zurück“ 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 die Anzeige bisher keinen nahtlosen Übergang unterstützt hat, 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. 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, 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 sind ein Passpoint-Feature, mit dem Netzwerkbereitstellungen unsichere Captive Portals, die offene Netzwerke verwenden, durch ein sicheres Passpoint-Netzwerk ersetzen können. Wenn die Nutzungsbedingungen akzeptiert werden müssen, wird dem Nutzer eine Benachrichtigung angezeigt. Anwendungen, die Passpoint-Netzwerke vorschlagen, die durch Nutzungsbedingungen gegatet 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(): Bei der Authentifizierung bei Netzwerken mit einem Präfix-Dekor ermöglicht das dekorierte Identitätspräfix Netzwerkbetreibern, die Network Access ID (NAI) zu aktualisieren, um ein explizites Routing durch mehrere Proxys innerhalb eines AAA-Netzwerks auszufü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. Anwendungen, 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 diese 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 Suggest API für die Internetverbindung.

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

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 zwar derzeit einige Nicht-SDK-Schnittstellen verwenden (je nach Ziel-API-Level Ihrer App), aber die Verwendung von Nicht-SDK-Methoden und -Feldern birgt immer ein hohes Risiko für Probleme mit Ihrer App.

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.