Wie bei früheren Versionen 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 anpassen, dass sie diese Verhaltensweisen richtig unterstützt.
Sehen Sie sich auch die Liste der Verhaltensänderungen an, die sich auf alle Apps auswirken, die unter Android 12 ausgeführt werden.
Nutzererfahrung
Benutzerdefinierte Benachrichtigungen
In Android 12 wurde das Erscheinungsbild und Verhalten von vollständig benutzerdefinierten Benachrichtigungen geändert. Bisher konnten benutzerdefinierte Benachrichtigungen den gesamten Benachrichtigungsbereich nutzen und eigene Layouts und Stile bereitstellen. Dies führte zu Antipatterns, die Nutzer verwirren oder auf verschiedenen Geräten zu Problemen mit der Layoutkompatibilität führen konnten.
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. Diese Vorlage sorgt dafür, dass benutzerdefinierte Benachrichtigungen in allen Status dieselbe Darstellung haben wie andere Benachrichtigungen, z. B. das Benachrichtigungssymbol und die Aufklapp-Affordances (im minimierten Zustand) sowie das Benachrichtigungssymbol, der App-Name und die Minimierungs-Affordance (im aufgeklappten Zustand). Dieses Verhalten ist nahezu identisch mit dem von Notification.DecoratedCustomViewStyle.
So sorgt Android 12 für ein einheitliches Erscheinungsbild aller Benachrichtigungen, die sich leicht scannen lassen. Außerdem können Nutzer Benachrichtigungen wie gewohnt aufrufen.
Die folgende Abbildung zeigt eine benutzerdefinierte Benachrichtigung in der Standardvorlage:
Die folgenden Beispiele zeigen, wie benutzerdefinierte Benachrichtigungen im minimierten und maximierten Zustand gerendert werden:
Die Änderung in Android 12 betrifft Apps, die benutzerdefinierte abgeleitete Klassen von Notification.Style definieren oder die Methoden setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews) und setCustomHeadsUpContentView(RemoteViews) von Notification.Builder verwenden.
Wenn Ihre App vollständig benutzerdefinierte Benachrichtigungen verwendet, empfehlen wir, so schnell wie möglich mit der neuen Vorlage zu testen.
So aktivieren Sie die Änderung bei benutzerdefinierten Benachrichtigungen:
- Ändern Sie die
targetSdkVersionIhrer App inS, um das neue Verhalten zu aktivieren. - Kompilieren Sie die App neu.
- Installieren Sie Ihre App auf einem Gerät oder Emulator mit Android 12.
- Ändern Sie die
Testen Sie alle Benachrichtigungen, die benutzerdefinierte Ansichten verwenden, um sicherzustellen, dass sie im Benachrichtigungsfeld wie erwartet aussehen. Berücksichtigen Sie beim Testen die folgenden Punkte und nehmen Sie die erforderlichen Anpassungen vor:
Die Dimensionen von benutzerdefinierten Ansichten haben sich geändert. Im Allgemeinen ist die Höhe, die benutzerdefinierten Benachrichtigungen zur Verfügung steht, geringer als zuvor. Im minimierten Zustand wurde die maximale Höhe der benutzerdefinierten Inhalte von 106 dp auf 48 dp verringert. Außerdem ist weniger horizontaler Platz vorhanden.
Alle Benachrichtigungen sind für Apps, die auf Android 12 ausgerichtet sind, maximierbar. Wenn Sie
setCustomContentViewverwenden, sollten Sie in der Regel auchsetBigCustomContentViewverwenden, um sicherzustellen, dass die minimierten und maximierten Zustände konsistent sind.Damit der Status „Heads Up“ wie erwartet aussieht, müssen Sie die Wichtigkeit des Benachrichtigungschannels auf „HIGH“ (Pops on screen) 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 geben App-Entwicklern und Endnutzern mehr Kontrolle.
Wenn Sie sich auf die Android App Link-Bestätigung verlassen, um Weblinks in Ihrer App zu öffnen, prüfen Sie, ob Sie das richtige Format 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 Schema https unterstützen.
Sie können die Links Ihrer App auch manuell überprüfen, um die Zuverlässigkeit Ihrer Erklärungen zu testen.
Verbesserungen beim Bild-im-Bild-Modus
In Android 12 wurden Verhaltensverbesserungen für den Bild-im-Bild-Modus (BiB) eingeführt. Außerdem werden kosmetische Verbesserungen für Übergangsanimationen sowohl für die gestenbasierte als auch für die elementbasierte Navigation empfohlen.
Weitere Informationen finden Sie unter Verbesserungen bei der Bild-im-Bild-Funktion.
Neugestaltung von Toasts
In Android 12 wurde die Toast-Ansicht neu gestaltet. Toasts 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 für Ihre App eine ungefähre Standortgenauigkeit 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 an der Verarbeitung von Drittanbieter-Cookies eingeführt, um mehr Sicherheit und Datenschutz zu bieten und Nutzern mehr Transparenz und Kontrolle zu ermöglichen. Ab Android 12 sind diese Änderungen auch in WebView enthalten, wenn Apps auf Android 12 (API‑Level 31) oder höher ausgerichtet sind.
Mit dem Attribut SameSite eines Cookies wird gesteuert, ob es mit beliebigen Anfragen oder nur mit SameSite-Anfragen 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 das AttributSecureangegeben 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 Nutzerabläufen identifizieren und dafür sorgen, dass das Attribut SameSite bei Bedarf explizit mit den entsprechenden Werten festgelegt wird. Sie müssen die Cookies, die auf verschiedenen Websites oder bei Same-Site-Navigationen von HTTP zu HTTPS funktionieren dürfen, explizit angeben.
Ausführliche Informationen zu diesen Änderungen für Webentwickler 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, die bzw. der Cookies verwendet, empfehlen wir, Ihre Abläufe in Android 12 WebView zu testen. Wenn Sie Probleme feststellen, müssen Sie möglicherweise Ihre Cookies aktualisieren, um das neue SameSite-Verhalten zu unterstützen.
Achten Sie auf Probleme bei Anmeldungen und eingebetteten Inhalten sowie bei Anmelde-, Kauf- 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 das neue SameSite-Verhalten für die App, die Sie testen möchten, aktivieren. Führen Sie dazu einen der folgenden Schritte aus:
Aktivieren Sie das SameSite-Verhalten auf dem Testgerät manuell, indem Sie in den WebView-Entwicklertools das UI-Flag webview-enable-modern-cookie-same-site umschalten.
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
targetSdkVersionfür Android 12 (API‑Level 31).Wenn Sie diese Methode verwenden, benötigen Sie ein Gerät mit Android 12.
Informationen zum Remote-Debugging für WebView unter Android finden Sie unter Remote-Debugging von Android-Geräten.
Weitere Informationen
Weitere Informationen zu den modernen SameSite-Verhaltensweisen und der 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-Issue-Tracker melden.
Bewegungssensoren sind ratenbegrenzt
Zum Schutz potenziell vertraulicher Nutzerinformationen wird die Aktualisierungsrate von Daten bestimmter Bewegungs- und Positionssensoren durch das System begrenzt, wenn Ihre App auf Android 12 oder höher ausgerichtet ist.
Weitere Informationen zur Ratenbegrenzung von Sensoren
App-Ruhezustand
In Android 12 wird das in Android 11 (API‑Level 30) eingeführte automatische Zurücksetzen von Berechtigungen erweitert. 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 Ruhezustand.
Weitere Informationen finden Sie im Leitfaden zum Ruhezustand von Apps.
Attributionserklärung bei der Prüfung des Datenzugriffs
Mit der API zur Überprüfung des Datenzugriffs, die in Android 11 (API-Level 30) eingeführt wurde, können Sie Attributions-Tags basierend auf den Anwendungsfällen Ihrer App erstellen. Mithilfe dieser Tags können Sie leichter ermitteln, welcher Teil Ihrer App auf bestimmte Daten zugreift.
Wenn Ihre App auf Android 12 oder höher ausgerichtet ist, müssen Sie diese Attributions-Tags in der Manifestdatei Ihrer App deklarieren.
ADB-Sicherungseinschränkung
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 aus allen anderen Systemdaten ausgeschlossen, die vom Gerät exportiert werden.
Wenn Ihre Test- oder Entwicklungs-Workflows auf App-Daten mit adb backup basieren, können Sie jetzt den Export der Daten Ihrer App aktivieren, indem Sie android:debuggable in der Manifestdatei Ihrer App auf true setzen.
Sicherer Komponentenexport
Wenn Ihre App auf Android 12 oder höher ausgerichtet ist und Aktivitäten, Dienste oder Broadcast-Empfä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, der einen Intent-Filter enthält, 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>
Meldungen in Android Studio
Wenn Ihre App eine Aktivität, einen Dienst oder einen Übertragungsempfä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änderlichkeit von Pending 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 verbessert die Sicherheit Ihrer App.
Änderung der Veränderlichkeit von PendingIntent testen
So stellen Sie fest, ob in Ihrer App Deklarationen zur Veränderlichkeit fehlen: Suchen Sie in Android Studio nach der folgenden Lint-Warnung:
Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]
Starten unsicherer Intents
Zur Verbesserung der Plattformsicherheit bietet Android 12 und höher eine Debugging-Funktion, die unsichere Starts von Intents erkennt. Wenn das System einen solchen unsicheren Start erkennt, tritt ein StrictMode-Verstoß auf.
Leistung
Launch-Beschränkungen für Dienste im Vordergrund
Apps, die auf Android 12 oder höher ausgerichtet sind, können keine Dienste im Vordergrund starten, wenn sie im Hintergrund ausgeführt werden, mit Ausnahme einiger 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).
Sie können beschleunigte Aufgaben mit WorkManager planen und starten, während Ihre App im Hintergrund ausgeführt wird. Um zeitkritische Aktionen auszuführen, die der Nutzer anfordert, starten Sie Dienste im Vordergrund innerhalb eines genauen Alarms.
Berechtigung „Exakter Alarm“
Damit Apps Systemressourcen schonen, müssen Apps, die auf Android 12 und höher ausgerichtet sind und exakte Alarme festlegen, Zugriff auf die Funktion „Alarme & Erinnerungen“ haben, die in den Systemeinstellungen auf dem Bildschirm Spezieller App-Zugriff angezeigt wird.
Um diesen speziellen App-Zugriff zu erhalten, müssen Sie die Berechtigung SCHEDULE_EXACT_ALARM im Manifest anfordern.
Genaue Alarme sollten nur für nutzerorientierte Funktionen verwendet werden. Weitere Informationen zu zulässigen Anwendungsfällen für das Stellen eines genauen Weckers
Verhaltensänderung deaktivieren
Wenn Sie Ihre App für Android 12 vorbereiten, können Sie die Verhaltensänderung in Ihrer debugfähigen Build-Variante vorübergehend deaktivieren, um sie zu testen. Führen Sie dazu eine der folgenden Aufgaben aus:
- Wählen Sie auf dem Einstellungsbildschirm Entwickleroptionen die Option Änderungen bei 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 Benachrichtigungs-Trampoline
Wenn Nutzer mit Benachrichtigungen interagieren, reagieren einige Apps auf das Tippen auf die Benachrichtigung, indem sie eine App-Komponente starten, die schließlich die Aktivität startet, die der Nutzer sieht und mit der er interagiert. Diese App-Komponente wird als Benachrichtigungstrampolin bezeichnet.
Um die App-Leistung und ‑Nutzerfreundlichkeit zu verbessern, können Apps, die auf Android 12 oder höher ausgerichtet sind, keine Aktivitäten über Dienste oder Broadcast-Empfänger starten, die als Benachrichtigungs-Trampoline verwendet werden. Das bedeutet, dass Ihre App nach dem Tippen des Nutzers auf eine Benachrichtigung oder eine Schaltfläche in der Benachrichtigung nicht startActivity() in einem Dienst oder Broadcast-Empfänger aufrufen kann.
Wenn Ihre App versucht, eine Aktivität über einen Dienst oder Broadcast-Empfänger zu starten, der als Benachrichtigungs-Trampolin fungiert, 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.
App-Komponenten identifizieren, die als Benachrichtigungstrampoline fungieren
Wenn Sie Ihre App testen und auf eine Benachrichtigung tippen, können Sie herausfinden, welcher Dienst oder Broadcast-Empfänger in Ihrer App als Benachrichtigungstrampolin fungiert hat. 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 als Ergebnis eines Tippens auf eine Benachrichtigung gestartet wird.
App aktualisieren
Wenn Ihre App eine Aktivität über einen Dienst oder Broadcast-Receiver startet, der als Benachrichtigungs-Trampolin fungiert, 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 die Benachrichtigung getippt haben. - Verwenden Sie das
PendingIntent-Objekt, das Sie im vorherigen Schritt erstellt haben, als Teil Ihrer Benachrichtigung.
Um den Ursprung der Aktivität zu identifizieren, z. B. um sie zu protokollieren, verwenden Sie Extras beim Posten der Benachrichtigung. Verwenden Sie für die zentrale Protokollierung ActivityLifecycleCallbacks oder Jetpack-Lifecycle-Observer.
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
Es gibt Änderungen bei der Sicherung und Wiederherstellung in Apps, die unter Android 12 (API-Level 31) ausgeführt werden und auf diese ausgerichtet sind. Es gibt zwei Arten von Android-Sicherungen und ‑Wiederherstellungen:
- Cloud-Sicherungen:Nutzerdaten werden im Google Drive eines Nutzers gespeichert, damit sie später auf diesem oder einem neuen Gerät wiederhergestellt werden können.
- Geräte-zu-Gerät-Übertragungen (D2D): Nutzerdaten werden direkt vom alten Gerät des Nutzers an sein neues Gerät 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 Backup Service sichern.
Änderungen bei der D2D-Übertragung
Für Apps, die unter Android 12 und höher ausgeführt werden und auf diese Versionen ausgerichtet sind:
Das Angeben von Ein- und Ausschlussregeln mit dem XML-Konfigurationsmechanismus hat keine Auswirkungen auf D2D-Übertragungen, aber auf cloudbasierte Sicherung und Wiederherstellung (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 Hersteller wird durch die Angabe von
android:allowBackup="false"zwar die Sicherung in Google Drive deaktiviert, nicht aber die D2D-Übertragung für die App.
Neues Ein- und Ausschlussformat
Apps, die unter 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 deutlich, da Sie Ein- und Ausschlussregeln separat für Cloud-Sicherungen und für die D2D-Übertragung 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 Konfiguration von Sicherung und Wiederherstellung 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>
Die Änderungen im Format sind unten 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 im Leitfaden zum Sichern von Nutzerdaten mit Auto Backup.
Manifest-Flag für Apps
Verweisen Sie mit dem Attribut android:dataExtractionRules in der Manifestdatei auf die neue XML-Konfiguration. 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. Diese Berechtigungen erleichtern Apps, die auf Android 12 ausgerichtet sind, die Interaktion mit Bluetooth-Geräten, insbesondere für Apps, die keinen Zugriff auf den Gerätestandort benötigen.
Um Ihr Gerät für die Ausrichtung auf Android 12 oder höher vorzubereiten, müssen Sie die Logik Ihrer App aktualisieren. Deklarieren Sie anstelle einer alten Gruppe von Bluetooth-Berechtigungen eine modernere Gruppe 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, gleichzeitig WLAN-Verbindungen zum Peer-Gerät und zum primären Netzwerk, das Internet bereitstellt, aufrechterhalten. Dadurch wird die Nutzerfreundlichkeit verbessert. 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 die Verbindung zum Peergerä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 in Android 12 und höher auf folgende Weise geändert:
- Wenn nur ein einzelnes WLAN verfügbar ist, wird dessen
WifiInfozurückgegeben. - Wenn mehrere WLANs verfügbar sind und die Anruf-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.
Um die Nutzerfreundlichkeit auf Geräten zu verbessern, die zwei gleichzeitige WLANs unterstützen, empfehlen wir, dass alle Apps, insbesondere solche, die Peer-to-Peer-Verbindungen auslösen, nicht mehr WifiManager.getConnectionInfo() aufrufen, sondern stattdessen NetworkCallback.onCapabilitiesChanged() verwenden, um alle WifiInfo-Objekte abzurufen, die mit dem NetworkRequest übereinstimmen, das zum Registrieren des NetworkCallback verwendet wurde. getConnectionInfo() wird seit Android 12 nicht mehr unterstützt.
Das folgende Codebeispiel zeigt, wie Sie die WifiInfo in einem 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; ... } ... };
mDNSResponder Native API
Unter Android 12 hat sich geändert, wann Apps über die native mDNSResponder-API mit dem mDNSResponder-Daemon interagieren können.
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 für alle Knoten abonniert, was dazu führte, dass das System häufiger aktiviert wurde und mehr Strom verbrauchte. Um den Akkuverbrauch zu minimieren, startet das System in Android 12 und höher den mDNSResponder-Daemon nur, wenn er für NSD-Ereignisse benötigt wird, und beendet ihn danach wieder.
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 Methode getSystemService() gestartet wird, möglicherweise Meldungen vom System, 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
Native freigegebene Bibliotheken, die nicht zum NDK gehören und von Chipherstellern oder Geräteherstellern bereitgestellt werden, sind standardmäßig nicht zugänglich, wenn die App auf Android 12 (API-Level 31) oder höher ausgerichtet ist. Auf die Bibliotheken kann nur zugegriffen werden, wenn sie explizit mit dem Tag <uses-native-library> 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 jede native gemeinsam genutzte Bibliothek zugänglich, unabhängig davon, ob es sich um eine NDK-Bibliothek handelt.
Aktualisierte Einschränkungen für Nicht-SDKs
Android 12 enthält aktualisierte Listen eingeschränkter Nicht-SDK-Schnittstellen, die auf der Zusammenarbeit mit Android-Entwicklern und den neuesten internen Tests basieren. Wir sorgen nach Möglichkeit dafür, dass öffentliche Alternativen verfügbar sind, bevor wir Nicht-SDK-Schnittstellen einschränken.
Wenn Ihre App nicht auf Android 12 ausgerichtet ist, wirken sich einige dieser Änderungen möglicherweise nicht sofort auf Sie aus. Derzeit können Sie jedoch einige Nicht-SDK-Schnittstellen verwenden (abhängig vom Ziel-API-Level Ihrer App). Die Verwendung einer Nicht-SDK-Methode oder eines Nicht-SDK-Felds birgt jedoch immer ein hohes Risiko, dass Ihre App nicht mehr funktioniert.
Wenn Sie sich nicht sicher sind, ob Ihre App Nicht-SDK-Schnittstellen verwendet, können Sie Ihre App testen, um das herauszufinden. Wenn Ihre App auf Nicht-SDK-Schnittstellen basiert, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Wir verstehen jedoch, dass einige Apps gültige Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen haben. Wenn Sie keine Alternative zur Verwendung einer Nicht-SDK-Schnittstelle für eine Funktion in Ihrer App finden, sollten Sie eine neue öffentliche API anfordern.
Weitere Informationen zu den Änderungen in dieser Version von Android finden Sie unter Updates to non-SDK interface restrictions in Android 12. Weitere Informationen zu Nicht-SDK-Schnittstellen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen.