Verhaltensänderungen: Apps, die auf Android 13 oder höher ausgerichtet sind

Wie bei früheren Versionen enthält Android 13 Verhaltensänderungen, die sich auf Ihre App auswirken können. Die folgenden Verhaltensänderungen gelten ausschließlich für Apps, die auf Android 13 oder höher ausgerichtet sind. Wenn Ihre App auf Android 13 oder höher ausgerichtet ist, sollten Sie sie gegebenenfalls so ändern, dass diese Verhaltensweisen richtig unterstützt werden.

Sehen Sie sich auch die Liste der Verhaltensänderungen an, die sich auf alle Apps auswirken, die unter Android 13 ausgeführt werden.

Datenschutz

Berechtigung zum Senden von Benachrichtigungen wirkt sich auf Darstellung von Diensten im Vordergrund aus

Wenn der Nutzer die Berechtigung zum Senden von Benachrichtigungen verweigert, werden ihm im Benachrichtigungsfeld keine Benachrichtigungen zu Diensten im Vordergrund angezeigt. Benachrichtigungen zu Diensten im Vordergrund werden Nutzern jedoch weiterhin im Task-Manager angezeigt, unabhängig davon, ob die Berechtigung zum Senden von Benachrichtigungen erteilt wurde.

Neue Laufzeitberechtigung für WLAN-Geräte in der Nähe

In früheren Versionen von Android muss der Nutzer Ihrer App die ACCESS_FINE_LOCATION Berechtigung erteilen, um mehrere gängige WLAN-Anwendungsfälle abzuschließen.

Da es für Nutzer schwierig ist, Standortberechtigungen mit der WLAN Funktionalität zu verknüpfen, wird in Android 13 (API-Level 33) eine Laufzeitberechtigung in der NEARBY_DEVICES Berechtigungsgruppe für Apps eingeführt, die die Verbindungen eines Geräts zu Zugriffspunkten in der Nähe über WLAN verwalten. Diese Berechtigung, NEARBY_WIFI_DEVICES, deckt WLAN-Anwendungsfälle wie die folgenden ab:

• Geräte in der Nähe finden oder eine Verbindung zu ihnen herstellen, z. B. Drucker oder Geräte für die Medienübertragung. Mit diesem Workflow kann Ihre App folgende Aufgaben ausführen:
  • AP-Informationen außerhalb des Bandes empfangen, z. B. über BLE.
  • Geräte über Wi-Fi Aware finden und eine Verbindung zu ihnen herstellen und eine Verbindung über einen rein lokalen Hotspot herstellen.
  • Geräte über Wi-Fi Direct finden und eine Verbindung zu ihnen herstellen.
• Eine Verbindung zu einer bekannten SSID herstellen, z. B. zu einem Auto oder einem Smart-Home-Gerät.
• Einen rein lokalen Hotspot starten.
• Reichweite zu WLAN-Geräten in der Nähe.

Solange Ihre App keine Informationen zum physischen Standort aus den WLAN-APIs ableitet, fordern Sie NEARBY_WIFI_DEVICES anstelle von ACCESS_FINE_LOCATION an, wenn Sie auf Android 13 oder höher ausgerichtet sind und WLAN-APIs verwenden. Wenn Sie die Berechtigung NEARBY_WIFI_DEVICES deklarieren, müssen Sie unbedingt angeben, dass Ihre App niemals Informationen zum physischen Standort aus WLAN-APIs ableitet. Setzen Sie dazu das Attribut android:usesPermissionFlags auf neverForLocation. Dieser Vorgang ist ähnlich dem in Android 12 (API-Level 31) und höher, wenn Sie angeben, dass Informationen zu Bluetooth-Geräten niemals für den Standort verwendet werden.

Weitere Informationen zum Anfordern der Berechtigung für den Zugriff auf WLAN-Geräte in der Nähe Weitere Informationen zum Anfordern der Berechtigung für den Zugriff auf WLAN-Geräte in der Nähe.

Detaillierte Berechtigungen für Medien

Wenn Ihre App auf Android 13 oder höher ausgerichtet ist und auf Mediendateien zugreifen muss, die von anderen Apps erstellt wurden, müssen Sie anstelle der Berechtigung READ_EXTERNAL_STORAGE eine oder mehrere der folgenden detaillierten Berechtigungen für Medien anfordern:

Bevor Sie auf die Mediendateien einer anderen App zugreifen, prüfen Sie, ob der Nutzer Ihrer App die entsprechenden detaillierten Berechtigungen für Medien erteilt hat.

In Abbildung 1 ist eine App zu sehen, die die Berechtigung READ_MEDIA_AUDIO anfordert.

Wenn Sie gleichzeitig die Berechtigungen READ_MEDIA_IMAGES und READ_MEDIA_VIDEO anfordern, wird nur ein Dialogfeld für Systemberechtigungen angezeigt.

Wenn Ihrer App zuvor die READ_EXTERNAL_STORAGE erteilt wurde, werden alle angeforderten READ_MEDIA_* beim Upgrade automatisch erteilt. Mit dem folgenden ADB-Befehl können Sie die aktualisierten Berechtigungen prüfen:

adb shell cmd appops get --uid PACKAGE_NAME

Verwendung von Körpersensoren im Hintergrund erfordert neue Berechtigung

In Android 13 wird das Konzept des Zugriffs „Während der Nutzung“ für Körpersensoren eingeführt, z. B. für die Herzfrequenz, die Temperatur und die Sauerstoffsättigung. Dieses Zugriffsmodell ähnelt dem, das das System in Android 10 (API-Level 29)für den Standort eingeführt hat.

Wenn Ihre App auf Android 13 ausgerichtet ist und Zugriff auf Informationen von Körpersensoren benötigt, während sie im Hintergrund ausgeführt wird, müssen Sie zusätzlich zur vorhandenen BODY_SENSORS Berechtigung die neue BODY_SENSORS_BACKGROUND Berechtigung deklarieren.

Leistung und Akku

Akkunutzung

Wenn der Nutzer Ihre App auf den Status „Eingeschränkt“ für die Akkunutzung im Hintergrund setzt, während Ihre App auf Android 13 ausgerichtet ist, liefert das System die BOOT_COMPLETED Übertragung oder die LOCKED_BOOT_COMPLETED Übertragung erst, wenn die App aus anderen Gründen gestartet wird.

Nutzer

Mediensteuerelemente aus PlaybackState abgeleitet

Bei Apps, die auf Android 13 (API-Level 33) und höher ausgerichtet sind, leitet das System die Mediensteuerelemente von PlaybackState-Aktionen ab. So kann das System eine größere Auswahl an Steuerelementen anzeigen, die technisch zwischen Smartphones und Tablets konsistent sind und auch mit der Darstellung von Mediensteuerelementen auf anderen Android-Plattformen wie Android Auto und Android TV übereinstimmen.

In Abbildung 2 ist ein Beispiel dafür zu sehen, wie das auf einem Smartphone bzw. Tablet aussieht.

Vor Android 13 zeigte das System bis zu fünf Aktionen aus der MediaStyle Benachrichtigung in der Reihenfolge an, in der sie hinzugefügt wurden. Im kompakten Modus, z. B. in den minimierten Schnelleinstellungen, wurden bis zu drei Aktionen angezeigt, die mit setShowActionsInCompactView() angegeben wurden.

Ab Android 13 zeigt das System bis zu fünf Aktionsschaltflächen basierend auf PlaybackState an, wie in der folgenden Tabelle beschrieben. Im kompakten Modus werden nur die ersten drei Aktionsfelder angezeigt. Bei Apps, die nicht auf Android 13 ausgerichtet sind oder kein PlaybackState enthalten, zeigt das System Steuerelemente basierend auf der Liste Action an, die der MediaStyle-Benachrichtigung hinzugefügt wurde, wie im vorherigen Absatz beschrieben.

Benutzerdefinierte Aktionen werden in der Reihenfolge platziert, in der sie zu PlaybackState hinzugefügt wurden.

Farbschema der App wird automatisch auf WebView-Inhalte angewendet

Bei Apps, die auf Android 13 (API-Level 33) oder höher ausgerichtet sind, ist die setForceDark() Methode veraltet. Wenn die Methode aufgerufen wird, passiert nichts.

Stattdessen legt WebView jetzt immer die Medienabfrage prefers-color-scheme gemäß dem Designattribut der App, isLightTheme, fest. Wenn isLightTheme also true ist oder nicht angegeben wurde, ist prefers-color-scheme light. Andernfalls ist es dark. Das bedeutet, dass der helle oder dunkle Stil des Webinhalts automatisch an das Design der App angepasst wird, wenn der Inhalt dies unterstützt.

Bei den meisten Apps sollten die entsprechenden App-Stile automatisch angewendet werden. Sie sollten Ihre App jedoch testen, um zu prüfen, ob Sie die Einstellungen für den dunklen Modus manuell gesteuert haben.

Wenn Sie das Verhalten des Farbschemas Ihrer App weiterhin anpassen müssen, verwenden Sie stattdessen die setAlgorithmicDarkeningAllowed() Methode. Für die Abwärtskompatibilität mit früheren Android-Versionen empfehlen wir, die entsprechende Methode in AndroidX zu verwenden.setAlgorithmicDarkeningAllowed()

In der Dokumentation zu dieser Methode erfahren Sie mehr darüber, welches Verhalten Sie in Ihrer App erwarten können, je nach targetSdkVersion und Designeinstellungen Ihrer App.

Konnektivität

`BluetoothAdapter#enable()` und `BluetoothAdapter#disable()` sind veraltet

Bei Apps, die auf Android 13 (API-Level 33) oder höher ausgerichtet sind, sind die BluetoothAdapter#enable() und BluetoothAdapter#disable() Methoden veraltet und geben immer false zurück.

Die folgenden Arten von Apps sind von diesen Änderungen ausgenommen:

• Apps für Geräteinhaber
• Apps für Profilinhaber
• System-Apps

Google Play-Dienste

Berechtigung für Werbe-ID erforderlich

Apps, die die Werbe-ID der Google Play-Dienste verwenden und auf Android 13 (API-Level 33) und höher ausgerichtet sind, müssen die normale Berechtigung AD_ID in der Manifestdatei ihrer App deklarieren:

<manifest ...>
    <!-- Required only if your app targets Android 13 or higher. -->
    <uses-permission android:name="com.google.android.gms.permission.AD_ID"/>

    <application ...>
        ...
    </application>
</manifest>

Wenn Ihre App diese Berechtigung nicht deklariert, während sie auf Android 13 oder höher ausgerichtet ist, wird die Werbe-ID automatisch entfernt und durch eine Reihe von Nullen ersetzt.

Wenn in Ihrer App SDKs verwendet werden, die die Berechtigung AD_ID im Manifest der Bibliothek deklarieren, wird die Berechtigung standardmäßig mit der Manifestdatei Ihrer App zusammengeführt. In diesem Fall müssen Sie die Berechtigung nicht in der Manifestdatei Ihrer App deklarieren.

Weitere Informationen finden Sie in der Play Console-Hilfe unter Werbe ID.

Aktualisierte Einschränkungen für Nicht-SDK-Schnittstellen

Android 13 enthält aktualisierte Listen eingeschränkter Nicht-SDK-Schnittstellen, die auf der Zusammenarbeit mit Android-Entwicklern und den neuesten internen Tests basieren. Wo immer möglich, stellen wir sicher, dass öffentliche Alternativen verfügbar sind, bevor wir Nicht-SDK-Schnittstellen einschränken.

Wenn Ihre App nicht auf Android 13 ausgerichtet ist, wirken sich einige dieser Änderungen möglicherweise nicht sofort auf Sie aus. Sie können derzeit zwar einige Nicht-SDK-Schnittstellen verwenden (je nach Ziel-API-Level Ihrer App), aber die Verwendung einer Nicht-SDK-Methode oder eines Nicht-SDK-Felds birgt 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 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 Version von Android finden Sie unter Updates zu Einschränkungen für Nicht-SDK-Schnittstellen in Android 13. Weitere Informationen zu Nicht-SDK-Schnittstellen im Allgemeinen finden Sie unter Einschränkungen für Nicht-SDK Schnittstellen.