Verhaltensänderungen: alle Apps

Die Android 12-Plattform umfasst Verhaltensänderungen, die sich auf Ihre App auswirken können. Die folgenden Verhaltensänderungen gelten für alle Apps, wenn sie unter Android 12 ausgeführt werden, unabhängig von targetSdkVersion. Sie sollten Ihre App testen und sie bei Bedarf anpassen, um diese richtig zu unterstützen.

Sehen Sie sich auch die Liste der Verhaltensänderungen an, die sich nur auf Apps auswirken, 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 bewirkt ein Overscroll-Ereignis, dass die visuellen Elemente leuchten. Unter Android 12 und höher werden die visuellen Elemente bei einem Ziehvorgang gedehnt und springen zurück. Bei einem Wischvorgang werden sie geschleudert und springen zurück.

Weitere Informationen finden Sie im Leitfaden zum Animieren von Scrollgesten.

Ladebildschirme von Apps

Wenn Sie in Android 11 oder niedriger bereits einen benutzerdefinierten Ladebildschirm implementiert haben, müssen Sie Ihre App zur SplashScreen API migrieren, damit sie ab Android 12 korrekt angezeigt wird. Wenn Sie Ihre App nicht migrieren, kann es zu einer beeinträchtigten oder unbeabsichtigten App-Startumgebung kommen.

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

Außerdem wendet das System ab Android 12 immer den neuen Android-Standard-Splash-Screen bei Kaltstarts und Warmstarts für alle Apps an. Standardmäßig wird dieser Systemstandard-Splash-Screen aus dem Launcher-Symbol-Element Ihrer App und der windowBackground Ihres Designs (falls es sich um eine einzelne Farbe handelt) erstellt.

Weitere Informationen finden Sie im Entwicklerleitfaden zu Startbildschirmen.

Web-Intent-Auflösung

Ab Android 12 (API‑Level 31) wird ein allgemeiner Web-Intent nur dann zu einer Aktivität in Ihrer App aufgelöst, wenn Ihre App für die spezifische Domain genehmigt ist, die in diesem Web-Intent enthalten ist. Wenn Ihre App nicht für die Domain genehmigt ist, 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 Immersionsmodus für die Bedienung über Gesten

In Android 12 wird das vorhandene Verhalten konsolidiert, um Nutzern die Ausführung von Gestennavigationsbefehlen im Immersive-Modus zu erleichtern. Außerdem bietet Android 12 Abwärtskompatibilitätsverhalten für den klebrigen immersiven Modus.

Display#getRealSize und getRealMetrics: Einstellung und Einschränkungen

Android-Geräte sind in vielen verschiedenen Formfaktoren erhältlich, z. B. mit großen Displays, als Tablets und als Foldables. Damit Inhalte auf jedem Gerät richtig gerendert werden, 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 die folgenden Methoden eingestellt:

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, die nicht vollständig in der Größe angepasst werden können. 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 breitere 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 anpassbar sind.

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

Wenn Ihre 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 App nicht vollständig anpassbar 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

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 minWidth- und minHeight-Attribute einer Aktivität, um festzustellen, ob die Aktivität im Mehrfenstermodus ausgeführt werden kann. Wenn resizeableActivity="false", wird verhindert, dass die App im Mehrfenstermodus ausgeführt wird, unabhängig von der Mindestbreite und ‑höhe.

Weitere Informationen finden Sie unter Unterstützung für mehrere Fenster.

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. Große Displays wie faltbare Geräte und Anzeigemodi wie Multi-Window und Multi-Display stellen diese Annahme jedoch infrage.

Unter Android 12 wechseln Kamera-Apps, die eine bestimmte Bildschirmausrichtung anfordern und nicht in der Größe angepasst werden können (resizeableActivity="false"), automatisch in den Hochformatmodus mit Einzug. So wird die richtige Ausrichtung und das richtige Seitenverhältnis des Kameravorschaubilds gewährleistet. Auf Faltgeräten und anderen Geräten mit einer HAL (Hardware Abstraction Layer) für die Kamera wird die Kameraausgabe zusätzlich gedreht, um die Ausrichtung des Kamerasensors auszugleichen. Außerdem wird die Kameraausgabe zugeschnitten, um das Seitenverhältnis der Kameravorschau der App zu erreichen. Durch das Zuschneiden und die zusätzliche Drehung wird die Kameravorschau unabhängig von der Ausrichtung des Geräts und davon, ob es zusammengeklappt ist oder nicht, richtig dargestellt.

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

Um die Nutzung von Vordergrunddiensten mit kurzer Laufzeit zu optimieren, können Geräte mit Android 12 oder höher die Anzeige von Benachrichtigungen für Vordergrunddienste 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

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

  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 möglicherweise unerwünschtes Verhalten auf.

Das System berücksichtigt neben den Nutzungsmustern auch das Verhalten Ihrer App, um zu entscheiden, ob sie in den eingeschränkten Bucket aufgenommen werden soll.

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

Prüfen, ob sich Ihre App in der eingeschränkten Kategorie befindet

Rufen Sie getAppStandbyBucket() auf, um zu prüfen, ob das System Ihre App in den eingeschränkten Bucket verschoben 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 den folgenden Befehl in einem Terminalfenster aus:

adb shell am set-standby-bucket PACKAGE_NAME restricted

Standort im Vordergrund und Energiesparmodus

Ab Android 12 kann der Standort im Vordergrund (auch über einen Dienst im Vordergrund) weiterhin bereitgestellt werden, wenn der Energiesparmodus aktiv ist, auch wenn das Display ausgeschaltet ist.

Bisher wurden im Energiesparmodus keine Standortaktualisierungen mehr durchgeführt, wenn das Display ausgeschaltet war. Durch diese Änderung wird die Akkulaufzeit für Nutzer verbessert. Außerdem müssen Entwickler Nutzer nicht mehr auffordern, den Energiesparmodus zu deaktivieren, um Standortaktualisierungen zu ermöglichen.

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

  1. Rufen Sie 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 Standortupdates, wenn sie im Vordergrund ausgeführt wird 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: Systemberechtigungsdialogfeld, in dem der Nutzer ungefähre Standortinformationen gewähren kann.

Auf Geräten mit Android 12 oder höher können Nutzer anfordern, dass Ihre App nur auf ungefähre Standortdaten 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, in dem 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 Systemberechtigungen enthält die folgenden Optionen für den Nutzer (siehe Abbildung 1):

  • Genau: Ermöglicht den Zugriff auf genaue Standortinformationen.
  • Ungefähr: Ermöglicht nur den 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 einer einzigen Ein/Aus-Schaltfläche aktivieren und deaktivieren. Nutzer können über die Schnelleinstellungen (siehe Abbildung 1) oder über den Bildschirm „Datenschutz“ in den Systemeinstellungen auf die einstellbaren Optionen zugreifen.

Weitere Informationen zu diesen Ein/Aus-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

Mikrofonanzeige und Kamerazugriff-Hinweis

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

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

Die Schnelleinstellungen-Kacheln sind mit „Kamerazugriff“ und „Mikrofonzugriff“ gekennzeichnet.
Abbildung 2. Schaltflächen für Mikrofon und Kamera in den Schnelleinstellungen.
Ein abgerundetes Rechteck in der oberen rechten Ecke mit einem Kamerasymbol und einem Mikrofonsymbol
Abbildung 3: Mikrofon- und Kamerazugriff-Hinweise, die zeigen, wann zuletzt auf Daten zugegriffen wurde.

Berechtigung „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 Ergebnismenge, die auf der Paketsichtbarkeit der App für andere Apps basiert:

BouncyCastle-Implementierung entfernt

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

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

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

  • Ihre App verwendet ungültige Schlüsselgrößen mit KeyGenerator. Die Conscrypt-Implementierung von KeyGenerator führt im Vergleich zu BouncyCastle eine zusätzliche Validierung von Schlüsselparametern durch. Conscrypt erlaubt Ihrer App beispielsweise nicht, einen 64-Bit-AES-Schlüssel zu generieren, da AES nur 128-, 192- und 256-Bit-Schlüssel unterstützt.

    Mit BouncyCastle können Schlüssel mit ungültigen Größen generiert werden. Wenn diese Schlüssel jedoch mit einem Cipher verwendet werden, schlägt der Vorgang später fehl. Conscrypt schlägt früher fehl.

  • Sie initialisieren Ihre Galois/Counter Mode (GCM)-Chiffren mit einer Größe, die nicht 12 Byte beträgt. Für die Conscrypt-Implementierung von GcmParameterSpec ist eine Initialisierung von 12 Byte erforderlich, die vom NIST empfohlen wird.

Benachrichtigungen zum Zugriff auf die Zwischenablage

Wenn eine App unter Android 12 oder höher zum ersten Mal getPrimaryClip() aufruft, um auf Zwischenablagedaten einer anderen App zuzugreifen, wird der Nutzer durch eine Toast-Benachrichtigung über diesen Zwischenablagezugriff informiert.

Der Text in der Kurzmitteilung 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 keine Systemdialogfelder schließen

Um die Nutzerkontrolle bei der Interaktion mit Apps und dem System zu verbessern, ist die Intent-Aktion ACTION_CLOSE_SYSTEM_DIALOGS ab Android 12 nicht mehr verfügbar. Mit Ausnahme einiger Sonderfälle führt das System einen der folgenden Schritte aus, wenn Ihre App versucht, einen Intent aufzurufen, der diese Aktion enthält, je nach Ziel-SDK-Version Ihrer App:

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

  • In Ihrer App wird ein Instrumentationstest ausgeführt.

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

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

  • Ihre App ist auf Android 11 oder niedriger ausgerichtet und hat einen aktiven Barrierefreiheitsdienst. Wenn Ihre App auf Android 12 ausgerichtet ist und die Benachrichtigungsleiste schließen soll, verwenden Sie stattdessen die Barrierefreiheitsaktion 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 verarbeiten, wenn ein Overlay die App auf unsichere Weise verdeckt. Das System blockiert also Berührungen, die bestimmte Fenster durchlaufen, mit einigen Ausnahmen.

Betroffene Apps

Diese Änderung betrifft Apps, die Berührungen durch ihre Fenster weiterleiten, 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.
  • Aktivitätszeiträume, für die das Flag FLAG_NOT_TOUCHABLE verwendet wird.

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 eingeblendet, wenn der Nutzer mit Ihrer App interagiert.

  • Vertrauenswürdige Fenster: Dazu gehören unter anderem die folgenden Zeiträume:

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

  • Vollständig transparente Fenster: Die Property alpha ist für das Fenster auf 0,0 gesetzt.

  • Systembenachrichtigungsfenster müssen ausreichend transparent sein. Das System betrachtet eine Reihe von Systembenachrichtigungsfenstern als ausreichend transparent, 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

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

Root-Launcher-Aktivitäten werden nicht mehr durch Drücken der Zurück-Taste beendet

In Android 12 wird die Standardbehandlung des System-Back-Press auf Launcher-Aktivitäten geändert, die sich im Stamm ihrer Aufgaben befinden. In früheren Versionen hat das System diese Aktivitäten beim Drücken der Zurück-Taste abgeschlossen. In Android 12 verschiebt das System die Aktivität und ihre Aufgabe in den Hintergrund, anstatt die Aktivität 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 Zurück-Geste verwenden, um Ihre App zu verlassen, die App schneller aus einem Warm-State fortsetzen können, anstatt sie aus einem Cold-State neu starten zu müssen.

Wir empfehlen, Ihre Apps mit dieser Änderung zu testen. Wenn Ihre App derzeit onBackPressed() überschreibt, um die Rückwärtsnavigation zu verarbeiten und die Activity zu beenden, aktualisieren Sie Ihre Implementierung so, dass super.onBackPressed() aufgerufen wird, anstatt die Activity zu beenden. Bei der Anrufaktivität super.onBackPressed() wird die Aktivität und ihre Aufgabe bei Bedarf in den Hintergrund verschoben. So wird eine einheitlichere Navigation für Nutzer in verschiedenen Apps ermöglicht.

Außerdem empfehlen wir im Allgemeinen, die AndroidX Activity APIs für benutzerdefinierte Zurück-Navigation zu verwenden, anstatt onBackPressed() zu überschreiben. Die AndroidX Activity-APIs werden automatisch an das entsprechende Systemverhalten weitergeleitet, wenn keine Komponenten das Drücken der System-Zurück-Taste abfangen.

Grafiken und Bilder

Verbessertes Umschalten der Aktualisierungsrate

In Android 12 können Änderungen der Aktualisierungsrate über 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 ein- oder zweisekündiger schwarzer Bildschirm. Bisher wurde, wenn das Display keinen nahtlosen Übergang unterstützte, nach dem Aufrufen von setFrameRate() in der Regel dieselbe Aktualisierungsrate verwendet. Mit dem Aufruf von getAlternativeRefreshRates() können Sie im Voraus feststellen, ob die Umstellung auf die neue Aktualisierung wahrscheinlich reibungslos verlaufen wird. Im Allgemeinen wird der Callback onDisplayChanged() nach dem Umschalten der Aktualisierungsrate aufgerufen. Bei einigen extern angeschlossenen Displays wird er jedoch während eines nicht nahtlosen Übergangs aufgerufen.

Hier ist ein Beispiel für die 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 erhält eine Benachrichtigung, wenn er die Nutzungsbedingungen akzeptieren muss. Apps, die Passpoint-Netzwerke vorschlagen, für die Nutzungsbedingungen gelten, 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. In diesem Fall muss ein alternatives oder altes Netzwerk vorgeschlagen werden.

  • isDecoratedIdentitySupported(): Bei der Authentifizierung in Netzwerken mit einer Präfixdekoration können Netzwerkbetreiber mit dem dekorierten Identitätspräfix die Network Access Identifier (NAI) aktualisieren, um explizites Routing über mehrere Proxys in einem AAA-Netzwerk durchzuführen (weitere Informationen finden Sie in 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 diese API zuerst 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 im Netzwerk schlägt möglicherweise fehl.

Um einen Passpoint-Vorschlag zu erstellen, 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 for internet connectivity.

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. Derzeit können Sie jedoch einige Nicht-SDK-Schnittstellen verwenden (abhängig vom Ziel-API-Level Ihrer App). Die Verwendung einer Nicht-SDK-Methode oder eines Nicht-SDK-Felds 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 das herauszufinden. Wenn Ihre App auf Nicht-SDK-Schnittstellen basiert, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Wir verstehen jedoch, dass einige Apps gültige Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen haben. 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 Version von Android finden Sie unter Updates to non-SDK interface restrictions in Android 12. Weitere Informationen zu Nicht-SDK-Schnittstellen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen.