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

Wie frühere Versionen umfasst auch Android 12 Verhaltensänderungen, die sich auf deine App auswirken können. Die folgenden Ä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 unter Android 12 auswirken.

Nutzererfahrung

Benutzerdefinierte Benachrichtigungen

Unter Android 12 wurden Aussehen und Verhalten von vollständig benutzerdefinierten Benachrichtigungen geändert. Bisher konnten benutzerdefinierte Benachrichtigungen den gesamten Benachrichtigungsbereich nutzen und ihre eigenen Layouts und Stile verwenden. Dies führte zu Antimustern, die Nutzer verwirren oder zu Problemen mit der Layoutkompatibilität auf verschiedenen Geräten führen könnten.

Bei Apps, die auf Android 12 ausgerichtet sind, wird bei Benachrichtigungen mit benutzerdefinierten Inhaltsansichten nicht mehr der gesamte Benachrichtigungsbereich genutzt. Stattdessen wendet das System eine Standardvorlage an. Mit dieser Vorlage wird sichergestellt, dass benutzerdefinierte Benachrichtigungen in allen Zuständen das gleiche Design haben wie andere Benachrichtigungen, z. B. das Benachrichtigungssymbol und Erweiterungsangebote (im minimierten Zustand) oder das Benachrichtigungssymbol, der App-Name und das Angebot zur Minimierung (im maximierten Zustand). Dieses Verhalten ist nahezu identisch mit dem Verhalten von Notification.DecoratedCustomViewStyle.

Auf diese Weise sorgt Android 12 dafür, dass alle Benachrichtigungen visuell einheitlich und leicht zu scannen sind, und die Nutzer eine vertraute, bekannte Benachrichtigungserweiterung haben.

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 bei 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 Tests mit der neuen Vorlage durchzuführen.

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

   1. Ändere die targetSdkVersion deiner App zu S, um das neue Verhalten zu aktivieren.
   2. Kompilieren Sie noch einmal.
   3. Installiere deine App auf einem Gerät oder Emulator mit Android 12.

2. Testen Sie alle Benachrichtigungen, die benutzerdefinierte Ansichten verwenden, und prüfen Sie, ob sie in der Töne wie erwartet aussehen. Berücksichtigen Sie beim Testen die folgenden Aspekte und nehmen Sie die erforderlichen Anpassungen vor:

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

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

   • Um sicherzustellen, dass der Status „Kopf hoch“ wie erwartet aussieht, sollten Sie die Wichtigkeit des Benachrichtigungskanals auf „HOCH“ (Pop-ups auf dem Bildschirm) erhöhen.

Änderungen bei der Bestätigung von Android-App-Links

Bei Apps, die auf Android 12 oder höher ausgerichtet sind, nimmt das System mehrere Änderungen an der Bestätigung von Android-App-Links vor. Diese Änderungen verbessern die Zuverlässigkeit der App-Verknüpfung und bieten App-Entwicklern und Endnutzern mehr Kontrolle.

Wenn Sie auf die Bestätigung über Android-App-Links angewiesen sind, um Weblinks in Ihrer App zu öffnen, achten Sie darauf, dass Sie beim Hinzufügen von Intent-Filtern für die Bestätigung von Android-App-Links das richtige Format verwenden. Diese Intent-Filter müssen insbesondere die Kategorie BROWSABLE enthalten und das Schema https unterstützen.

Sie können die Links Ihrer App auch manuell prüfen, um die Zuverlässigkeit Ihrer Deklarationen zu testen.

Verbesserungen bei der Funktion „Bild im Bild“

In Android 12 wurden Verhaltensverbesserungen für den Bild-im-Bild-Modus (BiB) und empfohlene kosmetische Verbesserungen bei Übergangsanimationen für die Bedienung über Gesten und für die elementbasierte Navigation eingeführt.

Weitere Informationen findest du unter Verbesserungen von Bild im Bild.

Neugestaltung des Toasts

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

Weitere Informationen

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 für den Chrome-Browser von Google. Chromium hat Änderungen beim 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 legt fest, ob es mit beliebigen Anfragen oder nur mit Anfragen derselben Website gesendet werden kann. Die folgenden datenschutzbezogenen Änderungen verbessern die standardmäßige Handhabung von Drittanbieter-Cookies und tragen zum Schutz vor unbeabsichtigtem websiteübergreifenden Teilen bei:

• Cookies ohne SameSite-Attribut werden wie SameSite=Lax behandelt.
• Cookies mit SameSite=None müssen auch das Attribut Secure angeben. 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 daher nur gesendet, wenn sie entsprechend als SameSite=None; Secure gekennzeichnet sind.

Entwickler sollten im Allgemeinen die websiteübergreifenden Cookie-Abhängigkeiten in den kritischen Nutzerflüssen ermitteln und dafür sorgen, dass das Attribut SameSite bei Bedarf explizit mit den entsprechenden Werten festgelegt wird. Sie müssen explizit die Cookies angeben, die auf Websites oder in Navigationen auf derselben Website funktionieren dürfen, die von HTTP zu HTTPS wechseln.

Umfassende Informationen für Webentwickler zu diesen Änderungen finden Sie unter SameSite Cookies Explained und Schemeful SameSite.

SameSite-Verhalten in Ihrer App testen

Wenn in deiner App WebView verwendet wird oder du eine Website oder einen Dienst verwaltest, der oder die Cookies verwendet, empfehlen wir dir, deine Abläufe in Android 12 WebView zu testen. Wenn Sie Probleme feststellen, müssen Sie möglicherweise Ihre Cookies aktualisieren, damit sie das neue SameSite-Verhalten unterstützen.

Achten Sie auf Probleme bei Anmeldungen und eingebetteten Inhalten sowie bei Anmeldevorgängen, Käufen und anderen Authentifizierungsabläufen, bei denen der Nutzer auf einer unsicheren Seite startet und dann zu einer sicheren Seite wechselt.

Wenn Sie eine App mit WebView testen möchten, müssen Sie die neuen SameSite-Verhalten für die App aktivieren, die Sie testen möchten. Dazu führen Sie einen der folgenden Schritte aus:

• Sie können das SameSite-Verhalten auf dem Testgerät manuell aktivieren. Dazu stellen Sie in den WebView-Entwicklertools das UI-Flag „webview-enable-modern-cookie-same-site“ um.

  So können Sie Tests auf jedem Gerät durchführen, auf dem Android 5.0 (API-Level 21) oder höher, einschließlich Android 12, und WebView-Version 89.0.4385.0 oder höher ausgeführt wird.

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

  Wenn Sie so vorgehen möchten, müssen Sie ein Gerät verwenden, auf dem Android 12 ausgeführt wird.

Informationen zum Remote-Debugging für WebView unter Android findest du unter Erste Schritte mit Remote-Debugging für Android-Geräte.

Weitere Informationen

Weitere Informationen zum modernen Verhalten von SameSite und zur Einführung in Chrome und WebView findest du auf der Seite Chromium SameSite Updates. Wenn du einen Fehler in WebView oder Chromium findest, kannst du ihn im öffentlichen Chromium Issue Tracker melden.

Bewegungssensoren sind ratenbegrenzt

Wenn Ihre App auf Android 12 oder höher ausgerichtet ist, begrenzt das System die Aktualisierungsrate von Daten bestimmter Bewegungs- und Positionssensoren, um potenziell vertrauliche Informationen zu Nutzern zu schützen.

Weitere Informationen zur Begrenzung der Sensorenfrequenz

App-Ruhezustand

Android 12 erweitert das in Android 11 (API-Level 30) eingeführte Verhalten beim automatischen Zurücksetzen von Berechtigungen. Wenn Ihre App auf Android 12 ausgerichtet ist und der Nutzer einige Monate lang nicht mit Ihrer App interagiert, setzt das System alle gewährten Berechtigungen automatisch zurück und Ihre App wird in den Ruhezustand versetzt.

Weitere Informationen finden Sie im Leitfaden zum Ruhezustand von Apps.

Deklaration der Attribution in der Datenzugriffsprüfung

Mit der in Android 11 (API-Level 30) eingeführten Auditing API für den Datenzugriff kannst du basierend auf den Anwendungsfällen deiner App Attributions-Tags erstellen. Mit diesen Tags können Sie leichter feststellen, welcher Teil Ihrer Anwendung 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.

Einschränkung für ADB-Sicherungen

Zum Schutz privater App-Daten ändert Android 12 das Standardverhalten des adb backup-Befehls. Wenn ein Nutzer bei Apps für Android 12 (API-Level 31) oder höher 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 deiner App-Daten aktivieren. Setze dazu android:debuggable in der Manifestdatei deiner App auf true.

Export von sichereren Komponenten

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, 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 android:exported-Attribut 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 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

Folgende 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, 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 von ausstehenden Intents

Wenn deine App auf Android 12 ausgerichtet ist, musst du die Veränderlichkeit aller PendingIntent-Objekte angeben, die von deiner App erstellt werden. Diese zusätzliche Anforderung verbessert die Sicherheit Ihrer App.

Ausstehende Änderung der Intent-Veränderlichkeit testen

Suchen Sie in Android Studio nach der folgenden Lint-Warnung, um festzustellen, ob in Ihrer App Veränderlichkeitsdeklarationen fehlen:

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 derart unsicheren Start erkennt, tritt ein StrictMode-Verstoß auf.

Leistung

Einschränkungen bei der Einführung von Diensten im Vordergrund

Bei Apps, die auf Android 12 oder höher ausgerichtet sind, können Dienste im Vordergrund nicht gestartet werden, während sie im Hintergrund ausgeführt werden. Ausnahmen 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 wenigen Sonderfällen).

Mit WorkManager können Sie beschleunigte Arbeiten planen und starten, während Ihre Anwendung im Hintergrund ausgeführt wird. Wenn Sie zeitkritische Aktionen ausführen möchten, die der Nutzer anfordert, starten Sie Dienste im Vordergrund in einem exakten Weckton.

Berechtigung „Exakter Alarm“

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

Fordern Sie im Manifest die Berechtigung SCHEDULE_EXACT_ALARM an, um diesen speziellen App-Zugriff zu erhalten.

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 das Einstellen eines exakten Alarms

Verhaltensänderung deaktivieren

Wenn Sie Ihre App für die Ausrichtung auf Android 12 vorbereiten, können Sie die Verhaltensänderung in Ihrer debugfähigen Build-Variante vorübergehend zu Testzwecken deaktivieren. Führen Sie dazu eine der folgenden Aufgaben aus:

• Wählen Sie auf dem Bildschirm mit den Entwickleroptionen die Option Änderungen an 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 über Trampolin-Einschränkungen

Wenn Nutzer mit Benachrichtigungen interagieren, reagieren einige Apps auf das Antippen von Benachrichtigungen und starten eine App-Komponente, 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 der Nutzererfahrung können Apps, die auf Android 12 oder höher ausgerichtet sind, keine Aktivitäten von Diensten oder Broadcast-Empfängern starten, die als Benachrichtigungs-Trampoline verwendet werden. Wenn der Nutzer also auf eine Benachrichtigung oder eine Aktionsschaltfläche in der Benachrichtigung getippt hat, kann die App startActivity() nicht mehr innerhalb eines Dienstes oder eines Sendeempfä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, dass die Aktivität gestartet wird, 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-Trampoline fungieren

Wenn Sie Ihre App testen, können Sie nach dem Tippen auf eine Benachrichtigung ermitteln, welcher Dienst oder Empfänger in Ihrer App als Benachrichtigungs-Trampolin fungiert. 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 durch das Antippen einer Benachrichtigung gestartet wird.

App aktualisieren

Wenn Ihre App eine Aktivität von einem Dienst oder Rundfunkempfänger startet, der als Benachrichtigungs-Trampolin fungiert, führen Sie die folgenden Migrationsschritte aus:

1. Erstellen Sie 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 Objekt PendingIntent, das Sie im vorherigen Schritt beim Erstellen der Benachrichtigung erstellt haben.

Verwende beim Posten der Benachrichtigung Extras, um den Ursprung der Aktivität zu identifizieren, um z. B. um ein Logging durchzuführen. Verwenden Sie für das zentralisierte 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 und deaktivieren.

Back-up und Wiederherstellung

Es gibt Änderungen an der Funktionsweise von Back-up und Wiederherstellung in Apps, die unter Android 12 (API-Level 31) ausgeführt werden und auf diese ausgerichtet sind. Es gibt zwei Formen der Android-Funktion „Sichern und wiederherstellen“:

• 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):Nutzerdaten werden, z. B. über ein Kabel, direkt von seinem älteren Gerät an das neue Gerät des Nutzers gesendet.

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 unter Android 12 und höher ausgeführt werden und darauf ausgerichtet sind:

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

Neues Format zum Ein- und Ausschließen

Apps, die auf Android 12 und höher ausgerichtet sind und auf Android 12 und höher ausgerichtet sind, verwenden ein anderes Format für die XML-Konfiguration. Dieses Format macht den Unterschied zwischen Google Drive-Sicherungen und D2D-Übertragung explizit aus, da Sie Ein- und Ausschlussregeln für Cloud-Sicherungen und D2D-Übertragungen separat festlegen 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 für Geräte mit Android 11 oder niedriger weiterhin erforderlich.

Änderungen des XML-Formats

Das folgende Format wird unter Android 11 und niedriger für die Konfiguration von Back-up und Wiederherstellung 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 in fett gedruckter Form.

<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 in der Anleitung zum Sichern von Nutzerdaten mit der automatischen Sicherung.

Manifest-Flag für Apps

Verweisen Sie Ihre Anwendungen 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

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

Wenn du dein Gerät für die Ausrichtung auf Android 12 oder höher vorbereiten möchtest, musst du die Logik deiner App aktualisieren. Deklarieren Sie keine alten Bluetooth-Berechtigungen, sondern 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, gleichzeitige WLAN-Verbindungen zum Peer-Gerät und zum primären Netzwerk mit dem Internet aufrechterhalten. Bei Apps, die auf Android 11 (API-Level 30) oder niedriger ausgerichtet sind, gilt weiterhin das bisherige Verhalten, bei dem das primäre WLAN vor dem Herstellen einer Verbindung zum Peer-Gerät getrennt wird.

Kompatibilität

WifiManager.getConnectionInfo() kann den WifiInfo nur für ein einzelnes Netzwerk zurückgeben. Aus diesem Grund wurde das Verhalten der API in Android 12 und höher so geändert:

• Wenn nur ein einzelnes WLAN verfügbar ist, wird der Wert für WifiInfo zurückgegeben.
• Wenn mehr als ein WLAN verfügbar ist und die aufrufende 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 die WifiInfo der primären Verbindung, die das Internet bereitstellt, zurückgegeben.

Für eine bessere Nutzerfreundlichkeit auf Geräten, die duale WLANs unterstützen, empfehlen wir alle Apps – insbesondere solche, die Peer-to-Peer-Verbindungen auslösen –, WifiManager.getConnectionInfo() nicht mehr aufzurufen und stattdessen NetworkCallback.onCapabilitiesChanged() zu verwenden, um alle WifiInfo-Objekte zu erhalten, die mit dem NetworkRequest übereinstimmen, mit dem NetworkCallback registriert wurde. getConnectionInfo() wird mit Android 12 eingestellt.

Das folgende Codebeispiel zeigt, wie Sie das 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 API für mDNSResponseer

Bei Android 12 ändert sich, wenn Apps über die native API mDNSResponseer API mit dem mDNSResponseer-Daemon interagieren können. Wenn eine App zuvor einen Dienst im Netzwerk registriert und die Methode getSystemService() aufgerufen hat, hat der NSD-Dienst des Systems den mDNSResponseer-Daemon gestartet, auch wenn die Anwendung noch keine NsdManager-Methoden aufgerufen hat. Der Daemon hat das Gerät dann den Multicast-Gruppen aus allen Knoten abonniert, wodurch das System häufiger aktiviert wurde und zusätzliche Energie verbraucht. Um die Akkunutzung zu minimieren, startet das System in Android 12 und höher jetzt den mDNSResponseer-Daemon nur dann, wenn er für NSD-Ereignisse benötigt wird, und stoppt ihn danach.

Da sich diese Änderung auf die Verfügbarkeit des mDNSResponseer-Daemons auswirkt, können Anwendungen, die davon ausgehen, dass der mDNSResponseer-Daemon nach dem Aufruf der Methode getSystemService() gestartet wird, möglicherweise Nachrichten vom System empfangen, die besagen, dass der mDNSResponseer-Daemon nicht verfügbar ist. Anwendungen, die NsdManager und nicht die native mDNSResponseer API nutzen, sind von dieser Änderung nicht betroffen.

Anbieterbibliotheken

Vom Anbieter bereitgestellte native freigegebene Bibliotheken

Nicht-NDK-native gemeinsam genutzte Bibliotheken, die von Herstellern oder Herstellern von Silicon Silikon 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 kann auf jede native freigegebene Bibliothek zugegriffen werden, unabhängig davon, ob es sich um eine NDK-Bibliothek handelt.

Nicht-SDK-Einschränkungen aktualisiert

Android 12 enthält aktualisierte Listen eingeschränkter Nicht-SDK-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 derzeit zwar einige Nicht-SDK-Schnittstellen verwenden (abhängig vom Ziel-API-Level Ihrer App), aber die Verwendung von Nicht-SDK-Methoden oder -Feldern birgt immer ein hohes Risiko für Probleme mit Ihrer App.

Wenn Sie sich nicht sicher sind, ob Ihre Anwendung Nicht-SDK-Schnittstellen verwendet, können Sie die Anwendung testen. Wenn Ihre App Nicht-SDK-Schnittstellen verwendet, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Trotzdem können einige Apps für die Verwendung von Nicht-SDK-Schnittstellen infrage kommen. Wenn Sie für eine Funktion 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 Aktualisierungen der Einschränkungen für Nicht-SDK-Schnittstellen in Android 12. Weitere Informationen zu Nicht-SDK-Schnittstellen im Allgemeinen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen.