Wie bei früheren Releases enthält Android 12 Verhaltensänderungen, die sich auf Ihre App auswirken können. Die folgenden Verhaltensänderungen gelten ausschließlich für Apps, die auf Android 12 oder höher ausgerichtet sind. Wenn Ihre App auf Android 12 ausgerichtet ist, sollten Sie sie gegebenenfalls so ändern, dass sie diese Funktionen korrekt unterstützt.
Lesen Sie sich auch die Liste der Verhaltensänderungen durch, die sich auf alle Apps auswirken, die auf Android 12 ausgeführt werden.
Nutzererfahrung
Benutzerdefinierte Benachrichtigungen
In Android 12 ändern sich das Erscheinungsbild und das Verhalten vollständig benutzerdefinierter Benachrichtigungen. Bisher konnten benutzerdefinierte Benachrichtigungen den gesamten Benachrichtigungsbereich nutzen und eigene Layouts und Stile verwenden. Dies führte zu Anti-Mustern, die Nutzer verwirren oder Layoutkompatibilitätsprobleme auf verschiedenen Geräten verursachen können.
Bei Apps, die auf Android 12 ausgerichtet sind, wird für Benachrichtigungen mit benutzerdefinierten Inhaltsansichten nicht mehr der gesamte Benachrichtigungsbereich verwendet. Stattdessen wendet das System eine Standardvorlage an. Mit dieser Vorlage haben benutzerdefinierte Benachrichtigungen in allen Status dieselben visuellen Elemente wie andere Benachrichtigungen, z. B. das Symbol und die Option zum Maximieren der Benachrichtigung (im minimierten Zustand) sowie das Symbol, den App-Namen und die Option zum Minimieren der Benachrichtigung (im maximierten Zustand). Dieses Verhalten entspricht nahezu dem von Notification.DecoratedCustomViewStyle.
So sind alle Benachrichtigungen in Android 12 visuell einheitlich und leicht zu überfliegen. Außerdem ist die Benachrichtigungserweiterung für Nutzer gut sichtbar und vertraut.
Die folgende Abbildung zeigt eine benutzerdefinierte Benachrichtigung in der Standardvorlage:
Die folgenden Beispiele zeigen, wie benutzerdefinierte Benachrichtigungen im minimierten und im maximierten Zustand dargestellt werden:
Die Änderung in Android 12 wirkt sich auf Apps aus, die benutzerdefinierte Unterklassen von Notification.Style definieren oder die Methoden setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews) und setCustomHeadsUpContentView(RemoteViews) von Notification.Builder verwenden.
Wenn in Ihrer App vollständig benutzerdefinierte Benachrichtigungen verwendet werden, empfehlen wir Ihnen, so bald wie möglich mit der neuen Vorlage zu testen.
Aktivieren Sie die Änderung für benutzerdefinierte Benachrichtigungen:
- Ändern Sie die
targetSdkVersionIhrer App inS, um das neue Verhalten zu aktivieren. - Kompilieren Sie die Datei noch einmal.
- Installieren Sie Ihre App auf einem Gerät oder Emulator mit Android 12.
- Ändern Sie die
Testen Sie alle Benachrichtigungen, für die benutzerdefinierte Ansichten verwendet werden, und achten Sie darauf, dass sie im Dunkeln wie erwartet aussehen. Berücksichtigen Sie beim Testen die folgenden Aspekte und nehmen Sie die erforderlichen Anpassungen vor:
Die Dimensionen von benutzerdefinierten Ansichten haben sich geändert. Im Allgemeinen ist die Höhe von benutzerdefinierten Benachrichtigungen geringer als zuvor. Im minimierten Zustand wurde die maximale Höhe der benutzerdefinierten Inhalte von 106 dp auf 48 dp reduziert. Außerdem ist weniger horizontale Fläche verfügbar.
Alle Benachrichtigungen sind für Apps, die auf Android 12 ausgerichtet sind, erweiterbar. Wenn Sie also
setCustomContentViewverwenden, sollten Sie in der Regel auchsetBigCustomContentViewverwenden, damit der minimierte und maximierte Zustand einheitlich ist.Damit der Status „Heads Up“ wie erwartet angezeigt wird, müssen Sie die Wichtigkeit des Benachrichtigungskanals auf „HOCH“ (Pop-up auf dem Display) setzen.
Änderungen bei der Überprüfung von Android-App-Links
Bei Apps, die auf Android 12 oder höher ausgerichtet sind, nimmt das System mehrere Änderungen an der Bestätigung von Android App-Links vor. Diese Änderungen verbessern die Zuverlässigkeit der App-Verknüpfung und bieten App-Entwicklern und Endnutzern mehr Kontrolle.
Wenn Sie die Android App Link-Bestätigung zum Öffnen von Weblinks in Ihrer App verwenden, achten Sie darauf, das richtige Format zu verwenden, wenn Sie Intent-Filter für die Android App Link-Bestätigung hinzufügen. Achten Sie insbesondere darauf, dass diese Intent-Filter die Kategorie BROWSABLE enthalten und das https-Schema unterstützen.
Sie können die Links Ihrer App auch manuell überprüfen, um die Zuverlässigkeit Ihrer Erklärungen zu testen.
Verbesserungen beim Verhalten von Bild-im-Bild
In Android 12 wurden Verhaltensverbesserungen für den Bild-im-Bild-Modus (PiP) eingeführt. Außerdem werden kosmetische Verbesserungen an Übergangsanimationen für die Gesten- und elementbasierte Navigation empfohlen.
Weitere Informationen finden Sie unter Verbesserungen beim Bild-im-Bild-Modus.
Neugestaltung von Toasts
In Android 12 wurde die Toast-Ansicht neu gestaltet. Toasts sind jetzt auf zwei Textzeilen beschränkt und neben dem Text wird das Symbol der App angezeigt.
Weitere Informationen finden Sie unter Toasts.
Sicherheit und Datenschutz
Ungefährer Standort
Auf Geräten mit Android 12 oder höher können Nutzer eine ungefähre Standortgenauigkeit für Ihre App anfordern.
Moderne SameSite-Cookies in WebView
Die WebView-Komponente von Android basiert auf Chromium, dem Open-Source-Projekt, das den Chrome-Browser von Google unterstützt. In Chromium wurden Änderungen am Umgang mit Drittanbieter-Cookies vorgenommen, um für mehr Sicherheit und Datenschutz zu sorgen und Nutzern mehr Transparenz und Kontrolle zu bieten. Ab Android 12 sind diese Änderungen auch in WebView enthalten, wenn Apps auf Android 12 (API-Level 31) oder höher ausgerichtet sind.
Das SameSite-Attribut eines Cookies steuert, ob es mit allen Anfragen oder nur mit Anfragen innerhalb der Website gesendet werden kann. Die folgenden datenschutzfreundlichen Änderungen verbessern die Standardbehandlung von Drittanbieter-Cookies und schützen vor unbeabsichtigter websiteübergreifender Weitergabe:
- Cookies ohne
SameSite-Attribut werden alsSameSite=Laxbehandelt. - Für Cookies mit
SameSite=Nonemuss auch dasSecure-Attribut angegeben werden. Das bedeutet, dass sie einen sicheren Kontext erfordern und über HTTPS gesendet werden sollten. - Links zwischen HTTP- und HTTPS-Versionen einer Website werden jetzt als websiteübergreifende Anfragen behandelt. Cookies werden also nur gesendet, wenn sie entsprechend als
SameSite=None; Securegekennzeichnet sind.
Entwickler sollten die websiteübergreifenden Cookie-Abhängigkeiten in Ihren kritischen Nutzerflüssen identifizieren und dafür sorgen, dass das SameSite-Attribut bei Bedarf explizit mit den entsprechenden Werten festgelegt wird. Sie müssen die Cookies, die websiteübergreifend oder für Navigationen innerhalb einer Website zulässig sind, die von HTTP zu HTTPS wechseln, explizit angeben.
Ausführliche Informationen zu diesen Änderungen für Webentwickler finden Sie unter SameSite-Cookies und Schemeful SameSite.
SameSite-Verhalten in Ihrer App testen
Wenn Ihre App WebView verwendet oder Sie eine Website oder einen Dienst verwalten, der Cookies verwendet, empfehlen wir Ihnen, Ihre Abläufe in der WebView von Android 12 zu testen. Falls Probleme auftreten, müssen Sie Ihre Cookies möglicherweise aktualisieren, um die neuen SameSite-Verhaltensweisen zu unterstützen.
Achten Sie auf Probleme bei Anmeldungen und eingebetteten Inhalten sowie bei Anmeldeabläufen, Käufen und anderen Authentifizierungsabläufen, bei denen der Nutzer auf einer unsicheren Seite beginnt und zu einer sicheren Seite wechselt.
Wenn Sie eine App mit WebView testen möchten, müssen Sie die neuen SameSite-Verhaltensweisen für die App aktivieren, die Sie testen möchten. Führen Sie dazu einen der folgenden Schritte aus:
Aktivieren Sie das SameSite-Verhalten manuell auf dem Testgerät, indem Sie das UI-Flag „webview-enable-modern-cookie-same-site“ in den WebView-DevTools aktivieren.
Mit diesem Ansatz können Sie auf jedem Gerät mit Android 5.0 (API-Level 21) oder höher – einschließlich Android 12 – und WebView-Version 89.0.4385.0 oder höher testen.
Kompilieren Sie Ihre App bis zum
targetSdkVersionso, dass sie auf Android 12 (API-Level 31) ausgerichtet ist.Wenn Sie diesen Ansatz verwenden, müssen Sie ein Gerät mit Android 12 verwenden.
Informationen zum Remote-Debugging für WebView auf Android-Geräten finden Sie unter Einstieg in das Remote-Debugging auf Android-Geräten.
Weitere Informationen
Weitere Informationen zu den modernen SameSite-Verhaltensweisen und zum Roll-out in Chrome und WebView finden Sie auf der Seite mit Chromium-SameSite-Updates. Wenn Sie einen Fehler in WebView oder Chromium finden, können Sie ihn im öffentlichen Chromium-Problem-Tracker melden.
Bewegungssensoren sind ratenbegrenzt
Zum Schutz potenziell vertraulicher Daten von Nutzern schränkt das System die Aktualisierungsrate von Daten bestimmter Bewegungs- und Positionssensoren ein, wenn Ihre App auf Android 12 oder höher ausgerichtet ist.
Weitere Informationen zur Begrenzung der Sensorrate
App-Ruhezustand
Android 12 erweitert das Verhalten beim automatischen Zurücksetzen von Berechtigungen, das in Android 11 (API-Level 30) eingeführt wurde. Wenn Ihre App auf Android 12 ausgerichtet ist und der Nutzer einige Monate lang nicht mit Ihrer App interagiert, setzt das System alle erteilten Berechtigungen automatisch zurück und versetzt Ihre App in den Ruhemodus.
Weitere Informationen zur App-Ruhezustandsverwaltung finden Sie im Leitfaden.
Erklärung zur Attribution bei der Prüfung des Datenzugriffs
Mit der Data Access Auditing API, die in Android 11 (API-Ebene 30) eingeführt wurde, können Sie Attributions-Tags basierend auf den Anwendungsfällen Ihrer App erstellen. Mit diesen Tags können Sie leichter feststellen, welcher Teil Ihrer App einen bestimmten Datenzugriff ausführt.
Wenn Ihre App auf Android 12 oder höher ausgerichtet ist, müssen Sie diese Attributions-Tags in der Manifestdatei Ihrer App deklarieren.
Einschränkung der ADB-Sicherung
Zum Schutz privater App-Daten wird in Android 12 das Standardverhalten des Befehls adb backup geändert. Bei Apps, die auf Android 12 (API-Level 31) oder höher ausgerichtet sind, werden App-Daten beim Ausführen des Befehls adb backup von allen anderen Systemdaten ausgeschlossen, die vom Gerät exportiert werden.
Wenn Ihre Test- oder Entwicklungsabläufe auf App-Daten mit adb backup basieren, können Sie jetzt den Export der App-Daten aktivieren. Dazu müssen Sie in der Manifestdatei Ihrer App android:debuggable auf true festlegen.
Sichererer Export von Komponenten
Wenn Ihre App auf Android 12 oder höher ausgerichtet ist und Aktivitäten, Dienste oder Broadcastempfänger enthält, die Intent-Filter verwenden, müssen Sie das Attribut android:exported für diese App-Komponenten explizit deklarieren.
Wenn die App-Komponente die Kategorie LAUNCHER enthält, setzen Sie android:exported auf true. In den meisten anderen Fällen setzen Sie android:exported auf false.
Das folgende Code-Snippet zeigt ein Beispiel für einen Dienst mit einem Intent-Filter, dessen android:exported-Attribut auf false festgelegt 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 Broadcast-Empfänger enthält, der Intent-Filter verwendet, aber android:exported nicht deklariert, werden je nach verwendeter Android Studio-Version die folgenden Warnmeldungen angezeigt:
Android Studio 2020.3.1 Canary 11 oder höher
Die folgenden Meldungen werden angezeigt:
In Ihrer Manifestdatei wird die folgende Lint-Warnung angezeigt:
When using intent filters, please specify android:exported as wellWenn Sie versuchen, Ihre App zu kompilieren, wird die folgende Build-Fehlermeldung 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, wird in Logcat die 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änderbarkeit von ausstehenden Intents
Wenn Ihre App auf Android 12 ausgerichtet ist, müssen Sie die Veränderlichkeit jedes PendingIntent-Objekts angeben, das von Ihrer App erstellt wird. Diese zusätzliche Anforderung trägt zur Sicherheit Ihrer App bei.
Änderung der Veränderlichkeit von PendingIntents testen
Ob in Ihrer App Deklarationen zur Veränderlichkeit fehlen, erkennen Sie an der folgenden Lint-Warnung in Android Studio:
Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]
Unsichere Intent-Ausführungen
Zur Verbesserung der Plattformsicherheit bieten Android 12 und höher eine Debug-Funktion, mit der unsichere Intent-Ausführungen erkannt werden. Wenn das System einen solchen unsicheren Start erkennt, liegt ein StrictMode-Verstoß vor.
Leistung
Launch-Beschränkungen für Dienste im Vordergrund
Apps, die auf Android 12 oder höher ausgerichtet sind, können Dienste im Vordergrund nicht starten, während sie im Hintergrund ausgeführt werden, außer in einigen Sonderfällen. Wenn eine App versucht, einen Dienst im Vordergrund zu starten, während sie im Hintergrund ausgeführt wird, wird eine Ausnahme ausgelöst (außer in wenigen Sonderfällen).
Sie können WorkManager verwenden, um Beschleunigte Aufgaben zu planen und zu starten, während Ihre App im Hintergrund ausgeführt wird. Wenn Sie zeitkritische Aktionen ausführen möchten, die vom Nutzer angefordert werden, starten Sie Dienste im Vordergrund innerhalb eines genauen Weckers.
Berechtigung „Exakter Alarm“
Um Apps zu ermutigen, Systemressourcen zu schonen, müssen Apps, die auf Android 12 und höher ausgerichtet sind und genaue Wecker stellen, auf die Funktion „Wecker und Erinnerungen“ zugreifen können. Diese Funktion wird in den Systemeinstellungen auf dem Bildschirm Spezielle App-Zugriffe angezeigt.
Wenn Sie diesen speziellen App-Zugriff erhalten möchten, müssen Sie die Berechtigung SCHEDULE_EXACT_ALARM im Manifest anfordern.
Genaue Wecker sollten nur für nutzerorientierte Funktionen verwendet werden. Weitere Informationen zu zulässigen Anwendungsfällen für die Einstellung eines genauen Weckers
Verhaltensänderung deaktivieren
Wenn Sie Ihre App für Android 12 vorbereiten, können Sie die Verhaltensänderung in Ihrer debuggbaren Buildvariante zu Testzwecken vorübergehend deaktivieren. Führen Sie dazu eine der folgenden Aufgaben aus:
- Wählen Sie auf dem Einstellungsbildschirm Entwickleroptionen die Option Änderungen an der App-Kompatibilität aus. Tippen Sie auf dem angezeigten Bildschirm auf den Namen Ihrer App und deaktivieren Sie dann 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
Einschränkungen für Trampolinbenachrichtigungen
Wenn Nutzer mit Benachrichtigungen interagieren, starten einige Apps beim Tippen auf eine Benachrichtigung eine App-Komponente, die schließlich die Aktivität startet, die der Nutzer sieht und mit der er interagiert. Diese App-Komponente wird als Benachrichtigungs-Trampolin bezeichnet.
Um die App-Leistung und die Nutzerfreundlichkeit zu verbessern, können Apps, die auf Android 12 oder höher ausgerichtet sind, keine Aktivitäten über Dienste oder Übertragungsempfänger starten, die als Trampoline für Benachrichtigungen verwendet werden. Wenn der Nutzer also auf eine Benachrichtigung oder eine Aktionsschaltfläche in der Benachrichtigung tippt, darf Ihre App startActivity() nicht innerhalb eines Dienstes oder Broadcasters aufrufen.
Wenn Ihre App versucht, eine Aktivität über einen Dienst oder Broadcast-Empfänger zu starten, der als Trampolin für Benachrichtigungen dient, verhindert das System den Start der Aktivität und die folgende Meldung wird in Logcat angezeigt:
Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.
Identifizieren Sie die App-Komponenten, die als Trampoline für Benachrichtigungen dienen.
Wenn Sie Ihre App testen, können Sie nach dem Tippen auf eine Benachrichtigung ermitteln, welcher Dienst oder Broadcast-Empfänger als Trampolin für Benachrichtigungen in Ihrer App diente. 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 erforderlich sind, um die Komponente zu identifizieren, die durch Tippen auf eine Benachrichtigung gestartet wird.
App aktualisieren
Wenn Ihre App eine Aktivität über einen Dienst oder Broadcast-Empfänger startet, der als Trampolin für Benachrichtigungen dient, führen Sie die folgenden Migrationsschritte aus:
- Erstelle ein
PendingIntent-Objekt, das mit der Aktivität verknüpft ist, die Nutzer sehen, nachdem sie auf die Benachrichtigung getippt haben. - Verwenden Sie das
PendingIntent-Objekt, das Sie im vorherigen Schritt erstellt haben, um die Benachrichtigung zu erstellen.
Wenn Sie den Ursprung der Aktivität ermitteln möchten, um beispielsweise Protokolle zu erstellen, verwenden Sie beim Posten der Benachrichtigung Extras. Verwenden Sie für die zentrale Protokollierung ActivityLifecycleCallbacks oder Jetpack-Lebenszyklus-Beobachter.
Verhalten umschalten
Wenn Sie eine debugfähige Version Ihrer App testen, können Sie diese Einschränkung mit dem App-Kompatibilitätsflag NOTIFICATION_TRAMPOLINE_BLOCK aktivieren und deaktivieren.
Back-up und Wiederherstellung
Die Funktionsweise von Sicherung und Wiederherstellung in Apps, die auf Android 12 (API-Level 31) ausgeführt werden und darauf ausgerichtet sind, hat sich geändert. Die Sicherung und Wiederherstellung von Android hat zwei Formen:
- Cloud-Sicherungen:Nutzerdaten werden in Google Drive des Nutzers gespeichert, damit sie später auf diesem Gerät oder einem neuen Gerät wiederhergestellt werden können.
- Geräteübergreifende Übertragung (Device-to-Device, D2D): Nutzerdaten werden direkt von ihrem alten Gerät an das neue Gerät des Nutzers gesendet, z. B. über ein Kabel.
Weitere Informationen zum Sichern und Wiederherstellen von Daten finden Sie unter Nutzerdaten mit der automatischen Sicherung sichern und Schlüssel/Wert-Paare mit dem Android-Sicherungsservice sichern.
Änderungen bei der D2D-Übertragungsfunktion
Für Apps, die auf Android 12 und höher ausgeführt werden und darauf ausgerichtet sind:
Die Angabe von Einschluss- und Ausschlussregeln mit dem XML-Konfigurationsmechanismus hat keine Auswirkungen auf D2D-Übertragungen, wirkt sich aber auf die cloudbasierte Sicherung und Wiederherstellung aus (z. B. Google Drive-Sicherungen). Wenn Sie Regeln für D2D-Übertragungen angeben möchten, müssen Sie die neue Konfiguration verwenden, die im nächsten Abschnitt beschrieben wird.
Auf Geräten einiger Gerätehersteller werden durch die Angabe von
android:allowBackup="false"zwar die Sicherungen in Google Drive deaktiviert, aber nicht die D2D-Übertragungen für die App.
Neues Format für Ein- und Ausschluss
Für Apps, die auf Android 12 oder höher ausgeführt werden und auf diese Version ausgerichtet sind, wird ein anderes Format für die XML-Konfiguration verwendet. Bei diesem Format wird der Unterschied zwischen Google Drive-Sicherung und D2D-Übertragung deutlich gemacht, da Sie Einschluss- und Ausschlussregeln für Cloud-Sicherungen und D2D-Übertragungen separat angeben müssen.
Optional können Sie damit auch Regeln für die Sicherung angeben. In diesem Fall wird die zuvor verwendete Konfiguration auf Geräten mit Android 12 oder höher ignoriert. Die ältere Konfiguration ist weiterhin für Geräte mit Android 11 oder niedriger erforderlich.
Änderungen am XML-Format
Das folgende Format wird für die Sicherungs- und Wiederherstellungskonfiguration in Android 11 und niedriger verwendet:
<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 sind die Formatänderungen fett dargestellt.
<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 des Leitfadens zum Sichern von Nutzerdaten mit der automatischen Sicherung.
Manifest-Flag für Apps
Weisen Sie Ihre Apps mit dem Attribut android:dataExtractionRules in Ihrer Manifestdatei auf die neue XML-Konfiguration hin. Wenn Sie auf die neue XML-Konfiguration verweisen, wird das Attribut android:fullBackupContent, das auf die alte Konfiguration verweist, auf Geräten mit Android 12 oder höher ignoriert. Das folgende Codebeispiel zeigt die neuen Manifestdateieinträge:
<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
In Android 12 werden die Berechtigungen BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE und BLUETOOTH_CONNECT eingeführt. Mit diesen Berechtigungen können Apps, die auf Android 12 ausgerichtet sind, einfacher mit Bluetooth-Geräten interagieren, insbesondere für Apps, für die kein Zugriff auf den Gerätestandort erforderlich ist.
Aktualisieren Sie die Logik Ihrer App, um Ihr Gerät auf die Ausrichtung auf Android 12 oder höher vorzubereiten. Anstatt eine alte Bluetooth-Berechtigungsgruppe zu deklarieren, sollten Sie eine modernere Bluetooth-Berechtigungsgruppe deklarieren.
Gleichzeitige Peer-to-Peer- und Internetverbindung
Bei Apps, die auf Android 12 (API-Level 31) oder höher ausgerichtet sind, können Geräte, die gleichzeitige Peer-to-Peer- und Internetverbindungen unterstützen, gleichzeitige WLAN-Verbindungen sowohl zum Peer-Gerät als auch zum primären Internetanbieternetzwerk aufrechterhalten, was die Nutzerfreundlichkeit erhöht. Bei Apps, die auf Android 11 (API-Level 30) oder niedriger ausgerichtet sind, tritt weiterhin das alte Verhalten auf, bei dem die Verbindung zum primären WLAN getrennt wird, bevor eine Verbindung zum Peer-Gerät hergestellt wird.
Kompatibilität
WifiManager.getConnectionInfo() kann die WifiInfo nur für ein einzelnes Netzwerk zurückgeben. Daher wurde das Verhalten der API unter Android 12 und höher auf folgende Weise geändert:
- Wenn nur ein WLAN verfügbar ist, wird dessen
WifiInfozurückgegeben. - Wenn mehrere WLANs verfügbar sind und die anrufende App eine Peer-to-Peer-Verbindung ausgelöst hat, wird die
WifiInfozurückgegeben, die dem Peer-Gerät entspricht. - Wenn mehrere WLANs verfügbar sind und die Anruf-App keine Peer-to-Peer-Verbindung ausgelöst hat, wird die
WifiInfoder primären Internetverbindung zurückgegeben.
Für eine bessere Nutzererfahrung auf Geräten, die zwei gleichzeitige WLANs unterstützen, empfehlen wir allen Apps – insbesondere solchen, die Peer-to-Peer-Verbindungen auslösen –, den Aufruf von WifiManager.getConnectionInfo() zu beenden und stattdessen NetworkCallback.onCapabilitiesChanged() zu verwenden, um alle WifiInfo-Objekte abzurufen, die mit der NetworkRequest übereinstimmen, die zum Registrieren der NetworkCallback verwendet wurde. getConnectionInfo() wird ab Android 12 nicht mehr unterstützt.
Im folgenden Codebeispiel wird gezeigt, wie Sie die WifiInfo in einer NetworkCallback abrufen:
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 mDNSResponder API
Unter Android 12 können Apps nicht mehr über die native mDNSResponder API mit dem mDNSResponder-Daemon interagieren.
Bisher wurde der mDNSResponder-Daemon vom NSD-Dienst des Systems gestartet, wenn eine App einen Dienst im Netzwerk registriert und die Methode getSystemService() aufgerufen hat, auch wenn die App noch keine NsdManager-Methoden aufgerufen hatte. Der Daemon hat das Gerät dann für die Multicast-Gruppen aller Knoten abonniert, wodurch das System häufiger geweckt wurde und mehr Strom verbraucht hat. Um die Akkunutzung zu minimieren, startet das System unter Android 12 und höher den mDNSResponder-Daemon nur dann, wenn er für NSD-Ereignisse benötigt wird, und beendet ihn danach.
Da sich diese Änderung darauf auswirkt, wann der mDNSResponder-Daemon verfügbar ist, erhalten Apps, die davon ausgehen, dass der mDNSResponder-Daemon nach dem Aufrufen der getSystemService()-Methode gestartet wird, möglicherweise vom System die Meldung, dass der mDNSResponder-Daemon nicht verfügbar ist. Apps, die NsdManager verwenden und nicht die native mDNSResponder API, sind von dieser Änderung nicht betroffen.
Anbieterbibliotheken
Vom Anbieter bereitgestellte native gemeinsam genutzte Bibliotheken
Auf nicht-NDK-native freigegebene Bibliotheken, die von Chipanbietern oder Geräteherstellern bereitgestellt werden, kann standardmäßig nicht zugegriffen werden, wenn die App auf Android 12 (API-Level 31) oder höher ausgerichtet ist. Auf die Bibliotheken kann nur zugegriffen werden, wenn sie explizit über das <uses-native-library>-Tag angefordert werden.
Wenn die App auf Android 11 (API-Level 30) oder niedriger ausgerichtet ist, ist das <uses-native-library>-Tag nicht erforderlich. In diesem Fall ist auf jede native freigegebene Bibliothek zugegriffen werden, unabhängig davon, ob es sich um eine NDK-Bibliothek handelt.
Aktualisierte Einschränkungen für Nicht-SDKs
Android 12 enthält aktualisierte Listen der eingeschränkten nicht SDK-basierten 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 (je nach 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 nicht sicher sind, ob Ihre App Nicht-SDK-Schnittstellen verwendet, können Sie Ihre App testen, um das herauszufinden. Wenn Ihre App Nicht-SDK-Schnittstellen verwendet, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Uns ist jedoch bewusst, 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-Benutzeroberfläche 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 Änderungen an den 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.