Änderungen beim Verhalten: Apps, die auf Android 12 ausgerichtet sind

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 deine App auf Android 12 ausgerichtet ist, solltest du sie gegebenenfalls anpassen, um diese Verhaltensweisen zu unterstützen.

Sieh dir auch die Liste der Verhaltensänderungen an, die alle Apps unter Android 12 betreffen.

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 ist fast identisch mit dem von Notification.DecoratedCustomViewStyle.

Android 12 sorgt auf diese Weise dafür, dass alle Benachrichtigungen optisch einheitlich und leicht 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 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 deine App vollständig benutzerdefinierte Benachrichtigungen verwendet, solltest du sie so schnell wie möglich mit der neuen Vorlage testen.

1. Aktivieren Sie die Änderung für benutzerdefinierte Benachrichtigungen:

   1. Ändern Sie die targetSdkVersion Ihrer App in S, um das neue Verhalten zu aktivieren.
   2. Neu kompilieren.
   3. Installiere deine App auf einem Gerät oder Emulator mit Android 12.

2. Teste alle Benachrichtigungen, die benutzerdefinierte Ansichten verwenden, und achte darauf, dass sie wie erwartet in der Leiste angezeigt werden. 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 sind benutzerdefinierte Benachrichtigungen geringer als zuvor. Im minimierten Zustand ist die maximale Höhe des benutzerdefinierten Inhalts von 106 dp auf 48 dp gesunken. Außerdem ist der horizontale Platz geringer.

   • Für Apps, die auf Android 12 ausgerichtet sind, können alle Benachrichtigungen maximiert werden. Wenn du setCustomContentView verwendest, solltest du in der Regel auch setBigCustomContentView verwenden, 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 einige Ä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 Schema https unterstützen.

Sie können die Links Ihrer Anwendung auch manuell bestätigen, um die Zuverlässigkeit Ihrer Deklarationen zu testen.

Verbesserte Funktion 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 findest du unter Verbesserungen von Bild im Bild.

Toast-Neugestaltung

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 – Übersicht.

Sicherheit & 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. Chromium hat Ä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 die standardmäßige Handhabung von Drittanbieter-Cookies und tragen zum Schutz vor einer unbeabsichtigten Freigabe mehrerer Websites bei:

• Cookies ohne SameSite-Attribut werden wie SameSite=Lax behandelt.
• Cookies mit SameSite=None müssen auch das Attribut Secure angeben. Sie erfordern also einen sicheren Kontext und sollten über HTTPS gesendet werden.
• Verknüpfungen 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; Secure gekennzeichnet sind.

Für Entwickler gilt als allgemeine Richtlinie, die websiteübergreifenden Cookie-Abhängigkeiten in ihren kritischen Nutzerflüssen zu identifizieren und dafür zu sorgen, dass das Attribut SameSite bei Bedarf explizit mit den entsprechenden Werten festgelegt wird. Sie müssen explizit angeben, welche Cookies auf Websites oder in Aufrufen derselben Website, die von HTTP zu HTTPS wechseln, funktionieren dürfen.

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 deine App WebView verwendet oder du eine Website oder einen Dienst verwaltest, der Cookies verwendet, empfehlen wir, die Abläufe mit Android 12 WebView zu testen. Wenn Probleme auftreten, müssen Sie möglicherweise Ihre Cookies aktualisieren, damit sie die neuen SameSite-Verhaltensweisen unterstützen.

Achten Sie auf Probleme bei der Anmeldung und eingebetteten Inhalten sowie auf Anmelde-, Einkaufs- und andere Authentifizierungsabläufe, 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 zu testende App aktivieren. 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.

  So können Sie Tests 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 ausführen.

• Kompiliere deine App bis zum targetSdkVersion so, dass sie auf Android 12 (API-Level 31) ausgerichtet ist.

  Wenn Sie sich für diesen Ansatz entscheiden, müssen Sie ein Gerät verwenden, auf dem Android 12 ausgeführt wird.

Informationen zum Remote-Debugging für WebView unter Android finden Sie unter Erste Schritte mit der Fehlerbehebung für Android-Geräte.

Weitere Informationen

Weitere Informationen zum modernen Verhalten von SameSite und zum Rollout in Chrome und WebView finden Sie auf der Seite „Chromium SameSite-Updates“. Wenn Sie einen Fehler in WebView oder Chromium entdecken, können Sie ihn in der öffentlichen Chromium-Problemverfolgung melden.

Bewegungssensoren sind geschwindigkeitsbegrenzt

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 Sensorenfrequenz

App-Ruhezustand

Android 12 erweitert das Verhalten beim automatischen Zurücksetzen von Berechtigungen, das in Android 11 (API-Level 30) eingeführt wurde. Wenn deine App auf Android 12 ausgerichtet ist und der Nutzer einige Monate lang nicht mit deiner App interagiert, werden alle erteilten Berechtigungen automatisch zurückgesetzt und deine App wird in den Ruhezustand versetzt.

Weitere Informationen finden Sie im Leitfaden zum App-Ruhezustand.

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 basierend auf den Anwendungsfällen Ihrer App Attributions-Tags erstellen. Mit diesen Tags können Sie leichter feststellen, welcher Teil Ihrer Anwendung eine bestimmte Art von Datenzugriff ausführt.

Wenn deine App auf Android 12 oder höher ausgerichtet ist, musst du diese Attributions-Tags in der Manifestdatei deiner 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 und ein Nutzer den Befehl adb backup ausführt, werden die App-Daten aus allen anderen Systemdaten ausgeschlossen, die vom Gerät exportiert werden.

Wenn deine Test- oder Entwicklungsworkflows auf App-Daten mit adb backup basieren, kannst du jetzt den Export der App-Daten aktivieren. Setze dazu android:debuggable in der Manifestdatei deiner App auf true.

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, der einen Intent-Filter enthält, 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 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:

1. In der Manifestdatei wird die folgende Lint-Warnung angezeigt:

   When using intent filters, please specify android:exported as well
   

2. Wenn Sie versuchen, die Anwendung 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 Anwendung zu installieren, zeigt Logcat die folgende Fehlermeldung an:

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 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]

Einführung unsicherer Intents

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, tritt ein StrictMode-Verstoß 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 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 Ihre Anwendung im Hintergrund ausgeführt wird. Starten Sie Dienste im Vordergrund innerhalb eines exakten Alarms, um zeitkritische Aktionen auszuführen, die der Nutzer anfordert.

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.

Exakte Alarme sollten nur für Funktionen verwendet werden, die für den Nutzer sichtbar sind. Weitere Informationen zu zulässigen Anwendungsfällen zum Einrichten eines exakten Alarms

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

Zur Verbesserung der App-Leistung und Nutzerfreundlichkeit dürfen Apps, die auf Android 12 oder höher ausgerichtet sind, keine Aktivitäten von Diensten oder Übertragungsempfängern starten, die als Benachrichtigungs-Trampolin 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 von einem Dienst oder Übertragungsempfä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.

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 von einem Dienst oder Übertragungsempfänger startet, der als Benachrichtigungs-Trampolin fungiert, führen Sie die folgenden Migrationsschritte aus:

1. Erstelle ein PendingIntent-Objekt, das der Aktivität zugeordnet ist, die Nutzer sehen, nachdem sie auf die Benachrichtigung getippt haben.
2. Verwende das Objekt PendingIntent, das du im vorherigen Schritt beim Erstellen der Benachrichtigung erstellt hast.

Verwende Extras beim Posten der Benachrichtigung, um den Ursprung der Aktivität zu identifizieren, beispielsweise für das Logging. Verwenden Sie für zentralisiertes Logging ActivityLifecycleCallbacks oder Jetpack-Lebenszyklus-Beobachter.

Verhalten aktivieren/deaktivieren

Beim Testen einer debugfähigen Version Ihrer App 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. Es gibt zwei Formen der Android-Sicherung und -Wiederherstellung:

• 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 Backup Service sichern.

Änderungen an der D2D-Übertragungsfunktion

Für Apps, die auf Android 12 und höher laufen 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 festlegen 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 der Anleitung zum Sichern von Nutzerdaten mit der automatischen Sicherung.

Manifest-Flag für Apps

Verweise deine Apps mithilfe des Attributs 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 es Apps, die auf Android 12 ausgerichtet sind, mit Bluetooth-Geräten zu interagieren. Dies gilt insbesondere für Apps, die keinen Zugriff auf den Gerätestandort benötigen.

Aktualisiere die App-Logik, um dein Gerät für die Ausrichtung auf Android 12 oder höher vorzubereiten. 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 das WifiInfo-Objekt nur für ein einzelnes Netzwerk zurückgeben. Aus diesem Grund wurde das Verhalten der API in Android 12 und höher folgendermaßen geändert:

• Wenn nur ein einziges WLAN verfügbar ist, wird WifiInfo zurückgegeben.
• Wenn mehr als ein WLAN verfügbar ist und die anrufende App eine Peer-to-Peer-Verbindung ausgelöst hat, wird die WifiInfo zurückgegeben, die dem Peer-Gerät entspricht.
• Wenn mehr als ein WLAN verfügbar ist und die anrufende App keine Peer-to-Peer-Verbindung ausgelöst hat, wird WifiInfo der primären Internetbereitstellung zurückgegeben.

Zur Verbesserung der Nutzerfreundlichkeit auf Geräten, die doppelte, gleichzeitige WLAN-Netzwerke unterstützen, empfehlen wir, alle Anwendungen – insbesondere solche, die Peer-to-Peer-Verbindungen auslösen – vom Aufrufen 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:

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

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 dann das Gerät für die Multicast-Gruppen mit allen Knoten abonniert, wodurch das System häufiger aktiviert wird und zusätzliche Energie verbraucht. 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 mDNSReplyer-Daemon verfügbar ist, empfangen Anwendungen, die davon ausgehen, dass der mDNSReplyer-Daemon nach dem Aufruf der Methode getSystemService() gestartet wird, möglicherweise Nachrichten vom System, die angeben, dass der mDNSReplyer-Daemon nicht verfügbar ist. Anwendungen, die NsdManager und 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 Silikonanbietern oder Geräteherstellern bereitgestellt werden, ist 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 über das Tag <uses-native-library> explizit angefordert werden.

Wenn die App auf Android 11 (API-Level 30) oder niedriger ausgerichtet ist, ist das Tag <uses-native-library> nicht erforderlich. In diesem Fall kann auf jede native gemeinsam genutzte 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-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 deine App nicht auf Android 12 ausgerichtet ist, betreffen dich einige dieser Änderungen möglicherweise nicht sofort. Sie können zwar derzeit einige Nicht-SDK-Schnittstellen verwenden (je nach Ziel-API-Level Ihrer App), aber die Verwendung von Nicht-SDK-Methoden und -Feldern birgt immer ein hohes Risiko für Probleme mit Ihrer App.

Wenn du nicht sicher bist, ob deine App Nicht-SDK-Schnittstellen verwendet, kannst du die App testen, um es herauszufinden. Wenn Ihre App Nicht-SDK-Schnittstellen benötigt, sollten Sie eine Migration zu SDK-Alternativen planen. 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 diesem Android-Release finden Sie unter Updates für Nicht-SDK-Schnittstelleneinschränkungen in Android 12. Weitere Informationen zu Nicht-SDK-Schnittstellen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen.