Verhaltensänderungen: alle Apps

Die Android 12-Plattform enthält Verhaltensänderungen, die auf Ihre App auswirken. Die folgenden Verhaltensänderungen gelten für alle Apps, wenn sie laufen auf Android 12, unabhängig von targetSdkVersion. Sie sollten testen Sie Ihre App und passen Sie sie bei Bedarf an, um diese korrekt zu unterstützen. zutreffend sind.

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

Nutzererfahrung

Overscroll-Effekt strecken

Auf Geräten mit Android 12 und höher wird das visuelle Verhalten für Overscroll Ereignisse.

Unter Android 11 und niedriger führt ein Overscroll-Ereignis dazu, dass die visuellen Elemente ein Leuchten; unter Android 12 und höher, dehnen sich die visuellen Elemente und reflektieren bei einem Drag-Event.

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

App-Startbildschirme

Wenn Sie bereits einen benutzerdefinierten Ladebildschirm in Android 11 oder niedriger ist, musst du deine App zur SplashScreen API migrieren, damit wird es ab Android 12 korrekt angezeigt. Wenn Sie Ihre Anwendung nicht migrieren, beeinträchtigt oder unbeabsichtigt gestartet werden.

Eine Anleitung dazu finden Sie unter Vorhandenen Ladebildschirm migrieren. Implementierung auf Android 12.

Außerdem wendet das System ab Android 12 immer die neue Android-Version Ladebildschirm des Systems eingeschaltet kalt und Warmstarts für alle Apps. Standardmäßig wird der Ladebildschirm des Systems anhand der Launcher-Symbols und das windowBackground Ihrer einfarbiges Design.

Weitere Informationen finden Sie im Entwicklerleitfaden für Startbildschirme.

Web Intent-Auflösung

Ab Android 12 (API-Level 31) wird ein generischer Web Intent zu einem Aktivitäten in Ihrer App nur, wenn sie für die jeweilige Domain genehmigt wurde die in diesem Web Intent enthalten sind. Wenn Ihre App für die Domain nicht genehmigt wird, Web Intent wird stattdessen in die Standardbrowser-App des Nutzers aufgelöst.

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

Wenn Ihre App Web-Intents aufruft, sollten Sie eine Eingabeaufforderung oder ein Dialogfeld hinzufügen, in dem Sie dazu aufgefordert werden. um die Aktion zu bestätigen.

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

Android 12 fasst die bisherige Funktionsweise zusammen, damit Nutzer Sie können im immersiven Modus Modus an. In Android 12 bietet Abwärtskompatibilität für immersive Modus an.

Display#getRealSize und getRealMetrics: Einstellung und Einschränkungen

Android-Geräte sind in vielen verschiedenen Formfaktoren erhältlich, z. B. große Displays, Tablets und faltbare Geräte. Um Inhalte für jedes einzelne verwendet, muss deine App die Bildschirm- oder Anzeigegröße bestimmen. Im Laufe der Zeit Android bietet verschiedene APIs zum Abrufen dieser Informationen. In Android 11 haben wir die WindowMetrics eingeführt. API und haben folgende Methoden verworfen:

In Android 12 empfehlen wir weiterhin WindowMetrics und werden diese Methoden eingestellt:

Um das Verhalten von Anwendungen zu mindern, die Display-APIs zum Abrufen des App-Grenzen festlegen, schränkt Android 12 die Werte ein, die von den APIs zurückgegeben werden. für Apps, deren Größe nicht vollständig angepasst werden kann. Dies könnte sich auf die Apps, die diese Informationen mit MediaProjection verwenden

Apps sollten die WindowMetrics APIs verwenden, um die Grenzen der das eigene Fenster und Configuration.densityDpi um die aktuelle Dichte abzufragen.

Für eine umfassendere Kompatibilität mit älteren Android-Versionen können Sie den Jetpack-Bibliothek WindowManager, die 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 sich auf WindowMetrics aus einem Aktivitätskontext Arbeiten im Zusammenhang mit der Benutzeroberfläche, insbesondere WindowManager.getCurrentWindowMetrics() oder der WindowMetricsCalculator.computeCurrentWindowMetrics()

Wenn Ihre Anwendung ein MediaProjection erstellt, müssen die Grenzen die richtige Größe haben. da die Projektion die Anzeigepartition erfasst, in der die Projector App ausgeführt wird.

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

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 einem WindowContext-Objekt abfragen. und rufen Sie den WindowMetrics der Aktivitätsgrenzen mithilfe von WindowManager.getMaximumWindowMetrics() oder die Jetpack-Methode WindowMetricsCalculator.computeMaximumWindowMetrics()

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, Dimensionen.

Bei kleinen Bildschirmen (sw < 600 dp) prüft das System minWidth und minHeight um zu ermitteln, ob die Aktivität im Mehrfenstermodus ausgeführt werden kann. Wenn resizeableActivity="false", Die Ausführung der App im Mehrfenstermodus wird unabhängig vom Mindestwert verhindert Breite und Höhe festlegen.

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 der Kamera das Gerät und das Seitenverhältnis der Kameravorschau. Aber großer Bildschirm Faktoren wie faltbare Geräte und Anzeigemodi wie Mehrfenstermodus und Multi-Display-Anzeigen stellen, widerspricht diese Annahme.

Kamera-Apps unter Android 12, die einen bestimmten Bildschirm anfordern Ausrichtung und kann nicht automatisch in der Größe (resizeableActivity="false") geändert werden in das Hochformat wechseln, wodurch die richtige Ausrichtung Seitenverhältnis der Kameravorschau. Auf faltbaren Geräten und anderen Geräten mit Kamera Hardware-Abstraktionsschicht (HAL) Eine zusätzliche Drehung wird auf die Kameraausgabe angewendet, um die Kamera auszugleichen. Sensorausrichtung und die Kameraausgabe wird so zugeschnitten, dass sie dem Seitenverhältnis entspricht der Kameravorschau der App. Durch das Zuschneiden und die zusätzliche Drehung sorgen Darstellung der Kameravorschau unabhängig von der Geräteausrichtung und dem zugeklappten Display oder aufgeklappt ist.

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

Um ein optimiertes Erlebnis für kurze Zeit im Vordergrund zu bieten -Dienste, Geräte, die Bei Android 12 oder höher kann die Anzeige des Dienstes im Vordergrund verzögert werden um 10 Sekunden zu verkürzen. Ausnahmen. Dieses können kurzlebige Aufgaben abgeschlossen werden, bevor ihre Benachrichtigungen erscheinen.

Leistung

Eingeschränkter App-Standby-Bucket

Für Android 11 (API-Level 30) wurden die eingeschränkten Bucket als App-Standby-Netzwerk Bucket. Ab Android 12 ist dieser Bucket standardmäßig aktiv. Der eingeschränkte Bucket hat die niedrigste Priorität (und die höchsten Einschränkungen) von alle Buckets. 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 App verbraucht viele Systemressourcen oder kann unerwünschtes Verhalten.

Das System berücksichtigt neben den Nutzungsmustern auch das Verhalten Ihrer App, Entscheiden Sie, ob Ihre Anwendung in den eingeschränkten Bucket verschoben werden soll.

Es ist weniger wahrscheinlich, dass Ihre Anwendung in den eingeschränkten Bucket verschoben wird, wenn sie Folgendes verwendet: Systemressourcen verantwortungsvoller gestalten können. Außerdem platziert das System Ihre App restriktiven Bucket, wenn der Nutzer direkt mit Ihrer Anwendung interagiert.

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

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

Verhalten des eingeschränkten Buckets testen

Um zu testen, wie sich Ihre App verhält, wenn das System Ihre App in die eingeschränkte Bucket können Sie Ihre Anwendung manuell in diesen Bucket verschieben. Führen Sie dazu den Befehl folgenden Befehl in einem Terminalfenster:

adb shell am set-standby-bucket PACKAGE_NAME restricted

Sicherheit und Datenschutz

Ungefährer Standort

<ph type="x-smartling-placeholder">
</ph> Das Dialogfeld enthält zwei Optionen, eine über der Anderes
Abbildung 1: Dialogfeld für Systemberechtigungen, das dem Nutzer erlaubt um Informationen zum ungefähren Standort zu erhalten.

Auf Geräten mit Android 12 oder höher können Nutzer anfragen, ob Ihre App Nur Zugriff auf ungefähren Standort Informationen.

Wenn Ihre App die ACCESS_FINE_LOCATION Laufzeitberechtigung aktiviert haben, sollten Sie auch ACCESS_COARSE_LOCATION Berechtigung für den Fall, dass der Nutzer den Zugriff auf den ungefähren Standort gewährt zu Ihrer App hinzufügen. Sie sollten beide Berechtigungen in einer Laufzeit aufnehmen anfragen.

Das Dialogfeld „Systemberechtigungen“ enthält die folgenden Optionen für den Nutzer: wie in Abbildung 1 gezeigt:

  • 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 Aktivieren und deaktivieren Sie den Zugriff auf Kamera und Mikrofon für alle Apps auf dem Gerät, indem Sie durch Drücken einer Ein-/Aus-Schaltfläche. Nutzer können auf die ein-/ausschaltbaren Optionen Schnelleinstellungen, wie in oder auf dem Privatsphärebildschirm in den Systemeinstellungen.

Weitere Informationen zu diesen dass Ihre App den Best Practices für die CAMERA und RECORD_AUDIO Berechtigungen.

Mikrofon- und Kameraanzeigen

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

Weitere Informationen zu diesen Indikatoren und darüber, wie Sie dass deine App den Best Practices für die CAMERA und RECORD_AUDIO Berechtigungen.

<ph type="x-smartling-placeholder">
</ph> Die Kacheln für Schnelleinstellungen sind mit „Kamerazugriff“ gekennzeichnet und „Mikrofonzugriff“
Abbildung 2: Ein/Aus-Schaltfläche für Mikrofon und Kamera Schnelleinstellungen
<ph type="x-smartling-placeholder">
</ph> Ein abgerundetes Rechteck in der oberen rechten Ecke, das enthält ein Kamera- und ein Mikrofonsymbol
Abbildung 3: Mikrofon- und Kameraanzeigen, die zeigen, kürzlich erfolgten Datenzugriff.

Sichtbarkeit des Berechtigungspakets

Auf Geräten mit Android 12 oder höher werden Apps, die auf Android 11 (API-Level 30) oder höher und eine der folgenden Methoden aufrufen Sie erhalten einen gefilterten Satz von Ergebnissen basierend auf dem Paket der App. Sichtbarkeit in andere Apps:

BouncyCastle-Implementierung entfernt

Unter Android 12 werden viele BouncyCastle-Implementierungen von kryptografische Algorithmen, die zuvor verworfen wurden, einschließlich aller AES- Algorithmen. Das System verwendet stattdessen die Methode Conscrypt-Implementierungen von diese 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 bietet zusätzliche Validierung wichtiger Parameter im Vergleich zu BouncyCastle. Beispiel: Conscrypt lässt deine App nicht zu, einen 64-Bit-AES-Schlüssel zu generieren, da AES nur unterstützt 128-, 192- und 256-Bit-Schlüssel.

    BouncyCastle lässt die Generierung 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 Conscrypt-Implementierung von Für GcmParameterSpec ist ein Initialisierung von 12 Byte, was NIST empfiehlt.

Benachrichtigungen zum Zugriff auf die Zwischenablage

Unter Android 12 und höher: Wenn eine App getPrimaryClip() um auf Clipdaten von einem anderen App zum ersten Mal angezeigt wird, wird eine Toast-Nachricht benachrichtigt den Nutzer über den Zugriff auf die Zwischenablage.

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 ermitteln:

Apps können Systemdialoge nicht schließen

Um die Steuerungsmöglichkeiten für Nutzer bei der Interaktion mit Apps und dem System zu verbessern, ACTION_CLOSE_SYSTEM_DIALOGS Intent-Aktion wird mit Android 12 eingestellt. Abgesehen von einigen Sonderfällen, wenn Ihre App versucht, Nutzer Intent mit dieser Aktion, dem führt je nach SDK-Zielversion Ihrer App eine der folgenden Aktionen aus:

  • Wenn deine App auf Android 12 oder höher ausgerichtet ist, wird ein SecurityException ist aufgetreten.

  • Wenn Ihre App auf Android 11 (API-Level 30) oder niedriger ausgerichtet ist, ausführen, und die folgende Nachricht wird in Logcat:

    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 immer noch auf Android 12 oder höher:

  • Ihre App führt eine Instrumentierung aus testen.

  • Deine App ist auf Android 11 oder niedriger ausgerichtet und es wird ein Fenster angezeigt über der Benachrichtigung Leiste.

  • Ihre App ist auf Android 11 oder niedriger ausgerichtet. Darüber hinaus hat die nutzende Person hat mit einer Benachrichtigung interagiert, möglicherweise unter Verwendung der Aktion der Benachrichtigung Schaltflächen und deine App Verarbeitung eines Dienstes oder einer Übertragung Empfänger als Reaktion auf diese Nutzeraktion.

  • Deine App ist auf Android 11 oder niedriger ausgerichtet und hat eine aktive Bedienungshilfen. Wenn Ihre App auf Android 12 ausgerichtet ist und die Benachrichtigungsleiste schließen möchte, verwenden Sie die GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE die Bedienungshilfe aktivieren.

Nicht vertrauenswürdige Touch-Events werden blockiert

Um die Sicherheit und Nutzerfreundlichkeit des Systems zu wahren, Android 12 hindert Apps daran, Touchscreens zu nutzen , bei denen die App durch ein Overlay auf unsichere Weise verdeckt wird. Das System blockiert Berührungen, die durch bestimmte Fenster verlaufen, ein paar Ausnahmen.

Betroffene Apps

Diese Änderung betrifft Apps, die festlegen, dass Berührungen durch ihr Fenster geleitet werden. indem Sie beispielsweise die FLAG_NOT_TOUCHABLE melden. Hier einige Beispiele:

  • Overlays, für die die Funktion SYSTEM_ALERT_WINDOW z. B. für Fenster, in denen TYPE_APPLICATION_OVERLAY, und verwenden Sie das Flag FLAG_NOT_TOUCHABLE.
  • Aktivitätsfenster, die das Flag FLAG_NOT_TOUCHABLE verwenden.

Ausnahmen

In den folgenden Fällen wird Berührungen sind erlaubt:

  • Interaktionen innerhalb Ihrer App: In der App wird das Overlay und das Overlay angezeigt. erscheint nur, wenn der Nutzer mit Ihrer App interagiert.

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

  • Unsichtbare Fenster: Die Stammansicht des Fensters GONE oder INVISIBLE

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

  • Ausreichend durchscheinende Systembenachrichtigungsfenster Das System berücksichtigt eine Menge ausreichend durchscheinend, wenn die kombinierte Deckkraft ist kleiner oder gleich der maximalen Deckkraft des Systems für Berührungen. 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ührung vom System blockiert wird, Logcat protokolliert die folgende Meldung:

Untrusted touch due to occlusion by PACKAGE_NAME

Änderung testen

Nicht vertrauenswürdige Berührungen werden auf Geräten, die ausgeführt werden, standardmäßig blockiert. Android 12 oder höher. Führen Sie den folgenden Befehl aus, um nicht vertrauenswürdige Berührungen zuzulassen: folgenden ADB-Befehl in einem Terminalfenster:

# 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

Um das Standardverhalten wiederherzustellen (nicht vertrauenswürdige Berührungen werden blockiert), führen Sie den folgenden Befehl:

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

Durch Android 12 ändert sich die Standardbehandlung des Systems: „Auf den Launcher drücken“ Aktivitäten, die im Kern ihrer Aufgaben stehen. In früheren Versionen hat das System würden diese Aktivitäten beim Drücken der Taste „Zurück“ beenden. Unter Android 12 wechselt das System die Aktivität und ihre Aufgabe in den Hintergrund zu übertragen, anstatt die Aktivität abzuschließen. Das neue Verhalten entspricht dem aktuellen Verhalten beim Verlassen einer App. indem Sie die Startbildschirmtaste oder eine Touch-Geste verwenden.

Bei den meisten Apps bedeutet diese Änderung, dass Nutzer, die die Schaltfläche „Zurück“ verwenden, um Ihre App kann sie schneller aus einem Warmzustand fortsetzen, anstatt die App von einem Gerät aus kalt.

Wir empfehlen Ihnen, Ihre Apps mit dieser Änderung zu testen. Wenn Ihre App derzeit onBackPressed() verarbeiten Zurücknavigation und Activity abschließen. Aktualisieren Sie Ihre Implementierung, um folgende URL aufzurufen: bis super.onBackPressed(), anstatt den Vorgang abzuschließen. Anrufen super.onBackPressed() verschiebt die Aktivität und ihre Aufgabe in den Hintergrund, wenn angemessen und bietet eine einheitlichere Navigation für Nutzende. in verschiedenen Apps.

Beachten Sie außerdem, dass wir die AndroidX Activity APIs im Allgemeinen für benutzerdefinierte Zurück-Navigation, anstatt onBackPressed() zu überschreiben. Die AndroidX Activity APIs automatisch dem entsprechenden Systemverhalten folgen, Komponenten, die das System durch Drücken der Taste abfangen.

Grafiken und Bilder

Verbesserter Wechsel der Aktualisierungsrate

In Android 12 ändert sich die Aktualisierungsrate setFrameRate() kann passieren, unabhängig davon, ob die Anzeige einen nahtlosen Übergang zu die neue Aktualisierungsrate, ein nahtloser Übergang ohne visuelle Elemente Unterbrechungen, z. B. wenn ein oder zwei Sekunden lang ein schwarzer Bildschirm angezeigt wird. Wenn die Funktion dass das Display keinen nahtlosen Übergang unterstützt, wird normalerweise weiterhin mit derselben Aktualisierungsrate, nachdem setFrameRate() aufgerufen wurde. Sie können in ob der Übergang zur neuen Aktualisierung wahrscheinlich nahtlos verläuft, getAlternativeRefreshRates() wird aufgerufen. Im Allgemeinen ist der Callback onDisplayChanged() nach Abschluss der Umstellung der Aktualisierungsrate aufgerufen, wird er 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(): Die Nutzungsbedingungen gelten als Passpoint. mit der Netzwerkbereitstellungen unsichere Captive Portale ersetzen können, die offene Netzwerke mit einem sicheren Passpoint-Netzwerk nutzen. Eine Benachrichtigung ist die dem Nutzer angezeigt werden, wenn die Nutzungsbedingungen akzeptiert werden müssen. Apps, die Passpoint-Netzwerke vorschlagen, für die die Nutzungsbedingungen gelten muss 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 herstellen. und es muss ein alternatives oder Legacy-Netzwerk vorgeschlagen werden.

  • isDecoratedIdentitySupported(): Bei der Authentifizierung bei Netzwerken mit einem Präfix-Dekoration Mit dem Identitätspräfix können Netzwerkbetreiber den Netzwerkzugriff ID (NAI), um ein explizites Routing durch mehrere enthaltene Proxys durchzuführen eines AAA-Netzwerks (siehe RFC 7542 für mehr dazu).

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

Um einen Passpoint-Vorschlag zu erstellen, müssen Apps die PasspointConfiguration, Credential und HomeSp Kurse. Diese Klassen beschreiben das Passpoint-Profil, das in der Wi-Fi Alliance definiert ist. Passpoint Spezifikation.

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 mit eingeschränktem Nicht-SDK Benutzeroberflächen basierend auf der Zusammenarbeit mit Android-Entwicklern internen Tests. Wann immer möglich, achten wir darauf, dass öffentliche Alternativen bevor wir Nicht-SDK-Schnittstellen einschränken.

Wenn deine App nicht auf Android 12 ausgerichtet ist, gibt es einige dieser Änderungen nicht sofort betreffen. Obwohl Sie derzeit einige Nicht-SDK-Schnittstellen (abhängig vom Ziel-API-Level Ihrer App) die Verwendung einer Nicht-SDK-Methode oder eines Nicht-SDK-Felds birgt immer ein hohes Risiko, dass Ihre

Wenn Sie sich nicht sicher sind, ob Ihre App Nicht-SDK-Schnittstellen verwendet, können Sie Ihre App um es herauszufinden. Wenn Ihre App Nicht-SDK-Schnittstellen benötigt, sollten Sie mit der Planung eine Migration zu SDK-Alternativen. Dennoch ist uns bewusst, dass einige Apps Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen. Wenn Sie keine Alternative finden für eine Funktion in Ihrer App eine Nicht-SDK-Schnittstelle verwenden, sollten Sie eine neue öffentliche API.

Weitere Informationen zu den Änderungen in dieser Android-Version findest du unter Updates für Einschränkungen für Nicht-SDK-Schnittstellen in Android 12 Weitere Informationen zu Nicht-SDK-Schnittstellen im Allgemeinen siehe Einschränkungen für Nicht-SDK-Schnittstellen Benutzeroberflächen.