Diese Seite wurde von der Cloud Translation API übersetzt.

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

Wie bei früheren Releases wurde auch bei Android 12 können sich auf Ihre App auswirken. Die folgenden Verhaltensänderungen gelten ausschließlich für Apps die auf Android 12 oder höher ausgerichtet sind. Wenn Ihre App Wenn deine App auf Android 12 ausgerichtet ist, solltest du deine App so anpassen, dass sie diese Verhaltensweisen unterstützt ordnungsgemäß sein.

Sehen Sie sich auch die Liste der Verhaltensänderungen an, die alle Apps betreffen mit Android 12.

Nutzererfahrung

Benutzerdefinierte Benachrichtigungen

Unter Android 12 werden Aussehen und Verhalten vollständig benutzerdefinierter Benachrichtigungen geändert. Bisher konnte bei benutzerdefinierten Benachrichtigungen der gesamte Benachrichtigungsbereich genutzt werden. und eigene Layouts und Stile festlegen. Dies führte zu Anti-Mustern, die Nutzer verwirren oder Probleme mit der Layoutkompatibilität auf verschiedenen Geräten verursachen.

Für Apps, die auf Android 12 ausgerichtet sind, werden Benachrichtigungen mit benutzerdefinierten Inhaltsansichten nicht den gesamten Benachrichtigungsbereich nicht mehr nutzen, Stattdessen wendet das System eine Standard- Vorlage. Diese Vorlage sorgt dafür, dass benutzerdefinierte Benachrichtigungen wie andere Benachrichtigungen in allen Status, wie das Benachrichtigungssymbol Erweiterungsmöglichkeiten (im minimierten Zustand) sowie das Symbol der Benachrichtigung App-Name und minimieren die Angebotsdarstellung (im maximierten Zustand). Dieses Verhalten ist fast identisch mit dem Verhalten von Notification.DecoratedCustomViewStyle

So werden in Android 12 alle Benachrichtigungen visuell einheitlich und leicht zu mit einer sichtbaren, bekannten Benachrichtigungserweiterung für Nutzer.

Die folgende Abbildung zeigt eine benutzerdefinierte Benachrichtigung in der Standardvorlage:

Die folgenden Beispiele zeigen, wie benutzerdefinierte Benachrichtigungen in einer minimierten Ansicht gerendert werden. und einen maximierten Zustand:

Die Änderung bei Android 12 betrifft Apps, die benutzerdefinierte abgeleitete Klassen von Notification.Style oder verwenden Methoden von Notification.Builder setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews) und setCustomHeadsUpContentView(RemoteViews).

Wenn deine App vollständig benutzerdefinierte Benachrichtigungen verwendet, empfehlen wir, sie mit dem neue Vorlage so schnell wie möglich erstellen.

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.
Teste alle Benachrichtigungen, die benutzerdefinierte Ansichten verwenden, und stelle sicher, dass sie wie du aussehen die Sie im Schatten erwarten. 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 ist die Höhe benutzerdefinierte Benachrichtigungen leisten können, ist weniger als zuvor. In der minimierten ist die maximale Höhe des benutzerdefinierten Inhalts von 106 dp gesunken. bis 48 dp. Außerdem ist der horizontale Platz geringer.
- Für Apps, die auf Android 12 ausgerichtet sind, können alle Benachrichtigungen maximiert werden. Wenn Sie setCustomContentView verwenden, bedeutet das in der Regel Folgendes: sollten Sie auch setBigCustomContentView um sicherzustellen, dass minimierte und maximierte Zustände einheitlich sind.
- Die Schaltfläche „Kopf hoch“ wie erwartet aussieht, denken Sie daran, um die Wichtigkeit des Benachrichtigungskanals auf "HOCH" zu setzen. (Klingelt auf Bildschirm).

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

Bei Apps, die auf Android 12 oder höher ausgerichtet sind, erstellt das System Mehrere Änderungen an der Funktionsweise von Android-App-Links bestätigt. Diese verbessern die Zuverlässigkeit der App-Verknüpfung und bieten die Kontrolle für App-Entwickler und Endnutzer bieten.

Wenn Sie zum Öffnen von Weblinks in Ihrer App die Bestätigung über Android-App-Links Achten Sie darauf, dass Sie beim Hinzufügen eines Intents Filter für Bestätigung von Android-App-Links. Achten Sie insbesondere darauf, dass diese Intents Filter enthalten die Kategorie BROWSABLE und unterstützen das Schema https.

Sie können auch manuell Bestätigen Sie Ihr um die Zuverlässigkeit deiner Erklärungen zu testen.

Verbesserte Funktion von Bild im Bild

Mit Android 12 wurden Verhaltensverbesserungen für den Bild-im-Bild-Modus (BiB) eingeführt. und empfohlene kosmetische Verbesserungen der Übergangsanimationen für beide Navigation und elementbasierte Navigation.

Weitere Informationen findest du unter Bild im Bild. Informationen.

Toast-Neugestaltung

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

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

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 ungefährer Standort Genauigkeit für Ihre App ermitteln.

Moderne SameSite-Cookies in WebView

Die WebView-Komponente von Android basiert auf Chromium, das Open-Source-Projekt, auf dem der Chrome-Browser von Google basiert. Einführung von Chromium die Handhabung von Drittanbieter-Cookies, um für mehr Sicherheit und und den Nutzern mehr Transparenz und Kontrolle bieten. Ab Android 12 Diese Änderungen sind auch in „WebView“ enthalten, wenn Apps auf Android 12 (API-Level 31) oder höher

Mit dem Attribut SameSite eines Cookies wird gesteuert, ob es mit einem beliebigen oder nur mit Anfragen zur selben Website. Die folgenden Datenschutzmaßnahmen verbessern den standardmäßigen Umgang mit Drittanbieter-Cookies und tragen dazu bei, vor unbeabsichtigtem websiteübergreifendem Teilen:

Cookies ohne SameSite-Attribut werden wie SameSite=Lax behandelt.
Cookies mit SameSite=None müssen auch das Attribut Secure enthalten, d. h. erfordern sie einen sicheren Kontext und sollten über HTTPS gesendet werden.
Links zwischen HTTP- und HTTPS-Versionen einer Website werden jetzt als websiteübergreifend behandelt. -Anforderungen, sodass Cookies nur gesendet werden, wenn sie entsprechend als SameSite=None; Secure

Für Entwickler ist die allgemeine Richtlinie, das websiteübergreifende Cookie zu identifizieren. in Ihren kritischen Nutzerabläufen zu berücksichtigen, und achten Sie darauf, dass die SameSite wird gegebenenfalls explizit mit den entsprechenden Werten festgelegt. Du musst ausdrücklich angeben, welche Cookies auf Websites oder in für Navigationen auf derselben Website, die von HTTP zu HTTPS wechseln.

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

SameSite-Verhalten in Ihrer App testen

Wenn Ihre App WebView verwendet oder Sie eine Website oder einen Dienst verwalten, empfehlen wir, die Abläufe in Android 12 WebView zu testen. Falls Probleme auftreten, müssen Sie möglicherweise Ihre Cookies aktualisieren, um die neue SameSite-Verhaltensweisen.

Achte auf Probleme bei Anmeldungen, eingebetteten Inhalten und Anmeldevorgängen. Authentifizierungsabläufe, bei denen der Nutzer mit einem unsicheren und zu einer sicheren Seite übergeht.

Um eine App mit WebView zu testen, müssen Sie die neuen SameSite-Verhaltensweisen für die App, die Sie testen möchten, indem Sie einen der folgenden Schritte ausführen:

Aktivieren Sie das SameSite-Verhalten auf dem Testgerät manuell durch Umschalten des UI-Flags. WebView-enable-modern-cookie-same-site in den WebView-Entwicklertools.

So kannst du Tests auf jedem Gerät mit Android 5.0 (API-Level 21) durchführen. oder höher (einschließlich Android 12) und WebView Version 89.0.4385.0 oder höher.
Kompiliere deine App bis zum targetSdkVersion so, dass sie auf Android 12 (API-Level 31) ausgerichtet ist.

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

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

Weitere Informationen

Weitere Informationen zum aktuellen Verhalten von SameSite und zur Einführung in Chrome und WebView finden Sie unter Chromium SameSite Updates . Wenn Sie einen Fehler in WebView finden oder Chromium melden Sie dies in der öffentlichen Chromium-Seite Tracker.

Bewegungssensoren sind geschwindigkeitsbegrenzt

Zum Schutz potenziell vertraulicher Nutzerdaten, wenn deine App auf Android 12 oder höher hat das System ein Limit für die Aktualisierung Datenfrequenz bestimmter Bewegungs- und Positionssensoren.

Weitere Informationen zum Sensor Ratenbegrenzung.

App-Ruhezustand

Unter Android 12 wird die automatische Zurücksetzung von Berechtigungen erweitert. Verhalten die mit Android 11 (API-Level 30) eingeführt wurde. Wenn Ihre App auf Unter Android 12 interagiert der Nutzer einige Zeit lang nicht mit deiner App gewährt, setzt das System alle erteilten Berechtigungen automatisch zurück und platziert deine App hibernation-Status.

Weitere Informationen finden Sie im Leitfaden zu App-Kampagnen Winterschlaf.

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 um eine Zuordnung zu erstellen Tags basierend auf Ihren App-Anwendungsfälle. Mithilfe dieser Tags können Sie leichter feststellen, eine bestimmte Art Datenzugriff ausführt.

Wenn deine App auf Android 12 oder höher ausgerichtet ist, musst du diese Attributions-Tags in in der Manifest-Datei Ihrer App.

Einschränkung für ADB-Sicherungen

Zum Schutz privater App-Daten ändert Android 12 das Standardverhalten der adb backup-Befehl. Für Apps, die auf Android 12 (API-Level 31) oder höher ausgerichtet sind, Wenn ein Nutzer den Befehl adb backup ausführt, werden die App-Daten von allen anderen ausgeschlossen. Systemdaten, die vom Gerät exportiert werden.

Wenn Ihre Test- oder Entwicklungs-Workflows mit adb backup auf App-Daten basieren, können Sie den Export Ihrer App-Daten aktivieren, indem Sie android:debuggable true in der Manifestdatei Ihrer App fest.

Sichererer Export von Komponenten

Wenn Ihre App auf Android 12 oder höher ausgerichtet ist und Aktivitäten, services oder broadcast Empfänger, die Intents verwenden ändern, müssen Sie explizit deklarieren: Attribut android:exported für diese App-Komponenten.

Enthält die App-Komponente die Kategorie LAUNCHER, festgelegt android:exported bis 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 enthält. Filter, 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, aber nicht android:exported deklariert, wird die folgende Warnung Je nach verwendeter Android Studio-Version werden Nachrichten angezeigt:

Android Studio 2020.3.1 Canary 11 oder höher

Die folgenden Meldungen werden angezeigt:

In der Manifestdatei wird die folgende Lint-Warnung angezeigt:

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

Wenn Sie versuchen, Ihre App zu kompilieren, wird die folgende Build-Fehlermeldung angezeigt: 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, Logcat wird 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 der ausstehenden Intents

Wenn deine App auf Android 12 ausgerichtet ist, musst du die Veränderlichkeit von jedes PendingIntent-Objekts, das im App erstellt. 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 nach der folgende Lint-Warnung in Android Studio:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

Einführung unsicherer Intents

Zur Verbesserung der Plattformsicherheit bieten Android 12 und höher Debugging-Funktion zur Erkennung unsicherer Starts von Intents. Wann? das System einen so unsicheren Start erkennt, Verstoß StrictMode tritt 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 den Vordergrund nicht starten während der Ausführung im Hintergrund, mit Ausnahme einiger speziellen Cases. Wenn eine App versucht, einen Dienst im Vordergrund zu starten, während sie in der Hintergrund, tritt eine Ausnahme auf (mit Ausnahme der wenigen Sonderfälle).

Nutzen Sie WorkManager, um Termine schnell zu planen und zu starten. Arbeit während die App im Hintergrund läuft. Um zeitkritische Aktionen auszuführen, die starten Sie Dienste im Vordergrund innerhalb einer genauen

Berechtigung „Exakter Alarm“

Um Apps dazu zu ermutigen, Systemressourcen zu schonen, werden Apps, die Android 12 und höher und legen Sie Genau passend Alarme müssen Zugriff auf den Bereich "Wecker und Erinnerungen“ die im Bildschirm Spezieller App-Zugriff angezeigt wird. Systemeinstellungen.

Um Zugriff auf diese spezielle App zu erhalten, fordern Sie den SCHEDULE_EXACT_ALARM Berechtigung im Manifest.

Exakte Alarme sollten nur für Funktionen verwendet werden, die für den Nutzer sichtbar sind. Weitere Informationen zum Anwendungsfälle für die Festlegung einer genauen

Verhaltensänderung deaktivieren

Wenn du deine App auf Android 12 vorbereitest, kannst du die Verhaltensänderung in Ihrem Debug-fähigen Build zu deaktivieren, -Variante zu Testzwecken. Führen Sie dazu folgende Schritte aus: eine der folgenden Aufgaben ausführen:

Wähle auf dem Einstellungsbildschirm Entwickleroptionen die Option App-Kompatibilität Änderungen. Tippe auf dem angezeigten Bildschirm auf den Namen deiner App und schalte sie dann aus 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 Nutzende mit Benachrichtigungen erhalten, reagieren einige Apps auf Antippen von Benachrichtigungen durch Starten einer App Komponente, die schließlich den die der Nutzer schließlich sieht und mit denen er interagiert. Diese App-Komponente ist auch als Benachrichtigungstrampolin bezeichnet.

Zur Verbesserung der App-Leistung und Nutzerfreundlichkeit werden Apps, die auf Android 12 oder können keine Aktivitäten aus Diensten oder Übertragungsempfänger, die als Benachrichtigungs-Trampolinen. Mit anderen Worten: Nachdem Nutzende auf eine Benachrichtigung getippt haben, oder einer Aktionsschaltfläche im die Benachrichtigung enthält, kann die App startActivity() in einem Dienst oder Broadcast-Empfänger befinden.

Wenn deine App versucht, eine Aktivität von einem Dienst oder Übertragungsempfänger zu starten das als Benachrichtigungs-Trampolin fungiert, verhindert das System, dass die Aktivität und die folgende Meldung wird in Logcat:

Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.

Herausfinden, welche App-Komponenten als Benachrichtigungs-Trampolin fungieren

Wenn du deine App testest, kannst du nach dem Tippen auf eine Benachrichtigung herausfinden, Dienst oder Übertragungsempfänger in Ihrer App als Benachrichtigungstrampolin 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 notwendig sind, um die Komponente zu identifizieren, als Ergebnis einer Benachrichtigung.

App aktualisieren

Wenn Ihre App eine Aktivität von einem Dienst oder Übertragungsempfänger startet, der als ein Benachrichtigungs-Trampolin zu öffnen, führen Sie die folgenden Migrationsschritte aus:

Erstellen Sie ein PendingIntent-Objekt, das mit der Aktivität verknüpft ist, die Nutzer sehen, nachdem sie auf das Benachrichtigung.
Verwenden Sie das PendingIntent-Objekt, das Sie im vorherigen Schritt erstellt haben. wie Sie Ihre Benachrichtigung.

Um den Ursprung der Aktivität zu identifizieren, z. B. für die Protokollierung, beim Posten der Benachrichtigung Extras verwenden. Verwenden Sie für das zentralisierte Logging ActivityLifecycleCallbacks oder Jetpack-Lebenszyklus-Beobachter.

Verhalten aktivieren/deaktivieren

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

Back-up und Wiederherstellung

Änderungen an der Funktionsweise von Sichern und Wiederherstellen in Apps, die auf Android 12 (API-Level 31). Es gibt zwei Formen der Android-Sicherung und -Wiederherstellung:

Cloud-Sicherungen:Nutzerdaten werden im Google Drive-Konto eines Nutzers gespeichert, damit sie kann später auf diesem oder einem neuen Gerät wiederhergestellt werden.
D2D-Übertragungen (Gerät-zu-Gerät):Nutzerdaten werden direkt an das das neue Gerät des Nutzers von seinem älteren Gerät zu übertragen, z. B. per Kabel.

Weitere Informationen dazu, wie Daten gesichert und wiederhergestellt werden, finden Sie unter Nutzer sichern mit der automatischen Sicherung und Schlüssel/Wert-Paare sichern mit Android Backup Service

Änderungen an der D2D-Übertragungsfunktion

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

Regeln zum Einschließen und Ausschließen mit der XML-Datei der Konfigurationsmechanismus keine Auswirkungen auf D2D-Übertragungen hat, wirkt sich auf die cloudbasierte Sicherung und Wiederherstellung aus (z. B. Google Drive-Sicherungen). Bis Regeln für D2D-Übertragungen angeben, müssen Sie die neue im nächsten Abschnitt.
Auf Geräten von einigen Geräteherstellern kann android:allowBackup="false" deaktiviert Sicherungen in Google Drive, aber wird die D2D-Übertragung für die App nicht deaktiviert.

Neues Format zum Einschließen und Ausschließen

Apps, die auf Android 12 und höher laufen und darauf ausgerichtet sind, verwenden ein Format für die XML-Konfiguration. Dieses Format macht den Unterschied zwischen Google Drive-Sicherung und D2D-Übertragung explizit, indem Sie Separate Ein- und Ausschlussregeln für Cloud-Sicherungen und D2D festlegen übertragen werden.

Optional können Sie es auch verwenden, um Regeln für die Sicherung anzugeben. In diesem Fall wird der zuvor verwendete Konfiguration auf Geräten mit Android 12 oder höher liegen. Die ältere Konfiguration ist für Geräte mit Android 11 weiterhin erforderlich oder niedriger.

Änderungen am XML-Format

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

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

Manifest-Flag für Apps

Weisen Sie Ihre Apps mithilfe des Attribut android:dataExtractionRules in Ihrem Manifest -Datei. Wenn Sie auf die neue XML-Konfiguration verweisen, Das android:fullBackupContent-Attribut, das auf die alte Konfiguration verweist, wird ignoriert. auf Geräten mit Android 12 oder höher. Das folgende Codebeispiel zeigt das neue 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>

Konnektivität

Bluetooth-Berechtigungen

Mit Android 12 wird die BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE, und BLUETOOTH_CONNECT Berechtigungen. Diese Berechtigungen erleichtern es Apps, Android 12 zur Interaktion mit Bluetooth , insbesondere für Apps, die keine benötigen Zugriff auf den Gerätestandort.

Um Ihr Gerät für die Ausrichtung auf Android 12 oder höher vorzubereiten, aktualisieren Sie der App-Logik. Anstatt einen alten Bluetooth-Satz zu deklarieren Berechtigungen ein moderneres Bluetooth-Gerät Berechtigungen

Gleichzeitige Peer-to-Peer- und Internetverbindung

Bei Apps, die auf Android 12 (API-Level 31) oder höher ausgerichtet sind, werden Geräte, die den Die gleichzeitige Verwendung von Peer-to-Peer und Internetverbindungen ermöglicht das gleichzeitige Verwenden von mit dem Peer-Gerät und dem primären Netzwerk, das das Internet bereitstellt, und sorgt so für eine nahtlose User Experience. App-Targeting Unter Android 11 (API-Level 30) oder niedriger tritt weiterhin das alte Verhalten auf, bei dem Das primäre WLAN wird getrennt, bevor eine Verbindung zum Peer hergestellt wird. .

Kompatibilität

WifiManager.getConnectionInfo() kann WifiInfo für nur ein einziges Netzwerk. Aus diesem Grund wurde das Verhalten der API auf folgende Arten in Android 12 und höher:

Wenn nur ein einziges WLAN verfügbar ist, wird WifiInfo zurückgegeben.
Wenn mehrere WLANs verfügbar sind und die Anruf-App eine Peer-to-Peer-Verbindung ist der WifiInfo, der dem Peer-Gerät entspricht, zurückgegeben.
Wenn mehr als ein WLAN verfügbar ist und die Anruf-App nicht eine Peer-to-Peer-Verbindung auslösen, wird der WifiInfo wird zurückgegeben.

Um die Nutzerfreundlichkeit auf Geräten zu verbessern, die die gleichzeitige Verwendung von zwei Teilnehmern unterstützen WLANs empfehlen wir alle Apps – insbesondere solche, die Peer-to-Peer-Verbindungen: Migration weg von Aufrufen WifiManager.getConnectionInfo() und verwenden Sie stattdessen NetworkCallback.onCapabilitiesChanged() , um alle WifiInfo-Objekte abzurufen, die mit dem NetworkRequest übereinstimmen, der für die Registrierung verwendet wurde NetworkCallback. „getConnectionInfo()“ wurde verworfen am Android 12

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

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

Unter Android 12 können Apps mit dem mDNSReplyer-Daemon über der nativen mDNSReplyer API Zuvor, wenn eine App einen Dienst im Netzwerk registriert hat und die getSystemService() gestartet, hat der NSD-Dienst des Systems den mDNSReplyer-Daemon gestartet, auch wenn der App noch keine NsdManager-Methoden aufgerufen hat. Der Daemon hat dann an die Multicast-Gruppen für alle Knoten, wodurch das System und zusätzlich Strom verbrauchen. In Android 12 die Akkunutzung minimieren und höher startet das System den mDNSReplyer-Daemon nur bei Bedarf für NSD-Ereignisse und stoppt es anschließend.

Da sich diese Änderung darauf auswirkt, wann der mDNSReplyer-Daemon verfügbar ist, die davon ausgehen, dass der mDNSReplyer-Daemon nach dem Aufruf der Die Methode getSystemService() kann Nachrichten vom System empfangen, die angeben, dass Der mDNSReplyer-Daemon ist nicht verfügbar. Apps, die NsdManager verwenden, aber 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 Siliziumanbietern oder Geräteherstellern bereitgestellt werden, standardmäßig, wenn die App auf Android 12 (API-Level 31) oder höher ausgerichtet ist. Die Bibliotheken sind nur zugänglich, wenn sie explizit mithilfe der Methode <uses-native-library> Tag.

Wenn die App auf Android 11 (API-Level 30) oder niedriger ausgerichtet ist, <uses-native-library>-Tag ist nicht erforderlich. In diesem Fall können alle auf die Bibliothek zugegriffen werden kann, unabhängig davon, ob es sich um eine NDK-Bibliothek handelt.

Nicht-SDK-Einschränkungen aktualisiert

Android 12 enthält aktualisierte Listen mit eingeschränktem Nicht-SDK Benutzeroberflächen basierend auf der Zusammenarbeit mit Android-Entwicklern internen Tests. Wann immer möglich, achten wir darauf, dass öffentliche Alternativen bevor wir Nicht-SDK-Schnittstellen einschränken.

Wenn deine App nicht auf Android 12 ausgerichtet ist, gibt es einige dieser Änderungen nicht sofort betreffen. Obwohl Sie derzeit einige Nicht-SDK-Schnittstellen (abhängig vom Ziel-API-Level Ihrer App) die Verwendung einer Nicht-SDK-Methode oder eines Nicht-SDK-Felds birgt immer ein hohes Risiko, dass Ihre

Wenn Sie sich nicht sicher sind, ob Ihre App Nicht-SDK-Schnittstellen verwendet, können Sie Ihre App um es herauszufinden. Wenn Ihre App Nicht-SDK-Schnittstellen benötigt, sollten Sie mit der Planung eine Migration zu SDK-Alternativen. Dennoch ist uns bewusst, dass einige Apps Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen. Wenn Sie keine Alternative finden für eine Funktion in Ihrer App eine Nicht-SDK-Schnittstelle verwenden, sollten Sie eine neue öffentliche API.

Weitere Informationen zu den Änderungen in dieser Android-Version findest du unter Updates für Einschränkungen für Nicht-SDK-Schnittstellen in Android 12 Weitere Informationen zu Nicht-SDK-Schnittstellen im Allgemeinen siehe Einschränkungen für Nicht-SDK-Schnittstellen Benutzeroberflächen.