Wie bei früheren Releases wurde auch bei Android 12 können sich auf Ihre App auswirken. Die folgenden Verhaltensänderungen gelten ausschließlich für Apps die auf Android 12 oder höher ausgerichtet sind. Wenn Ihre App Wenn deine App auf Android 12 ausgerichtet ist, solltest du deine App so anpassen, dass sie diese Verhaltensweisen unterstützt ordnungsgemäß sein.
Sehen Sie sich auch die Liste der Verhaltensänderungen an, die alle Apps betreffen mit Android 12.
Nutzererfahrung
Benutzerdefinierte Benachrichtigungen
Unter Android 12 werden Aussehen und Verhalten vollständig benutzerdefinierter Benachrichtigungen geändert. Bisher konnte bei benutzerdefinierten Benachrichtigungen der gesamte Benachrichtigungsbereich genutzt werden. und eigene Layouts und Stile festlegen. Dies führte zu Anti-Mustern, die Nutzer verwirren oder Probleme mit der Layoutkompatibilität auf verschiedenen Geräten verursachen.
Für Apps, die auf Android 12 ausgerichtet sind, werden Benachrichtigungen mit benutzerdefinierten Inhaltsansichten nicht
den gesamten Benachrichtigungsbereich nicht mehr nutzen, Stattdessen wendet das System eine Standard-
Vorlage. Diese Vorlage sorgt dafür, dass benutzerdefinierte Benachrichtigungen
wie andere Benachrichtigungen in allen Status, wie das Benachrichtigungssymbol
Erweiterungsmöglichkeiten (im minimierten Zustand) sowie das Symbol der Benachrichtigung
App-Name und minimieren die Angebotsdarstellung (im maximierten Zustand). Dieses Verhalten ist
fast identisch mit dem Verhalten von
Notification.DecoratedCustomViewStyle
So werden in Android 12 alle Benachrichtigungen visuell einheitlich und leicht zu mit einer sichtbaren, bekannten Benachrichtigungserweiterung für Nutzer.
Die folgende Abbildung zeigt eine benutzerdefinierte Benachrichtigung in der Standardvorlage:
Die folgenden Beispiele zeigen, wie benutzerdefinierte Benachrichtigungen in einer minimierten Ansicht gerendert werden. und einen maximierten Zustand:
![](https://developer.android.com/static/images/about/versions/12/custom-collapsed-view.png?authuser=0000&hl=de)
![](https://developer.android.com/static/images/about/versions/12/custom-expanded-view.png?authuser=0000&hl=de)
Die Änderung bei Android 12 betrifft Apps, die benutzerdefinierte abgeleitete Klassen von
Notification.Style
oder verwenden
Methoden von Notification.Builder
setCustomContentView(RemoteViews)
,
setCustomBigContentView(RemoteViews)
und setCustomHeadsUpContentView(RemoteViews)
.
Wenn deine App vollständig benutzerdefinierte Benachrichtigungen verwendet, empfehlen wir, sie mit dem neue Vorlage so schnell wie möglich erstellen.
Aktivieren Sie die Änderung für benutzerdefinierte Benachrichtigungen:
- Ändern Sie die
targetSdkVersion
Ihrer App inS
, um das neue Verhalten zu aktivieren. - Neu kompilieren.
- Installiere deine App auf einem Gerät oder Emulator mit Android 12.
- Ändern Sie die
Teste alle Benachrichtigungen, die benutzerdefinierte Ansichten verwenden, und stelle sicher, dass sie wie du aussehen die Sie im Schatten erwarten. Berücksichtigen Sie beim Testen diese Überlegungen und nehmen Sie die erforderlichen Anpassungen vor:
Die Abmessungen der benutzerdefinierten Ansichten haben sich geändert. Im Allgemeinen ist die Höhe benutzerdefinierte Benachrichtigungen leisten können, ist weniger als zuvor. In der minimierten ist die maximale Höhe des benutzerdefinierten Inhalts von 106 dp gesunken. bis 48 dp. Außerdem ist der horizontale Platz geringer.
Für Apps, die auf Android 12 ausgerichtet sind, können alle Benachrichtigungen maximiert werden. Wenn Sie
setCustomContentView
verwenden, bedeutet das in der Regel Folgendes: sollten Sie auchsetBigCustomContentView
um sicherzustellen, dass minimierte und maximierte Zustände einheitlich sind.Die Schaltfläche „Kopf hoch“ wie erwartet aussieht, denken Sie daran, um die Wichtigkeit des Benachrichtigungskanals auf "HOCH" zu setzen. (Klingelt auf Bildschirm).
Änderungen bei der Bestätigung von Android-App-Links
Bei Apps, die auf Android 12 oder höher ausgerichtet sind, erstellt das System Mehrere Änderungen an der Funktionsweise von Android-App-Links bestätigt. Diese verbessern die Zuverlässigkeit der App-Verknüpfung und bieten die Kontrolle für App-Entwickler und Endnutzer bieten.
Wenn Sie zum Öffnen von Weblinks in Ihrer App die Bestätigung über Android-App-Links
Achten Sie darauf, dass Sie beim Hinzufügen eines Intents
Filter für
Bestätigung von Android-App-Links. Achten Sie insbesondere darauf, dass diese Intents
Filter enthalten die Kategorie BROWSABLE
und unterstützen das Schema https
.
Sie können auch manuell Bestätigen Sie Ihr um die Zuverlässigkeit deiner Erklärungen zu testen.
Verbesserte Funktion von Bild im Bild
Mit Android 12 wurden Verhaltensverbesserungen für den Bild-im-Bild-Modus (BiB) eingeführt. und empfohlene kosmetische Verbesserungen der Übergangsanimationen für beide Navigation und elementbasierte Navigation.
Weitere Informationen findest du unter Bild im Bild. Informationen.
Toast-Neugestaltung
In Android 12 wurde die Toast-Ansicht neu gestaltet. Pop-ups sind jetzt auf zwei Textzeilen beschränkt und zeigen die App. neben dem Text.
![Bild eines Android-Geräts mit Toast-Pop-up
„Nachricht wird gesendet“ neben einem App-Symbol](https://developer.android.com/static/images/toast.png?authuser=0000&hl=de)
Weitere Informationen finden Sie unter Toasts – Übersicht.
Sicherheit und Datenschutz
Ungefährer Standort
Auf Geräten mit Android 12 oder höher können Nutzer ungefährer Standort Genauigkeit für Ihre App ermitteln.
Moderne SameSite-Cookies in WebView
Die WebView-Komponente von Android basiert auf Chromium,
das Open-Source-Projekt, auf dem der Chrome-Browser von Google basiert. Einführung von Chromium
die Handhabung von Drittanbieter-Cookies, um für mehr Sicherheit und
und den Nutzern mehr
Transparenz und Kontrolle bieten. Ab Android 12
Diese Änderungen sind auch in „WebView
“ enthalten, wenn Apps auf
Android 12 (API-Level 31) oder höher
Mit dem Attribut SameSite
eines Cookies wird gesteuert, ob es mit einem beliebigen
oder nur mit Anfragen zur selben Website. Die folgenden Datenschutzmaßnahmen
verbessern den standardmäßigen Umgang mit Drittanbieter-Cookies und tragen dazu bei,
vor unbeabsichtigtem websiteübergreifendem Teilen:
- Cookies ohne
SameSite
-Attribut werden wieSameSite=Lax
behandelt. - Cookies mit
SameSite=None
müssen auch das AttributSecure
enthalten, d. h. erfordern sie einen sicheren Kontext und sollten über HTTPS gesendet werden. - Links zwischen HTTP- und HTTPS-Versionen einer Website werden jetzt als websiteübergreifend behandelt.
-Anforderungen, sodass Cookies nur gesendet werden, wenn sie entsprechend als
SameSite=None; Secure
Für Entwickler ist die allgemeine Richtlinie, das websiteübergreifende Cookie zu identifizieren.
in Ihren kritischen Nutzerabläufen zu berücksichtigen, und achten Sie darauf, dass die SameSite
wird gegebenenfalls explizit mit den entsprechenden Werten festgelegt. Du musst
ausdrücklich angeben, welche Cookies auf Websites oder in
für Navigationen auf derselben Website, die von HTTP zu HTTPS wechseln.
Eine vollständige Anleitung zu diesen Änderungen für Webentwickler finden Sie unter SameSite-Cookies Erklärt und Schemata SameSite
SameSite-Verhalten in Ihrer App testen
Wenn Ihre App WebView verwendet oder Sie eine Website oder einen Dienst verwalten, empfehlen wir, die Abläufe in Android 12 WebView zu testen. Falls Probleme auftreten, müssen Sie möglicherweise Ihre Cookies aktualisieren, um die neue SameSite-Verhaltensweisen.
Achte auf Probleme bei Anmeldungen, eingebetteten Inhalten und Anmeldevorgängen. Authentifizierungsabläufe, bei denen der Nutzer mit einem unsicheren und zu einer sicheren Seite übergeht.
Um eine App mit WebView zu testen, müssen Sie die neuen SameSite-Verhaltensweisen für die App, die Sie testen möchten, indem Sie einen der folgenden Schritte ausführen:
Aktivieren Sie das SameSite-Verhalten auf dem Testgerät manuell durch Umschalten des UI-Flags. WebView-enable-modern-cookie-same-site in den WebView-Entwicklertools.
So kannst du Tests auf jedem Gerät mit Android 5.0 (API-Level 21) durchführen. oder höher (einschließlich Android 12) und WebView Version 89.0.4385.0 oder höher.
Kompiliere deine App bis zum
targetSdkVersion
so, dass sie auf Android 12 (API-Level 31) ausgerichtet ist.Wenn Sie diesen Ansatz nutzen, müssen Sie ein Gerät verwenden, Android 12
Informationen zum Remote-Debugging für WebView unter Android finden Sie unter Erste Schritte mit Remote-Debugging für Android-Geräte.
Weitere Informationen
Weitere Informationen zum aktuellen Verhalten von SameSite und zur Einführung in Chrome und WebView finden Sie unter Chromium SameSite Updates . Wenn Sie einen Fehler in WebView finden oder Chromium melden Sie dies in der öffentlichen Chromium-Seite Tracker.
Bewegungssensoren sind geschwindigkeitsbegrenzt
Zum Schutz potenziell vertraulicher Nutzerdaten, wenn deine App auf Android 12 oder höher hat das System ein Limit für die Aktualisierung Datenfrequenz bestimmter Bewegungs- und Positionssensoren.
Weitere Informationen zum Sensor Ratenbegrenzung.
App-Ruhezustand
Unter Android 12 wird die automatische Zurücksetzung von Berechtigungen erweitert. Verhalten die mit Android 11 (API-Level 30) eingeführt wurde. Wenn Ihre App auf Unter Android 12 interagiert der Nutzer einige Zeit lang nicht mit deiner App gewährt, setzt das System alle erteilten Berechtigungen automatisch zurück und platziert deine App hibernation-Status.
Weitere Informationen finden Sie im Leitfaden zu App-Kampagnen Winterschlaf.
Attributionsdeklaration in der Prüfung des Datenzugriffs
Mit der in Android 11 (API-Level 30) eingeführten API für die Datenzugriffsprüfung können Sie um eine Zuordnung zu erstellen Tags basierend auf Ihren App-Anwendungsfälle. Mithilfe dieser Tags können Sie leichter feststellen, eine bestimmte Art Datenzugriff ausführt.
Wenn deine App auf Android 12 oder höher ausgerichtet ist, musst du diese Attributions-Tags in in der Manifest-Datei Ihrer App.
Einschränkung für ADB-Sicherungen
Zum Schutz privater App-Daten ändert Android 12 das Standardverhalten der
adb backup
-Befehl. Für Apps, die auf Android 12 (API-Level 31) oder höher ausgerichtet sind,
Wenn ein Nutzer den Befehl adb backup
ausführt, werden die App-Daten von allen anderen ausgeschlossen.
Systemdaten, die vom Gerät exportiert werden.
Wenn Ihre Test- oder Entwicklungs-Workflows mit adb backup
auf App-Daten basieren,
können Sie den Export Ihrer App-Daten aktivieren, indem Sie
android:debuggable
true
in der Manifestdatei Ihrer App fest.
Sichererer Export von Komponenten
Wenn Ihre App auf Android 12 oder höher ausgerichtet ist und
Aktivitäten,
services oder broadcast
Empfänger, die Intents verwenden
ändern, müssen Sie explizit
deklarieren:
Attribut android:exported
für diese App-Komponenten.
Enthält die App-Komponente die
Kategorie LAUNCHER
, festgelegt
android:exported
bis true
. In den meisten anderen Fällen setzen Sie android:exported
auf
false
.
Das folgende Code-Snippet zeigt ein Beispiel für einen Dienst, der einen Intent enthält.
Filter, dessen Attribut android:exported
auf false
gesetzt ist:
<service android:name="com.example.app.backgroundService" android:exported="false"> <intent-filter> <action android:name="com.example.app.START_BACKGROUND" /> </intent-filter> </service>
Nachrichten in Android Studio
Wenn Ihre App eine Aktivität, einen Dienst oder einen Übertragungsempfänger enthält, der
Intent-Filter, aber nicht android:exported
deklariert, wird die folgende Warnung
Je nach verwendeter Android Studio-Version werden Nachrichten angezeigt:
Android Studio 2020.3.1 Canary 11 oder höher
Die folgenden Meldungen werden angezeigt:
In der Manifestdatei wird die folgende Lint-Warnung angezeigt:
When using intent filters, please specify android:exported as well
Wenn Sie versuchen, Ihre App zu kompilieren, wird die folgende Build-Fehlermeldung angezeigt: angezeigt:
Manifest merger failed : Apps targeting Android 12 and higher are required \ to specify an explicit value for android:exported when the corresponding \ component has an intent filter defined.
Ältere Versionen von Android Studio
Wenn Sie versuchen, die App zu installieren, Logcat wird folgende Fehlermeldung angezeigt:
Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'
Veränderlichkeit der ausstehenden Intents
Wenn deine App auf Android 12 ausgerichtet ist, musst du die
Veränderlichkeit von
jedes PendingIntent
-Objekts, das im
App erstellt. Diese zusätzliche Anforderung erhöht die Sicherheit Ihrer App.
Ausstehende Änderung der Intent-Veränderlichkeit testen
Wenn Sie herausfinden möchten, ob in Ihrer App Veränderlichkeitsdeklarationen fehlen, suchen Sie nach der folgende Lint-Warnung in Android Studio:
Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]
Einführung unsicherer Intents
Zur Verbesserung der Plattformsicherheit bieten Android 12 und höher Debugging-Funktion zur Erkennung unsicherer Starts von Intents. Wann? das System einen so unsicheren Start erkennt, Verstoß StrictMode tritt auf.
Leistung
Einschränkungen für die Einführung von Diensten im Vordergrund
Apps, die auf Android 12 oder höher ausgerichtet sind, können den Vordergrund nicht starten während der Ausführung im Hintergrund, mit Ausnahme einiger speziellen Cases. Wenn eine App versucht, einen Dienst im Vordergrund zu starten, während sie in der Hintergrund, tritt eine Ausnahme auf (mit Ausnahme der wenigen Sonderfälle).
Nutzen Sie WorkManager, um Termine schnell zu planen und zu starten. Arbeit während die App im Hintergrund läuft. Um zeitkritische Aktionen auszuführen, die starten Sie Dienste im Vordergrund innerhalb einer genauen
Berechtigung „Exakter Alarm“
Um Apps dazu zu ermutigen, Systemressourcen zu schonen, werden Apps, die Android 12 und höher und legen Sie Genau passend Alarme müssen Zugriff auf den Bereich "Wecker und Erinnerungen“ die im Bildschirm Spezieller App-Zugriff angezeigt wird. Systemeinstellungen.
Um Zugriff auf diese spezielle App zu erhalten, fordern Sie den
SCHEDULE_EXACT_ALARM
Berechtigung im Manifest.
Exakte Alarme sollten nur für Funktionen verwendet werden, die für den Nutzer sichtbar sind. Weitere Informationen zum Anwendungsfälle für die Festlegung einer genauen
Verhaltensänderung deaktivieren
Wenn du deine App auf Android 12 vorbereitest, kannst du die Verhaltensänderung in Ihrem Debug-fähigen Build zu deaktivieren, -Variante zu Testzwecken. Führen Sie dazu folgende Schritte aus: eine der folgenden Aufgaben ausführen:
- Wähle auf dem Einstellungsbildschirm Entwickleroptionen die Option App-Kompatibilität Änderungen. Tippe auf dem angezeigten Bildschirm auf den Namen deiner App und schalte sie dann aus REQUIRE_EXACT_ALARM_PERMISSION
Führen Sie in einem Terminalfenster auf Ihrem Entwicklungscomputer den folgenden Befehl aus:
adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
Benachrichtigung zu Einschränkungen auf dem Trampolin
Wenn Nutzende mit Benachrichtigungen erhalten, reagieren einige Apps auf Antippen von Benachrichtigungen durch Starten einer App Komponente, die schließlich den die der Nutzer schließlich sieht und mit denen er interagiert. Diese App-Komponente ist auch als Benachrichtigungstrampolin bezeichnet.
Zur Verbesserung der App-Leistung und Nutzerfreundlichkeit werden Apps, die auf Android 12 oder
können keine Aktivitäten aus Diensten oder
Übertragungsempfänger, die als
Benachrichtigungs-Trampolinen. Mit anderen Worten: Nachdem Nutzende auf eine Benachrichtigung getippt haben,
oder einer Aktionsschaltfläche im
die Benachrichtigung enthält, kann die App
startActivity()
in einem Dienst oder
Broadcast-Empfänger befinden.
Wenn deine App versucht, eine Aktivität von einem Dienst oder Übertragungsempfänger zu starten das als Benachrichtigungs-Trampolin fungiert, verhindert das System, dass die Aktivität und die folgende Meldung wird in Logcat:
Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.
Herausfinden, welche App-Komponenten als Benachrichtigungs-Trampolin fungieren
Wenn du deine App testest, kannst du nach dem Tippen auf eine Benachrichtigung herausfinden, Dienst oder Übertragungsempfänger in Ihrer App als Benachrichtigungstrampolin fungierte. Sehen Sie sich dazu die Ausgabe des folgenden Terminalbefehls an:
adb shell dumpsys activity service \ com.android.systemui/.dump.SystemUIAuxiliaryDumpService
Ein Abschnitt der Ausgabe enthält den Text „NotifInteractionLog“. Dieser Abschnitt enthält die Informationen, die notwendig sind, um die Komponente zu identifizieren, als Ergebnis einer Benachrichtigung.
App aktualisieren
Wenn Ihre App eine Aktivität von einem Dienst oder Übertragungsempfänger startet, der als ein Benachrichtigungs-Trampolin zu öffnen, führen Sie die folgenden Migrationsschritte aus:
- Erstellen Sie ein
PendingIntent
-Objekt, das mit der Aktivität verknüpft ist, die Nutzer sehen, nachdem sie auf das Benachrichtigung. - Verwenden Sie das
PendingIntent
-Objekt, das Sie im vorherigen Schritt erstellt haben. wie Sie Ihre Benachrichtigung.
Um den Ursprung der Aktivität zu identifizieren, z. B. für die Protokollierung,
beim Posten der Benachrichtigung Extras verwenden. Verwenden Sie für das zentralisierte Logging
ActivityLifecycleCallbacks
oder Jetpack-Lebenszyklus-Beobachter.
Verhalten aktivieren/deaktivieren
Wenn du eine debugfähige Version deiner App testest, kannst du diese Funktion aktivieren oder deaktivieren
Einschränkung mit dem App-Kompatibilitäts-Flag NOTIFICATION_TRAMPOLINE_BLOCK
.
Back-up und Wiederherstellung
Änderungen an der Funktionsweise von Sichern und Wiederherstellen in Apps, die auf Android 12 (API-Level 31). Es gibt zwei Formen der Android-Sicherung und -Wiederherstellung:
- Cloud-Sicherungen:Nutzerdaten werden im Google Drive-Konto eines Nutzers gespeichert, damit sie kann später auf diesem oder einem neuen Gerät wiederhergestellt werden.
- D2D-Übertragungen (Gerät-zu-Gerät):Nutzerdaten werden direkt an das das neue Gerät des Nutzers von seinem älteren Gerät zu übertragen, z. B. per Kabel.
Weitere Informationen dazu, wie Daten gesichert und wiederhergestellt werden, finden Sie unter Nutzer sichern mit der automatischen Sicherung und Schlüssel/Wert-Paare sichern mit Android Backup Service
Änderungen an der D2D-Übertragungsfunktion
Für Apps, die auf Android 12 und höher laufen und darauf ausgerichtet sind:
Regeln zum Einschließen und Ausschließen mit der XML-Datei der Konfigurationsmechanismus keine Auswirkungen auf D2D-Übertragungen hat, wirkt sich auf die cloudbasierte Sicherung und Wiederherstellung aus (z. B. Google Drive-Sicherungen). Bis Regeln für D2D-Übertragungen angeben, müssen Sie die neue im nächsten Abschnitt.
Auf Geräten von einigen Geräteherstellern kann
android:allowBackup="false"
deaktiviert Sicherungen in Google Drive, aber wird die D2D-Übertragung für die App nicht deaktiviert.
Neues Format zum Einschließen und Ausschließen
Apps, die auf Android 12 und höher laufen und darauf ausgerichtet sind, verwenden ein Format für die XML-Konfiguration. Dieses Format macht den Unterschied zwischen Google Drive-Sicherung und D2D-Übertragung explizit, indem Sie Separate Ein- und Ausschlussregeln für Cloud-Sicherungen und D2D festlegen übertragen werden.
Optional können Sie es auch verwenden, um Regeln für die Sicherung anzugeben. In diesem Fall wird der zuvor verwendete Konfiguration auf Geräten mit Android 12 oder höher liegen. Die ältere Konfiguration ist für Geräte mit Android 11 weiterhin erforderlich oder niedriger.
Änderungen am XML-Format
Das folgende Format wird für die Sicherungs- und Wiederherstellungskonfiguration in Android verwendet 11 und niedriger:
<full-backup-content> <include domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string" requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] /> <exclude domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string" /> </full-backup-content>
Im Folgenden sehen Sie die Änderungen im Format in Fettdruck.
<data-extraction-rules> <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]> ... <include domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string"/> ... <exclude domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string"/> ... </cloud-backup> <device-transfer> ... <include domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string"/> ... <exclude domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string"/> ... </device-transfer> </data-extraction-rules>
Weitere Informationen finden Sie im entsprechenden Abschnitt in die Anleitung zum Sichern von Nutzerdaten mit der automatischen Sicherung.
Manifest-Flag für Apps
Weisen Sie Ihre Apps mithilfe des
Attribut android:dataExtractionRules
in Ihrem Manifest
-Datei. Wenn Sie auf die neue XML-Konfiguration verweisen,
Das android:fullBackupContent
-Attribut, das auf die alte Konfiguration verweist, wird ignoriert.
auf Geräten mit Android 12 oder höher. Das folgende Codebeispiel zeigt das neue
Einträge in der Manifestdatei:
<application ... <!-- The below attribute is ignored. --> android:fullBackupContent="old_config.xml" <!-- You can point to your new configuration using the new dataExtractionRules attribute . --> android:dataExtractionRules="new_config.xml" ...> </application>
Konnektivität
Bluetooth-Berechtigungen
Mit Android 12 wird die
BLUETOOTH_SCAN
,
BLUETOOTH_ADVERTISE
,
und
BLUETOOTH_CONNECT
Berechtigungen. Diese Berechtigungen erleichtern es Apps,
Android 12 zur Interaktion mit Bluetooth
, insbesondere für Apps, die keine
benötigen Zugriff auf den Gerätestandort.
Um Ihr Gerät für die Ausrichtung auf Android 12 oder höher vorzubereiten, aktualisieren Sie der App-Logik. Anstatt einen alten Bluetooth-Satz zu deklarieren Berechtigungen ein moderneres Bluetooth-Gerät Berechtigungen
Gleichzeitige Peer-to-Peer- und Internetverbindung
Bei Apps, die auf Android 12 (API-Level 31) oder höher ausgerichtet sind, werden Geräte, die den Die gleichzeitige Verwendung von Peer-to-Peer und Internetverbindungen ermöglicht das gleichzeitige Verwenden von mit dem Peer-Gerät und dem primären Netzwerk, das das Internet bereitstellt, und sorgt so für eine nahtlose User Experience. App-Targeting Unter Android 11 (API-Level 30) oder niedriger tritt weiterhin das alte Verhalten auf, bei dem Das primäre WLAN wird getrennt, bevor eine Verbindung zum Peer hergestellt wird. .
Kompatibilität
WifiManager.getConnectionInfo()
kann WifiInfo
für
nur ein einziges Netzwerk. Aus diesem Grund wurde das Verhalten der API
auf folgende Arten in Android 12 und höher:
- Wenn nur ein einziges WLAN verfügbar ist, wird
WifiInfo
zurückgegeben. - Wenn mehrere WLANs verfügbar sind und die Anruf-App eine
Peer-to-Peer-Verbindung ist der
WifiInfo
, der dem Peer-Gerät entspricht, zurückgegeben. - Wenn mehr als ein WLAN verfügbar ist und die Anruf-App nicht
eine Peer-to-Peer-Verbindung auslösen, wird der
WifiInfo
wird zurückgegeben.
Um die Nutzerfreundlichkeit auf Geräten zu verbessern, die die gleichzeitige Verwendung von zwei Teilnehmern unterstützen
WLANs empfehlen wir alle Apps – insbesondere solche, die
Peer-to-Peer-Verbindungen: Migration weg von Aufrufen
WifiManager.getConnectionInfo()
und verwenden Sie stattdessen
NetworkCallback.onCapabilitiesChanged()
, um alle WifiInfo
-Objekte abzurufen, die mit dem NetworkRequest
übereinstimmen, der für die Registrierung verwendet wurde
NetworkCallback
. „getConnectionInfo()
“ wurde verworfen am
Android 12
Das folgende Codebeispiel zeigt, wie Sie die WifiInfo
in einem
NetworkCallback
:
Kotlin
val networkCallback = object : ConnectivityManager.NetworkCallback() { ... override fun onCapabilitiesChanged( network : Network, networkCapabilities : NetworkCapabilities) { val transportInfo = networkCapabilities.getTransportInfo() if (transportInfo !is WifiInfo) return val wifiInfo : WifiInfo = transportInfo ... } }
Java
final NetworkCallback networkCallback = new NetworkCallback() { ... @Override public void onCapabilitiesChanged( Network network, NetworkCapabilities networkCapabilities) { final TransportInfo transportInfo = networkCapabilities.getTransportInfo(); if (!(transportInfo instanceof WifiInfo)) return; final WifiInfo wifiInfo = (WifiInfo) transportInfo; ... } ... };
Native mDNSReplyer API
Unter Android 12 können Apps mit dem mDNSReplyer-Daemon über
der nativen mDNSReplyer API
Zuvor, wenn eine App einen Dienst im Netzwerk registriert hat
und die getSystemService()
gestartet, hat der NSD-Dienst des Systems den mDNSReplyer-Daemon gestartet, auch wenn der
App noch keine NsdManager
-Methoden aufgerufen hat. Der Daemon hat dann
an die Multicast-Gruppen für alle Knoten, wodurch das System
und zusätzlich Strom verbrauchen. In Android 12 die Akkunutzung minimieren
und höher startet das System den mDNSReplyer-Daemon nur bei Bedarf
für NSD-Ereignisse und stoppt es anschließend.
Da sich diese Änderung darauf auswirkt,
wann der mDNSReplyer-Daemon verfügbar ist,
die davon ausgehen, dass der mDNSReplyer-Daemon nach dem Aufruf der
Die Methode getSystemService()
kann Nachrichten vom System empfangen, die angeben, dass
Der mDNSReplyer-Daemon ist nicht verfügbar. Apps, die NsdManager
verwenden, aber nicht
die native mDNSReplyer API verwenden, sind von dieser Änderung nicht betroffen.
Anbieterbibliotheken
Vom Anbieter bereitgestellte native gemeinsam genutzte Bibliotheken
Native gemeinsam genutzte Bibliotheken ohne NDK
die von Siliziumanbietern oder Geräteherstellern bereitgestellt werden,
standardmäßig, wenn die App auf Android 12 (API-Level 31) oder höher ausgerichtet ist. Die
Bibliotheken sind nur zugänglich, wenn sie explizit mithilfe der Methode
<uses-native-library>
Tag.
Wenn die App auf Android 11 (API-Level 30) oder niedriger ausgerichtet ist,
<uses-native-library>
-Tag ist nicht erforderlich. In diesem Fall können alle
auf die Bibliothek zugegriffen werden kann, unabhängig davon, ob es sich um eine NDK-Bibliothek handelt.
Nicht-SDK-Einschränkungen 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.