Verhaltensänderungen: alle Apps

Die Android 12-Plattform enthält Verhaltensänderungen, die sich auf deine 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 App testen und gegebenenfalls so anpassen, dass sie diese ordnungsgemäß unterstützt.

Sehen Sie sich auch die Liste der Verhaltensänderungen an, die nur Apps betreffen, die auf Android 12 ausgerichtet sind.

Nutzererfahrung

Overscroll-Effekt „Dehnen“

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

Unter Android 11 und niedriger führt ein Overscroll-Ereignis dazu, dass die visuellen Elemente leuchten. Unter Android 12 und höher werden die visuellen Elemente bei einem Drag-Ereignis gestreckt und springen zurück. Bei einem Fling-Ereignis werden sie weggeschleudert und springen zurück.

Weitere Informationen finden Sie im Leitfaden zum Animieren von Scroll-Gesten.

Ladebildschirme der App

Wenn du zuvor einen benutzerdefinierten Splash Screen in Android 11 oder niedriger implementiert hast, musst du deine App zur SplashScreen API migrieren, damit sie ab Android 12 korrekt angezeigt wird. Wenn Sie Ihre App nicht migrieren, kann dies zu einer beeinträchtigten oder unbeabsichtigten App-Starterfahrung führen.

Eine Anleitung finden Sie unter Vorhandene Splash Screen-Implementierung zu Android 12 migrieren.

Außerdem wird ab Android 12 bei allen Apps der neue Android-System-Standard-Splash-Screen bei Kalt- und Warmstarts angewendet. Standardmäßig wird dieser System-Standard-Splash-Screen mit dem Launcher-Symbolelement Ihrer App und dem windowBackground Ihres Designs (wenn es einfarbig ist) erstellt.

Weitere Informationen finden Sie im Entwicklerleitfaden für Splash Screens.

Auflösung von Web-Intents

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 im Web-Intent enthaltene Domain genehmigt ist. Wenn Ihre App nicht für die Domain genehmigt wurde, wird der Web-Intent stattdessen in der Standardbrowser-App des Nutzers aufgelöst.

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

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

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

Android 12 fasst das bestehende Verhalten zusammen, damit Nutzer im immersiven Modus leichter Befehle zur Bedienung über Gesten ausführen können. Darüber hinaus bietet Android 12 Abwärtskompatibilität für den immersiven Modus.

Display#getRealSize und getRealMetrics: Einstellung und Einschränkungen

Android-Geräte sind in vielen verschiedenen Formfaktoren verfügbar, z. B. mit großen Displays, als Tablets und als faltbare Smartphones. Damit Inhalte auf jedem Gerät richtig gerendert werden, muss Ihre App die Bildschirm- oder Displaygröße ermitteln. Im Laufe der Zeit wurden in Android verschiedene APIs zum Abrufen dieser Informationen bereitgestellt. In Android 11 haben wir die WindowMetrics API eingeführt und diese Methoden verworfen:

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

Um das Verhalten von Anwendungen zu minimieren, die Display APIs verwenden, um die Grenzen der Anwendung abzurufen, schränkt Android 12 die von den APIs zurückgegebenen Werte für Apps ein, deren Größe nicht vollständig angepasst werden kann. 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 umfassendere Kompatibilität mit älteren Android-Versionen können Sie die Jetpack-Bibliothek WindowManager verwenden, die eine WindowMetrics-Klasse enthält, 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 in der Größe anpassbar sind.

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

Wenn deine App ein MediaProjection erstellt, müssen die Grenzen richtig dimensioniert sein, da die Projektion die Displaypartition erfasst, in der die Projektor-App ausgeführt wird.

Wenn die Größe der App vollständig angepasst werden kann, gibt der Aktivitätskontext die richtigen Grenzen zurück:

Kotlin

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

Java

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

Wenn die Größe der App nicht vollständig angepasst werden kann, muss sie eine Abfrage von einer WindowContext-Instanz durchführen 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

In Android 12 ist der Mehrfenstermodus das Standardverhalten.

Auf großen Bildschirmen (sw >= 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 Werte minWidth und minHeight einer Aktivität, um festzustellen, ob die Aktivität im Mehrfenstermodus ausgeführt werden kann. Wenn resizeableActivity="false", kann die App unabhängig von der Mindestbreite und -höhe nicht im Mehrfenstermodus ausgeführt werden.

Weitere Informationen findest du unter Unterstützung für den 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. Große Formfaktoren wie faltbare Geräte und Anzeigemodi wie Mehrfenstermodus und Multi-Display stellen diese Annahme jedoch infrage.

Unter Android 12 wechseln Kamera-Apps, die eine bestimmte Bildschirmausrichtung anfordern und deren Größe nicht angepasst werden kann (resizeableActivity="false"), automatisch in den Porträtmodus mit Einzug. Dadurch werden die richtige Ausrichtung und das richtige Seitenverhältnis der Kameravorschau sichergestellt. Auf faltbaren und anderen Geräten mit einer Hardwareabstraktionsschicht (HAL) für die Kamera 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 Kameravorschau unabhängig von der Ausrichtung des Geräts und davon, ob es zu- oder aufgeklappt ist, richtig dargestellt.

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

Um die Nutzung von kurz laufenden Diensten im Vordergrund zu optimieren, können Geräte mit Android 12 oder höher die Anzeige von Benachrichtigungen für Dienste im Vordergrund um 10 Sekunden verzögern. Es gibt jedoch einige Ausnahmen. Durch diese Änderung haben kurzlebige Aufgaben die Möglichkeit, abgeschlossen zu werden, bevor ihre Benachrichtigungen angezeigt werden.

Leistung

Eingeschränkter App-Standby-Bucket

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 Buckets sind nach Priorität von hoch bis niedrig sortiert:

  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 täglich verwendet.
  4. Selten: Die App wird nicht häufig verwendet.
  5. Eingeschränkt: Die App verbraucht viele Systemressourcen oder zeigt möglicherweise unerwünschtes Verhalten.

Das System berücksichtigt das Verhalten Ihrer App sowie die Nutzungsmuster, um zu entscheiden, ob Ihre App in den eingeschränkten Bucket verschoben werden soll.

Wenn Ihre App Systemressourcen verantwortungsvoller nutzt, ist es weniger wahrscheinlich, dass sie in den eingeschränkten Bucket verschoben wird. Außerdem wird Ihre App in einen weniger restriktiven Bucket verschoben, wenn der Nutzer direkt mit Ihrer App interagiert.

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

Wenn du prüfen möchtest, ob das System deine App in den eingeschränkten Bucket verschoben hat, rufe getAppStandbyBucket() auf. 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 du testen möchtest, wie sich deine App verhält, wenn sie vom System in den eingeschränkten Bucket verschoben wird, kannst du sie manuell dorthin verschieben. Führen Sie dazu den folgenden Befehl in einem Terminalfenster aus:

adb shell am set-standby-bucket PACKAGE_NAME restricted

Standortermittlung im Vordergrund und Energiesparmodus

Ab Android 12 können Standortdaten im Vordergrund (auch von einem Dienst im Vordergrund) weiterhin bereitgestellt werden, während der Energiesparmodus aktiv ist, auch wenn das Display ausgeschaltet ist.

Bisher wurden im Energiesparmodus Standort-Updates gestoppt, wenn das Display ausgeschaltet war. Diese Änderung ermöglicht eine längere Akkulaufzeit für Nutzer und bedeutet, dass Entwickler Nutzer nicht mehr bitten müssen, den Energiesparmodus zu deaktivieren, um Standort-Updates zu erhalten.

Apps, die den Standort über einen Dienst im Vordergrund anfordern, sollten die folgenden Schritte ausführen:

  1. Rufe getLocationPowerSaverMode() auf, um zu prüfen, wie sich die Standortfunktionen des Geräts verhalten, wenn der Energiesparmodus aktiv ist.
  2. Wenn LOCATION_MODE_FOREGROUND_ONLY zurückgegeben wird, erhält Ihre App weiterhin Standort-Updates, während sie sich im Vordergrund befindet oder ein Dienst im Vordergrund ausgeführt wird, während der Energiesparmodus aktiviert und das Display ausgeschaltet ist.

Sicherheit und Datenschutz

Ungefährer Standort

Das Dialogfeld enthält zwei Gruppen von Optionen, die übereinander angeordnet sind.
Abbildung 1: Systemdialogfeld für Berechtigungen, in dem der Nutzer die Berechtigung für den Zugriff auf Informationen zum ungefähren Standort erteilen kann.

Auf Geräten mit Android 12 oder höher können Nutzer festlegen, 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 berücksichtigen, dass der Nutzer Ihrer App Zugriff auf den ungefähren Standort gewährt. Sie sollten beide Berechtigungen in einer einzigen Laufzeitanfrage einfügen.

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

  • Genau: Gewährt Zugriff auf genaue Standortinformationen.
  • 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 aktivieren und deaktivieren, indem sie eine einzige Umschaltoption drücken. Nutzer können die aktivierbaren Optionen über die Schnelleinstellungen (siehe Abbildung 1) oder über den Bildschirm „Datenschutz“ 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.

Zugriffshinweise für Mikrofon und Kamera

Wenn eine App auf Geräten mit Android 12 oder höher 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, finden Sie hier.

Die Schnelleinstellungen-Kacheln 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 Kamerasymbol und ein Mikrofonsymbol enthält
Abbildung 3. Mikrofon- und Kameraanzeigen, die den letzten Datenzugriff anzeigen.

Berechtigung für die Sichtbarkeit von Paketen

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 Gruppe von Ergebnissen, die auf der Paketsichtbarkeit der App für andere Apps basieren:

BouncyCastle-Implementierung entfernt

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

Diese Änderung betrifft Ihre App, wenn eine der folgenden Bedingungen zutrifft:

  • Ihre App verwendet 512-Bit-Schlüssel. Conscrypt unterstützt diese Schlüsselgröße nicht. Aktualisieren Sie bei Bedarf die Kryptografielogik Ihrer App, um andere 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 eine zusätzliche Validierung der Schlüsselparameter durch. Conscrypt lässt beispielsweise nicht zu, dass Ihre App einen 64-Bit-AES-Schlüssel generiert, da AES nur 128-, 192- und 256-Bit-Schlüssel unterstützt.

    BouncyCastle ermöglicht die Generierung 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 GCM-Chiffren (Galois/Counter Mode) mit einer anderen Größe als 12 Byte. Die Conscrypt-Implementierung von GcmParameterSpec erfordert eine Initialisierung von 12 Byte, was vom NIST empfohlen wird.

Benachrichtigungen zum Zugriff auf die Zwischenablage

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

Der Text in der Toast-Nachricht hat das folgende 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 Systemdialoge nicht schließen

Um die Nutzerkontrolle 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, wenn deine App versucht, einen Intent aufzurufen, der diese Aktion enthält, je nach Ziel-SDK-Version deiner App einen der folgenden Schritte aus:

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

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

  • In Ihrer App 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. Außerdem hat der Nutzer mit einer Benachrichtigung interagiert, möglicherweise über die Aktionsschaltflächen der Benachrichtigung, und Ihre App verarbeitet als Reaktion auf diese Nutzeraktion einen Dienst oder Ü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 soll, verwende stattdessen die Bedienungshilfe-Aktion 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-Events verarbeiten, wenn ein Overlay die App auf unsichere Weise verdeckt. Mit anderen Worten: Das System blockiert Berührungen, die durch bestimmte Fenster gehen, mit einigen Ausnahmen.

Betroffene Apps

Diese Änderung betrifft Apps, die Berührungen durch ihre Fenster zulassen, 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, 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 „Pass-Through“-Berührungen zulässig:

  • Interaktionen in Ihrer App: Ihre App zeigt das Overlay an und das Overlay wird nur angezeigt, wenn der Nutzer mit Ihrer App interagiert.

  • Vertrauenswürdige Fenster. Diese Zeitfenster umfassen unter anderem Folgendes:

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

  • Vollständig transparente Fenster. Das Attribut alpha ist für das Fenster 0,0.

  • Ausreichend transparente Systemwarnungsfenster. Das System betrachtet eine Reihe von Systemwarnungsfenstern 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, wird in Logcat die folgende Meldung protokolliert:

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. Wenn Sie nicht vertrauenswürdige Berührungen zulassen möchten, 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 Standardverhalten wiederherzustellen (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 nicht mehr beendet, wenn die Zurück-Taste gedrückt wird

Mit Android 12 wird die Standardbehandlung des Zurück-Tastendrucks des Systems bei Launcher-Aktivitäten geändert, die sich im Stammverzeichnis ihrer Aufgaben befinden. In früheren Versionen wurden diese Aktivitäten beim Drücken der Zurück-Taste beendet. In Android 12 verschiebt das System die Aktivität und die zugehörige Aufgabe in den Hintergrund, anstatt die Aktivität zu beenden. Das neue Verhalten entspricht dem aktuellen Verhalten, wenn eine App über den Home-Button oder die Geste verlassen wird.

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

Wir empfehlen, Ihre Apps mit dieser Änderung zu testen. Wenn deine App derzeit onBackPressed() überschreibt, um die Rückwärtsnavigation zu verarbeiten und die Activity zu beenden, aktualisiere deine Implementierung so, dass super.onBackPressed() aufgerufen wird, anstatt die Aktivität zu beenden. Durch den Aufruf von super.onBackPressed() werden die Aktivität und die zugehörige Aufgabe bei Bedarf in den Hintergrund verschoben. Dadurch wird die Navigation für Nutzer in allen Apps einheitlicher.

Außerdem empfehlen wir im Allgemeinen, die AndroidX Activity APIs zu verwenden, um eine benutzerdefinierte Rückwärtsnavigation bereitzustellen, anstatt onBackPressed() zu überschreiben. Die AndroidX Activity APIs greifen automatisch auf das entsprechende Systemverhalten zurück, wenn keine Komponenten das Drücken der Zurück-Taste abfangen.

Grafiken und Bilder

Verbesserter Wechsel der Aktualisierungsrate

In Android 12 können Änderungen der Aktualisierungsrate mit setFrameRate() unabhängig davon erfolgen, ob das Display einen nahtlosen Übergang zur neuen Aktualisierungsrate unterstützt. Ein nahtloser Übergang ist ein Übergang ohne visuelle Unterbrechungen, 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 Aktualisierungsrate verwendet. Sie können im Voraus feststellen, ob die Umstellung auf die neue Aktualisierung wahrscheinlich nahtlos erfolgt, indem Sie getAlternativeRefreshRates() aufrufen. Im Allgemeinen wird der Callback onDisplayChanged() aufgerufen, nachdem der Wechsel der Aktualisierungsrate abgeschlossen ist. Bei einigen extern verbundenen Displays wird er jedoch während eines nicht nahtlosen Übergangs aufgerufen.

Hier ist ein Beispiel für eine mögliche Implementierung:

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

Die folgenden APIs wurden in Android 12 hinzugefügt:

  • isPasspointTermsAndConditionsSupported(): Nutzungsbedingungen ist eine Passpoint-Funktion, mit der Netzwerkbereitstellungen unsichere Captive Portale, die offene Netzwerke verwenden, durch ein sicheres Passpoint-Netzwerk ersetzen können. Der Nutzer wird benachrichtigt, wenn er die Nutzungsbedingungen akzeptieren muss. 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 und es muss ein alternatives oder älteres Netzwerk vorgeschlagen werden.

  • isDecoratedIdentitySupported(): Bei der Authentifizierung in Netzwerken mit einem Präfix ermöglicht das dekorierte Identitätspräfix Netzwerkbetreibern, den Network Access Identifier (NAI) zu aktualisieren, um explizites Routing über mehrere Proxys innerhalb eines AAA-Netzwerks durchzuführen (weitere Informationen finden Sie unter RFC 7542).

    Android 12 implementiert diese Funktion, 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 ergänzt und die Authentifizierung beim Netzwerk schlägt möglicherweise fehl.

Zum Erstellen eines Passpoint-Vorschlags müssen Apps 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 die Internetverbindung.

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 stellen nach Möglichkeit öffentliche Alternativen zur Verfügung, bevor wir Nicht-SDK-Schnittstellen einschränken.

Wenn Ihre App nicht auf Android 12 ausgerichtet ist, sind Sie von einigen dieser Änderungen möglicherweise nicht sofort betroffen. Derzeit können Sie zwar einige Nicht-SDK-Schnittstellen verwenden (abhängig vom Ziel-API-Level Ihrer App), die Verwendung von Nicht-SDK-Methoden oder ‑Feldern birgt jedoch immer ein hohes Risiko, dass Ihre App nicht mehr funktioniert.

Wenn Sie sich nicht sicher sind, ob Ihre App Nicht-SDK-Schnittstellen verwendet, können Sie Ihre App testen, um dies herauszufinden. Wenn Ihre App auf Nicht-SDK-Schnittstellen basiert, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Wir wissen jedoch, 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-Schnittstelle 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 Aktualisierungen der 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.