Wie bei früheren Releases umfasst Android 12 Verhaltensänderungen, die sich auf deine 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
Unter Android 12 werden Aussehen und Verhalten vollständig benutzerdefinierter Benachrichtigungen geändert. Bisher konnten benutzerdefinierte Benachrichtigungen den gesamten Benachrichtigungsbereich nutzen und ihre eigenen Layouts und Stile bereitstellen. Dies führte zu Anti-Patterns, die Nutzer verwirren oder Layout-Kompatibilitätsprobleme auf verschiedenen Geräten verursachen konnten.
Bei Apps, die auf Android 12 ausgerichtet sind, wird bei Benachrichtigungen mit benutzerdefinierten Inhaltsansichten nicht mehr der vollständige Benachrichtigungsbereich verwendet. Stattdessen wendet das System eine Standardvorlage an. Mit dieser Vorlage wird sichergestellt, dass benutzerdefinierte Benachrichtigungen in allen Status dieselbe Dekoration haben wie andere Benachrichtigungen, z. B. das Symbol und die Erweiterungsoptionen der Benachrichtigung (im minimierten Zustand) sowie das Symbol, den App-Namen und die Minimierungsoption (im maximierten Zustand). Dieses Verhalten entspricht nahezu dem von Notification.DecoratedCustomViewStyle.
Auf diese Weise sorgt Android 12 dafür, dass alle Benachrichtigungen visuell einheitlich und einfach zu scannen sind. Nutzer erhalten eine vertraute Benachrichtigungserweiterung.
Die folgende Abbildung zeigt eine benutzerdefinierte Benachrichtigung in der Standardvorlage:
Die folgenden Beispiele zeigen, wie benutzerdefinierte Benachrichtigungen minimiert und maximiert 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
Teste alle Benachrichtigungen, die benutzerdefinierte Ansichten verwenden, und achte darauf, dass sie wie erwartet in der Leiste angezeigt werden. 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 der horizontale Platz geringer.
Für Apps, die auf Android 12 ausgerichtet sind, können alle Benachrichtigungen maximiert werden. Wenn du
setCustomContentViewverwendest, solltest du in der Regel auchsetBigCustomContentViewverwenden, damit minimierte und maximierte Zustände einheitlich sind.Damit der Status „Vorsicht“ wie erwartet aussieht, solltest du die Wichtigkeit des Benachrichtigungskanals auf „HOCH“ (Pop-up auf dem Bildschirm) erhöhen.
Änderungen bei der Bestätigung 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 zum Öffnen von Weblinks in Ihrer App die Bestätigung über Android-App-Links benötigen, achten Sie darauf, dass Sie beim Hinzufügen von Intent-Filtern für die Bestätigung von Android-App-Links das richtige Format verwenden. 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“
Android 12 enthält Verbesserungen für das Verhalten des Bild-im-Bild-Modus (BiB) und empfohlene kosmetische Verbesserungen bei Übergangsanimationen für die Gestennavigation und die elementbasierte Navigation.
Weitere Informationen finden Sie unter Verbesserungen beim Bild-im-Bild-Modus.
Neugestaltung von Toasts
In Android 12 wurde die Toast-Ansicht neu gestaltet. Pop-ups sind jetzt auf zwei Textzeilen beschränkt und zeigen das Anwendungssymbol neben dem Text an.
Weitere Informationen finden Sie unter Toasts.
Sicherheit und Datenschutz
Ungefährer Standort
Auf Geräten mit Android 12 oder höher können Nutzer die 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, auf dem der Chrome-Browser von Google basiert. 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 Attribut SameSite eines Cookies steuert, ob es mit allen Anfragen oder nur mit Anfragen auf derselben Website gesendet werden kann. Die folgenden Änderungen zum Datenschutz verbessern den standardmäßigen Umgang mit Drittanbieter-Cookies und tragen zum Schutz vor einer unbeabsichtigten Freigabe mehrerer Websites bei:
- Cookies ohne
SameSite-Attribut werden alsSameSite=Laxbehandelt. - Cookies mit
SameSite=Nonemüssen auch das AttributSecureangeben. Sie erfordern also einen sicheren Kontext und sollten über HTTPS gesendet werden. - 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.
Eine vollständige Anleitung für Webentwickler zu diesen Änderungen finden Sie unter SameSite Cookies Explained 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:
Sie können SameSite-Verhaltensweisen auf dem Testgerät manuell aktivieren. Dazu deaktivieren Sie das UI-Flag „webview-enable-modern-cookie-same-site“ in den WebView-Entwicklertools.
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 zum modernen Verhalten von SameSite und zur Einführung in Chrome und WebView finden Sie auf der Seite „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
Wenn Ihre App auf Android 12 oder höher ausgerichtet ist, legt das System zum Schutz potenziell vertraulicher Nutzerdaten eine Beschränkung für die Aktualisierungsrate der Daten bestimmter Bewegungssensoren und Positionssensoren fest.
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 finden Sie im Leitfaden zum App-Ruhezustand.
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 für ADB-Sicherungen
Zum Schutz privater App-Daten ändert Android 12 das Standardverhalten des Befehls adb backup. 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. Legen Sie dazu in der Manifestdatei Ihrer App android:debuggable auf true fest.
Sichererer Export von Komponenten
Wenn Ihre App auf Android 12 oder höher ausgerichtet ist und Aktivitäten, Dienste oder Übertragungsempfänger mit Intent-Filtern enthält, müssen Sie das Attribut android:exported für diese App-Komponenten explizit deklarieren.
Wenn die App-Komponente die Kategorie LAUNCHER enthält, setze 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 der 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 deine App auf Android 12 ausgerichtet ist, musst du die Veränderlichkeit aller PendingIntent-Objekte angeben, die von deiner App erstellt werden. 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 in Android Studio nach der folgenden Lint-Warnung:
Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]
Unsichere Intent-Ausführungen
Zur Verbesserung der Plattformsicherheit bieten Android 12 und höher eine Fehlerbehebungsfunktion, die unsichere Starts von Intents erkennt. 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. Hiervon ausgenommen sind einige Sonderfälle. Wenn eine App versucht, einen Dienst im Vordergrund zu starten, während sie im Hintergrund ausgeführt wird, tritt eine Ausnahme auf (mit Ausnahme der wenigen Sonderfälle).
Mit WorkManager können Sie schnelle Arbeitsschritte planen und starten, während die Anwendung 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“
Damit Apps Systemressourcen schonen können, müssen Apps, die auf Android 12 und höher ausgerichtet sind und genaue Alarme einrichten, Zugriff auf die Funktion „Wecker und Erinnerungen“ haben, die in den Systemeinstellungen unter Spezieller App-Zugriff angezeigt wird.
Wenn Sie diesen speziellen App-Zugriff erhalten möchten, fordern Sie im Manifest die Berechtigung SCHEDULE_EXACT_ALARM an.
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 auf Android 12 vorbereiten, können Sie die Verhaltensänderung in Ihrer Debug-fähigen Build-Variante vorübergehend zu Testzwecken deaktivieren. Führen Sie dazu eine der folgenden Aufgaben aus:
- Wählen Sie auf dem Einstellungsbildschirm Entwickleroptionen die Option Änderungen 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, reagieren einige Apps auf das Tippen auf Benachrichtigungen, indem sie eine App-Komponente starten, die schließlich die Aktivität startet, die der Nutzer schließlich 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. Mit anderen Worten: Nachdem der Nutzer auf eine Benachrichtigung oder eine Aktionsschaltfläche in der Benachrichtigung getippt hat, kann Ihre App startActivity() nicht innerhalb eines Dienstes oder Übertragungsempfängers 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.
Herausfinden, welche App-Komponenten als Benachrichtigungs-Trampolin fungieren
Beim Testen Ihrer App können Sie nach dem Tippen auf eine Benachrichtigung ermitteln, welcher Dienst oder Übertragungsempfänger in Ihrer App als Benachrichtigungs-Trampolin 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 zur Identifizierung der Komponente erforderlich sind, die nach dem 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 der Aktivität zugeordnet 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-Lebenszyklusbeobachter.
Verhalten aktivieren/deaktivieren
Wenn Sie eine debugfähige Version Ihrer App testen, können Sie diese Einschränkung mit dem App-Kompatibilitäts-Flag NOTIFICATION_TRAMPOLINE_BLOCK aktivieren oder deaktivieren.
Back-up und Wiederherstellung
Es gibt Änderungen an der Funktionsweise von Sichern und Wiederherstellen in Apps, die unter Android 12 (API-Level 31) ausgeführt werden und darauf ausgerichtet sind. Die Sicherung und Wiederherstellung unter Android erfolgt auf zwei Arten:
- Cloud-Sicherungen:Nutzerdaten werden im Google Drive-Konto eines Nutzers gespeichert, damit sie später auf diesem oder einem neuen Gerät wiederhergestellt werden können.
- D2D-Übertragungen (Device to Device, D2D):Nutzerdaten werden von seinem älteren Gerät direkt an das neue Gerät des Nutzers gesendet, beispielsweise ü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:
Das Angeben von Ein- und Ausschließen-Regeln mit dem XML-Konfigurationsmechanismus wirkt sich nicht auf D2D-Übertragungen aus. Sie wirkt sich jedoch auf die cloudbasierte Sicherung und Wiederherstellung (z. B. Google Drive-Sicherungen) aus. 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 von einigen Geräteherstellern werden durch die Angabe von
android:allowBackup="false"Sicherungen in Google Drive deaktiviert, D2D-Übertragungen für die App jedoch nicht.
Neues Format zum Einschließen und Ausschließen
Apps, die auf Android 12 und höher ausgeführt werden und darauf ausgerichtet sind, verwenden ein anderes Format für die XML-Konfiguration. Dieses Format macht den Unterschied zwischen Google Drive-Sicherung und D2D-Übertragung explizit aus, da Sie separate Einschluss- und Ausschlussregeln für Cloud-Sicherungen und D2D-Übertragungen 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 für Geräte mit Android 11 oder niedriger weiterhin erforderlich.
Änderungen am XML-Format
In Android 11 und niedriger wird das folgende Format für die Konfiguration von Sicherungen und Wiederherstellungen 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 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 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 android:fullBackupContent-Attribut, 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 Apps, für die kein Zugriff auf den Gerätestandort erforderlich ist.
Wenn du dein Gerät für die Ausrichtung auf Android 12 oder höher vorbereiten möchtest, musst du die Logik deiner App aktualisieren. Deklarieren Sie statt eines Legacy-Satzes von Bluetooth-Berechtigungen einen moderneren Satz von Bluetooth-Berechtigungen.
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 Internetnetzwerk herstellen, um die Nutzerfreundlichkeit zu verbessern. Apps, die auf Android 11 (API-Level 30) oder niedriger ausgerichtet sind, weisen weiterhin das alte Verhalten auf, bei dem das primäre 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. Aus diesem Grund 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 mehr als ein WLAN verfügbar ist 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.
Zur Verbesserung der Nutzerfreundlichkeit auf Geräten, die doppelte, gleichzeitige WLANs unterstützen, empfehlen wir, alle Anwendungen – insbesondere solche, die Peer-to-Peer-Verbindungen auslösen – vom Aufruf von WifiManager.getConnectionInfo() zu beenden. Verwenden Sie stattdessen NetworkCallback.onCapabilitiesChanged(), um alle WifiInfo-Objekte abzurufen, die mit dem NetworkRequest übereinstimmen, das zum Registrieren von NetworkCallback verwendet wurde. getConnectionInfo() wurde mit Android 12 eingestellt.
Das folgende Codebeispiel zeigt, wie die WifiInfo in einer NetworkCallback abgerufen wird:
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 ändert sich, wann Anwendungen über die native mDNSResponseer-API mit dem mDNSReplyer-Daemon interagieren können.
Wenn eine Anwendung zuvor einen Dienst im Netzwerk registriert und die Methode getSystemService() aufgerufen hat, startete der NSD-Dienst des Systems den mDNSReplyer-Daemon, auch wenn die Anwendung 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. Zur Minimierung der Akkunutzung startet das System in Android 12 und höher den mDNSReplyer-Daemon nur dann, wenn er für NSD-Ereignisse benötigt wird, und stoppt 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 über das Tag <uses-native-library> explizit 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.
Nicht-SDK-Einschränkungen aktualisiert
Android 12 enthält aktualisierte Listen eingeschränkter nicht SDK-basierter Schnittstellen, die auf der Zusammenarbeit mit Android-Entwicklern und den neuesten internen Tests basieren. Wann immer möglich, achten wir darauf, 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 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 aber bewusst, dass es bei einigen Apps gültige Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen gibt. Wenn Sie für ein Feature in Ihrer App keine Alternative zur Verwendung einer Nicht-SDK-Schnittstelle 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.