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

Wie frühere Versionen enthält auch 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 so anpassen, dass sie diese Verhaltensweisen 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 ändern sich das Aussehen und das Verhalten von vollständig benutzerdefinierten Benachrichtigungen. Bisher konnten benutzerdefinierte Benachrichtigungen den gesamten Benachrichtigungsbereich nutzen und eigene Layouts und Stile bereitstellen. Dies führte zu Anti-Patterns, die Nutzer verwirren oder zu Layoutkompatibilitätsproblemen auf verschiedenen Geräten 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 Dekoration wie andere Benachrichtigungen haben, z. B. das Symbol der Benachrichtigung und die Erweiterungsmöglichkeiten (im minimierten Status) sowie das Symbol der Benachrichtigung, der App-Name und die Minimierungsmöglichkeit (im maximierten Status). Dieses Verhalten ist fast identisch mit dem Verhalten von Notification.DecoratedCustomViewStyle.

So sorgt Android 12 dafür, dass alle Benachrichtigungen visuell einheitlich und leicht zu erfassen sind. Außerdem können Nutzer die Benachrichtigungen auf vertraute Weise maximieren.

Die folgende Abbildung zeigt eine benutzerdefinierte Benachrichtigung in der Standardvorlage:

Die folgenden Beispiele zeigen, wie benutzerdefinierte Benachrichtigungen im minimierten und maximierten Zustand dargestellt werden:

Die Änderung in Android 12 betrifft Apps, 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, so bald wie möglich Tests mit der neuen Vorlage durchzuführen.

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

   1. Ändern Sie den targetSdkVersion Ihrer App in S, um das neue Verhalten zu aktivieren.
   2. Kompilieren Sie den Code neu.
   3. Installieren Sie Ihre App auf einem Gerät oder Emulator mit Android 12.

2. Teste alle Benachrichtigungen, die benutzerdefinierte Ansichten verwenden, um sicherzustellen, dass sie in der Benachrichtigungsleiste wie erwartet aussehen. Berücksichtigen Sie beim Testen die folgenden Punkte und nehmen Sie die erforderlichen Anpassungen vor:

   • Die Abmessungen benutzerdefinierter Ansichten haben sich geändert. Im Allgemeinen ist die Höhe, die für benutzerdefinierte Benachrichtigungen zur Verfügung steht, geringer als zuvor. Im minimierten Zustand wurde die maximale Höhe des benutzerdefinierten Inhalts von 106 dp auf 48 dp verringert. Außerdem ist weniger horizontaler Platz vorhanden.

   • Alle Benachrichtigungen für Apps, die auf Android 12 ausgerichtet sind, können maximiert werden. Wenn Sie setCustomContentView verwenden, sollten Sie in der Regel auch setBigCustomContentView verwenden, damit minimierte und maximierte Zustände einheitlich sind.

   • Damit der Status „Heads-up“ wie erwartet aussieht, musst du die Wichtigkeit des Benachrichtigungskanals auf „HOCH“ (Pop-up auf dem Bildschirm) 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 Überprüfung 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-Überprüfung verwenden, 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-Überprüfung hinzufügen. Achte 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 am Verhalten der Bild-im-Bild-Funktion

Mit Android 12 werden Verhaltensverbesserungen für den Bild-im-Bild-Modus (BiB) eingeführt. Außerdem werden kosmetische Verbesserungen für Übergangsanimationen sowohl für die Bedienung über Gesten als auch für die elementbasierte Navigation empfohlen.

Weitere Informationen finden Sie unter Verbesserungen für Bild im Bild.

Überarbeitete Toast-Benachrichtigungen

In Android 12 wurde die Toast-Ansicht neu gestaltet. Toasts sind jetzt auf zwei Textzeilen beschränkt und zeigen das App-Symbol neben dem Text an.

Weitere Informationen finden Sie unter Toasts – Übersicht.

Sicherheit und Datenschutz

Ungefährer Standort

Auf Geräten mit Android 12 oder höher können Nutzer die Genauigkeit des ungefähren Standorts 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 die Sicherheit und den Datenschutz zu verbessern 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 SameSite-Anfragen gesendet werden kann. Die folgenden datenschutzfreundlichen Änderungen verbessern die Standardbehandlung von Drittanbieter-Cookies und tragen zum Schutz vor unbeabsichtigter websiteübergreifender Weitergabe bei:

• Cookies ohne SameSite-Attribut werden als SameSite=Lax behandelt.
• Bei Cookies mit SameSite=None muss auch das Attribut Secure 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.

Entwicklern wird allgemein empfohlen, die websiteübergreifenden Cookie-Abhängigkeiten in ihren kritischen Nutzer-Flows zu identifizieren und dafür zu sorgen, dass das Attribut SameSite bei Bedarf explizit mit den entsprechenden Werten festgelegt wird. Sie müssen die Cookies, die websiteübergreifend oder bei der Navigation auf derselben Website von HTTP zu HTTPS funktionieren dürfen, explizit angeben.

Eine vollständige Anleitung für Webentwickler zu diesen Änderungen finden Sie unter SameSite-Cookies erklärt und Schemeful SameSite.

SameSite-Verhalten in Ihrer App testen

Wenn deine App WebView verwendet oder du eine Website oder einen Dienst verwaltest, die bzw. der Cookies verwendet, empfehlen wir, deine 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 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 das neue SameSite-Verhalten für die zu testende App aktivieren. Führen Sie dazu einen der folgenden Schritte aus:

• Aktivieren Sie SameSite-Verhaltensweisen manuell auf dem Testgerät, indem Sie in den WebView-Entwicklertools das UI-Flag „webview-enable-modern-cookie-same-site“ 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 für Android 12 (API-Level 31).

  Wenn Sie diesen Ansatz verwenden, müssen Sie ein Gerät mit Android 12 verwenden.

Informationen zum Remote-Debugging für WebView unter Android finden Sie unter Erste Schritte mit dem Remote-Debugging von Android-Geräten.

Andere Ressourcen

Weitere Informationen zu den modernen SameSite-Verhaltensweisen und zur Einführung in Chrome und WebView finden Sie auf der Seite zu SameSite-Updates für Chromium. Wenn Sie einen Fehler in WebView oder Chromium finden, können Sie ihn im öffentlichen Chromium Issue Tracker melden.

Für Bewegungssensoren gilt eine Ratenbegrenzung

Wenn deine App auf Android 12 oder höher ausgerichtet ist, begrenzt das System die Aktualisierungsrate von Daten bestimmter Bewegungssensoren und Positionssensoren, um potenziell vertrauliche Informationen über Nutzer zu schützen.

Weitere Informationen zur Ratenbegrenzung für Sensoren

App-Ruhezustand

Android 12 erweitert das automatische 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 Ruhezustand.

Weitere Informationen findest du im Leitfaden zum App-Ruhezustand.

Attributionserklärung bei der Prüfung von Datenzugriffen

Mit der in Android 11 (API-Level 30) eingeführten API zur Prüfung von Datenzugriffen können Sie Attributions-Tags erstellen, die auf den Anwendungsfällen Ihrer App basieren. Mit diesen Tags können Sie leichter feststellen, welcher Teil Ihrer App eine bestimmte Art von 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.

ADB-Sicherungseinschränkung

Zum Schutz privater App-Daten wird unter 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 von allen anderen Systemdaten ausgeschlossen, die vom Gerät exportiert werden, wenn ein Nutzer den Befehl adb backup ausführt.

Wenn Ihre Test- oder Entwicklungsworkflows auf App-Daten mit adb backup angewiesen sind, 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 Übertragungsempfä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, legen Sie für android:exported den Wert true fest. In den meisten anderen Fällen legen Sie android:exported auf false fest.

Das folgende Code-Snippet zeigt ein Beispiel für einen Dienst, der einen Intent-Filter enthält, dessen Attribut android:exported 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 deine 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 Ihrer Manifestdatei wird die folgende Lint-Warnung angezeigt:

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

2. Wenn Sie versuchen, Ihre 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änderlichkeit von Pending Intents

Wenn Ihre App auf Android 12 ausgerichtet ist, müssen Sie die Veränderlichkeit jedes PendingIntent-Objekts angeben, das Ihre App erstellt. Diese zusätzliche Anforderung verbessert die Sicherheit Ihrer App.

Änderung der Veränderlichkeit von PendingIntent testen

Wenn Sie herausfinden möchten, 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]

Unsichere Intent-Starts

Zur Verbesserung der Plattformsicherheit bieten Android 12 und höher eine Debugging-Funktion, die unsichere Intent-Starts 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 Dienste im Vordergrund nicht starten, während sie im Hintergrund ausgeführt werden. Es gibt jedoch einige Ausnahmen. Wenn eine App versucht, einen Dienst im Vordergrund zu starten, während sie im Hintergrund ausgeführt wird, tritt eine Ausnahme auf (außer in einigen Sonderfällen).

Sie können WorkManager verwenden, um Express-Jobs zu planen und zu starten, während Ihre App im Hintergrund ausgeführt wird. Wenn Sie zeitkritische Aktionen ausführen möchten, die vom Nutzer angefordert werden, starten Sie Dienste im Vordergrund innerhalb eines genauen Weckers.

Berechtigung „Exakter Alarm“

Damit Apps Systemressourcen schonen, müssen Apps, die auf Android 12 und höher ausgerichtet sind und genaue Wecker einstellen, Zugriff auf die Funktion „Wecker und Erinnerungen“ haben, die in den Systemeinstellungen auf dem Bildschirm Spezieller App-Zugriff angezeigt wird.

Wenn du diesen speziellen App-Zugriff erhalten möchtest, musst du die Berechtigung SCHEDULE_EXACT_ALARM im Manifest anfordern.

Exakte Alarme sollten nur für Funktionen verwendet werden, die für Nutzer sichtbar sind. Weitere Informationen zu den zulässigen Anwendungsfällen für das Festlegen 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 zu Testzwecken vorübergehend deaktivieren. Führen Sie dazu eine der folgenden Aufgaben aus:

• Wählen Sie auf dem Einstellungsbildschirm Entwickleroptionen die Option Änderungen an der App-Kompatibilität aus. Tippen Sie auf dem angezeigten Bildschirm auf den Namen Ihrer App und deaktivieren Sie dann REQUIRE_EXACT_ALARM_PERMISSION.

• Führen Sie in einem Terminalfenster auf Ihrem Entwicklungscomputer den folgenden Befehl aus:

  adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
  

Einschränkungen für Benachrichtigungs-Trampoline

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 sieht und mit der er interagiert. Diese App-Komponente wird als Benachrichtigungs-Trampolin bezeichnet.

Um die App-Leistung und die UX 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 Benachrichtigungs-Trampoline verwendet werden. Das bedeutet, dass Ihre App nach dem Tippen auf eine Benachrichtigung oder einen Aktionsbutton in der Benachrichtigung nicht startActivity() innerhalb eines Dienstes oder Übertragungsempfängers aufrufen kann.

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.

Ermitteln, welche App-Komponenten als Benachrichtigungs-Trampoline fungieren

Wenn Sie Ihre App testen, können Sie nach dem Tippen auf eine Benachrichtigung feststellen, welcher Dienst oder Übertragungsempfänger als Benachrichtigungs-Trampolin in Ihrer App 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 Übertragungsempfänger startet, der als Benachrichtigungs-Trampolin fungiert, 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 Ihre Benachrichtigung zu erstellen.

Wenn Sie den Ursprung der Aktivität ermitteln möchten, um beispielsweise Logging durchzuführen, verwenden Sie beim Posten der Benachrichtigung Extras. Verwenden Sie für zentralisiertes Logging ActivityLifecycleCallbacks oder Jetpack-Lebenszyklusbeobachter.

Verhalten ein-/ausschalten

Wenn du eine debugfähige Version deiner App testest, kannst du diese Einschränkung mit dem App-Kompatibilitäts-Flag NOTIFICATION_TRAMPOLINE_BLOCK aktivieren und deaktivieren.

Sichern und wiederherstellen

Es gibt Änderungen bei der Funktionsweise von Sicherung und Wiederherstellung in Apps, die auf Android 12 (API-Level 31) ausgeführt werden und auf dieses Betriebssystem ausgerichtet sind. Es gibt zwei Arten von Android-Backups und ‑Wiederherstellungen:

• Cloud-Sicherungen:Nutzerdaten werden in Google Drive gespeichert, damit sie später auf dem Gerät oder einem neuen Gerät wiederhergestellt werden können.
• Übertragung von Gerät zu Gerät (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 Datenübertragung von Gerät zu Gerät

Für Apps, die auf Android 12 und höher ausgeführt werden und darauf ausgerichtet sind:

• Das Festlegen von Ein- und Ausschlussregeln mit dem XML-Konfigurationsmechanismus hat keine Auswirkungen auf D2D-Übertragungen, wirkt sich aber auf cloudbasierte Sicherungen und Wiederherstellungen (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 einiger Gerätehersteller wird durch die Angabe von android:allowBackup="false" zwar die Sicherung in Google Drive deaktiviert, aber nicht die D2D-Übertragung für die App.

Neues Format für Ein- und Ausschlüsse

Apps, die auf Android 12 und höher ausgeführt werden und auf diese Versionen ausgerichtet sind, verwenden ein anderes Format für die XML-Konfiguration. Dieses Format macht den Unterschied zwischen Google Drive-Backups und D2D-Übertragungen deutlich, da Sie separate Ein- und Ausschlussregeln für Cloud-Backups und D2D-Übertragungen angeben müssen.

Optional können Sie damit auch Regeln für die Sicherung festlegen. In diesem Fall wird die zuvor verwendete Konfiguration auf Geräten mit Android 12 oder höher ignoriert. Die ältere Konfiguration ist weiterhin für Geräte mit Android 11 oder niedriger erforderlich.

Änderungen am XML-Format

Das folgende Format wird für die Sicherungs- und Wiederherstellungskonfiguration in Android 11 und niedriger verwendet:

<full-backup-content>
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string"
    requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string" />
</full-backup-content>

Im Folgenden sind die Änderungen am Format 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 findest du im entsprechenden Abschnitt des Leitfadens zum Sichern von Nutzerdaten mit der automatischen Sicherung.

Manifest-Flag für Apps

Verweisen Sie Ihre Apps auf die neue XML-Konfiguration, indem Sie das Attribut android:dataExtractionRules in Ihrer Manifestdatei verwenden. 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 Einträge in der Manifestdatei:

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

Verbindung

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, insbesondere Apps, die keinen Zugriff auf den Gerätestandort benötigen.

Aktualisieren Sie die Logik Ihrer App, um Ihr Gerät auf die Ausrichtung auf Android 12 oder höher vorzubereiten. Anstatt ältere Bluetooth-Berechtigungen zu deklarieren, deklarieren Sie modernere 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 sowohl zum Peer-Gerät als auch zum primären Internetnetzwerk aufrechterhalten. Dadurch wird die Nutzerfreundlichkeit verbessert. Bei Apps, die auf Android 11 (API-Level 30) oder niedriger ausgerichtet sind, wird weiterhin das alte Verhalten verwendet, bei dem die Verbindung zum primären WLAN getrennt wird, bevor eine Verbindung zum Peer-Gerät hergestellt wird.

Kompatibilität

WifiManager.getConnectionInfo() kann die WifiInfo nur für ein einzelnes Netzwerk zurückgeben. 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 dessen WifiInfo zurückgegeben.
• Wenn mehr als ein WLAN verfügbar ist und die Anruf-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 Anruf-App keine Peer-to-Peer-Verbindung ausgelöst hat, wird die WifiInfo der primären Internetverbindung zurückgegeben.

Damit Nutzer auf Geräten, die zwei gleichzeitige WLAN-Netzwerke unterstützen, eine bessere Nutzererfahrung haben, 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, der zum Registrieren des NetworkCallback verwendet wurde. getConnectionInfo() wurde mit Android 12 eingestellt.

Das folgende Codebeispiel zeigt, wie Sie die WifiInfo in einer NetworkCallback abrufen:

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

Mit Android 12 ändert sich, wann Apps über die native mDNSResponder API mit dem mDNSResponder-Daemon interagieren können. Wenn eine App einen Dienst im Netzwerk registriert und die Methode getSystemService() aufgerufen hat, hat der NSD-Dienst des Systems den mDNSResponder-Daemon gestartet, auch wenn die App noch keine NsdManager-Methoden aufgerufen hatte. Der Daemon hat das Gerät dann bei den Multicast-Gruppen für alle Knoten angemeldet, was dazu führte, dass das System häufiger aktiviert wurde und mehr Strom verbrauchte. Um den Akkuverbrauch zu minimieren, startet das System den mDNSResponder-Daemon in Android 12 und höher jetzt nur, wenn er für NSD-Ereignisse benötigt wird, und beendet ihn danach.

Da sich diese Änderung darauf auswirkt, wann der mDNSResponder-Daemon verfügbar ist, erhalten Apps, die davon ausgehen, dass der mDNSResponder-Daemon nach dem Aufruf der Methode getSystemService() gestartet wird, möglicherweise Nachrichten 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

Nicht-NDK-native gemeinsam genutzte Bibliotheken, die 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. Die Bibliotheken sind nur zugänglich, 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 Tag <uses-native-library> 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-SDK-Schnittstellen

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 stellen nach Möglichkeit öffentliche Alternativen zur Verfügung, bevor wir Nicht-SDK-Schnittstellen einschränken.

Wenn Ihre App nicht auf Android 12 ausgerichtet ist, sind Sie von einigen dieser Änderungen möglicherweise nicht sofort betroffen. Derzeit können Sie zwar einige Nicht-SDK-Schnittstellen verwenden (abhängig vom 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 sich nicht sicher sind, ob Ihre App Nicht-SDK-Schnittstellen verwendet, können Sie Ihre App testen, um dies herauszufinden. Wenn Ihre App auf Nicht-SDK-Schnittstellen basiert, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Wir wissen jedoch, dass es für einige Apps gültige Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen gibt. Wenn Sie keine Alternative zur Verwendung einer Nicht-SDK-Schnittstelle für eine Funktion in Ihrer App finden, sollten Sie eine neue öffentliche API anfordern.

Weitere Informationen zu den Änderungen in dieser Android-Version finden Sie unter Aktualisierungen der 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.