Ä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 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 minimiert und maximiert dargestellt 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 in Ihrer App vollständig benutzerdefinierte Benachrichtigungen verwendet werden, empfehlen wir Ihnen, so bald wie möglich mit der neuen Vorlage zu 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. Kompilieren Sie die Datei noch einmal.
    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 die folgenden Aspekte und nehmen Sie die erforderlichen Anpassungen vor:

    • Die Dimensionen von benutzerdefinierten Ansichten haben sich geändert. Im Allgemeinen sind benutzerdefinierte 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 setCustomContentView verwenden, sollten Sie in der Regel auch setBigCustomContentView verwenden, 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.

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

In Android 12 wurden Verhaltensverbesserungen für den Modus „Bild im Bild“ (PiP) eingeführt. Außerdem werden optische Verbesserungen für Übergangsanimationen sowohl für die Gestennavigation als auch für die elementbasierte Navigation empfohlen.

Weitere Informationen findest du unter Verbesserungen von Bild im Bild.

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.

Bild eines Android-Geräts mit einem Toast-Pop-up mit dem Text „Nachricht wird gesendet“ neben einem App-Symbol

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. 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 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 als SameSite=Lax behandelt.
  • Für Cookies mit SameSite=None muss auch das Secure-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; Secure gekennzeichnet 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 targetSdkVersion so, 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 für ADB-Sicherungen

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

  1. In Ihrer 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 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 Pending 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.

Änderung der Veränderlichkeit von PendingIntents 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 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. Hiervon ausgenommen sind einige Sonderfälle. 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. Starten Sie Dienste im Vordergrund innerhalb eines exakten Alarms, um zeitkritische Aktionen auszuführen, die der Nutzer anfordert.

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, Zugriff auf die Funktion „Wecker und Erinnerungen“ haben, die in den Systemeinstellungen auf dem Bildschirm Spezielle App-Zugriffe angezeigt wird.

Wenn Sie diesen speziellen App-Zugriff erhalten möchten, müssen Sie die Berechtigung SCHEDULE_EXACT_ALARM im Manifest anfordern.

Exakte Alarme sollten nur für Funktionen verwendet werden, die für den Nutzer sichtbar sind. 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 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

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

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:

  1. Erstelle ein PendingIntent-Objekt, das mit der Aktivität verknüpft ist, die Nutzer sehen, nachdem sie auf die Benachrichtigung getippt haben.
  2. 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 zentralisiertes Logging 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. 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.
  • 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 Backup Service sichern.

Änderungen an 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 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 für Ein- und Ausschlüsse

Für Apps, die auf Android 12 und 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

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

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. 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 in Android 12 und höher folgendermaßen geändert:

  • Wenn nur ein WLAN verfügbar ist, wird dessen WifiInfo zurückgegeben.
  • Wenn mehrere WLANs verfügbar sind und die anrufende App eine Peer-to-Peer-Verbindung ausgelöst hat, wird die WifiInfo zurü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 WifiInfo der 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 mDNSReplyer-Daemon verfügbar ist, können Anwendungen, die davon ausgehen, dass der mDNSReplyer-Daemon nach dem Aufruf der Methode getSystemService() gestartet wird, möglicherweise Nachrichten vom System empfangen, die angeben, dass der mDNSReplyer-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 eingeschränkter nicht SDK-basierter 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 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 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.