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 anpassen, dass sie diese Verhaltensweisen richtig unterstützt.

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 für Benachrichtigungen wirkt sich auf die Darstellung von Vordergrunddiensten aus

Wenn der Nutzer die Berechtigung für Benachrichtigungen ablehnt, werden ihm keine Benachrichtigungen zu Diensten im Vordergrund in der Benachrichtigungsleiste angezeigt. Nutzer sehen jedoch weiterhin Benachrichtigungen zu Diensten im Vordergrund im Task-Manager, unabhängig davon, ob die Berechtigung für Benachrichtigungen erteilt wurde.

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

In früheren Android-Versionen muss der Nutzer Ihrer App die Berechtigung ACCESS_FINE_LOCATION erteilen, damit mehrere gängige WLAN-Anwendungsfälle ausgeführt werden können.

Da es für Nutzer schwierig ist, Berechtigungen zur Standortermittlung mit WLAN-Funktionen in Verbindung zu bringen, wird in Android 13 (API-Level 33) eine Laufzeitberechtigung in der Berechtigungsgruppe NEARBY_DEVICES für Apps eingeführt, die die Verbindungen eines Geräts zu Access Points in der Nähe über WLAN verwalten. Diese Berechtigung, NEARBY_WIFI_DEVICES, erfüllt WLAN-Anwendungsfälle wie die folgenden:

• Geräte in der Nähe finden oder eine Verbindung zu ihnen herstellen, z. B. zu Druckern oder Geräten für das Media-Streaming. Mit diesem Workflow kann Ihre App die folgenden Arten von Aufgaben ausführen:
  • AP-Informationen werden out-of-band empfangen, z. B. über BLE.
  • Geräte über Wi‑Fi Aware erkennen und eine Verbindung zu ihnen herstellen und eine Verbindung über einen lokal beschränkten 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.
• Starten Sie einen Hotspot, der nur lokal verfügbar ist.
• Reichweite zu Wi‑Fi Aware-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 ausdrücklich bestätigen, dass Ihre App niemals Informationen zum physischen Standort aus WLAN-APIs ableitet. Legen Sie dazu das Attribut android:usesPermissionFlags auf neverForLocation fest. Dieser Prozess ähnelt dem in Android 12 (API-Level 31) und höher, wenn Sie bestätigen, dass Bluetooth-Geräteinformationen 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

Detaillierte Media-Berechtigungen

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 Medienberechtigungen anfordern:

Bevor Sie auf die Mediendateien einer anderen App zugreifen, müssen Sie prüfen, ob der Nutzer Ihrer App die entsprechenden detaillierten Medienberechtigungen erteilt hat.

Abbildung 1 zeigt eine App, die die Berechtigung READ_MEDIA_AUDIO anfordert.

Wenn Sie gleichzeitig die Berechtigung READ_MEDIA_IMAGES und die Berechtigung READ_MEDIA_VIDEO anfordern, wird nur ein Systemberechtigungsdialogfeld angezeigt.

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

adb shell cmd appops get --uid PACKAGE_NAME

Für die Verwendung von Körpersensoren im Hintergrund ist eine neue Berechtigung erforderlich

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

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

Leistung und Akku

Akkunutzung

Wenn der Nutzer Ihre App für die Akkunutzung im Hintergrund in den eingeschränkten Status versetzt, während Ihre App auf Android 13 ausgerichtet ist, sendet das System die Broadcasts BOOT_COMPLETED und LOCKED_BOOT_COMPLETED erst, wenn die App aus anderen Gründen gestartet wird.

Nutzererfahrung

Mediensteuerelemente, die aus PlaybackState abgeleitet wurden

Bei Apps, die auf Android 13 (API‑Level 33) und höher ausgerichtet sind, leitet das System die Media-Steuerelemente 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 der Darstellung von Mediensteuerelementen auf anderen Android-Plattformen wie Android Auto und Android TV entsprechen.

Abbildung 2 zeigt ein Beispiel dafür, wie das auf einem Smartphone und einem Tablet aussieht.

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

Ab Android 13 zeigt das System bis zu fünf Aktionsschaltflächen basierend auf dem 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, werden die Steuerelemente basierend auf der Action-Liste angezeigt, die der MediaStyle-Benachrichtigung hinzugefügt wurde, wie im vorherigen Absatz beschrieben.

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

Das Farbdesign der App wird automatisch auf WebView-Inhalte angewendet

Bei Apps, die auf Android 13 (API‑Level 33) oder höher ausgerichtet sind, ist die Methode setForceDark() eingestellt. Wenn die Methode aufgerufen wird, wird nichts ausgeführt.

Stattdessen wird die Media-Anfrage prefers-color-scheme jetzt immer gemäß dem Designattribut der App, isLightTheme, festgelegt. Wenn isLightTheme also true ist oder nicht angegeben wird, ist prefers-color-scheme light. Andernfalls ist prefers-color-scheme dark. Das bedeutet, dass das helle oder dunkle Design des Webinhalts automatisch an das Design der App angepasst wird, sofern 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 Dark Mode manuell gesteuert haben.

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

In der Dokumentation zu dieser Methode finden Sie weitere Informationen dazu, welches Verhalten Sie in Ihrer App erwarten können, je nach den targetSdkVersion- und Theme-Einstellungen 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 Methoden BluetoothAdapter#enable() und BluetoothAdapter#disable() eingestellt und geben immer false zurück.

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

• Apps für Geräteinhaber
• Apps des Profilinhabers
• System-Apps

Google Play-Dienste

Berechtigung für Werbe-ID erforderlich

Für Apps, die die Werbe-ID von Google Play-Diensten verwenden und auf Android 13 (API‑Level 33) und höher ausgerichtet sind, muss die normale Berechtigung AD_ID in der Manifestdatei der App deklariert werden:

<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, wenn 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, für die im Manifest der Bibliothek die Berechtigung AD_ID deklariert wird, 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-SDKs

Android 13 enthält aktualisierte Listen eingeschränkter Nicht-SDK-Schnittstellen, die auf der Zusammenarbeit mit Android-Entwicklern und den neuesten internen Tests basieren. Wir sorgen nach Möglichkeit dafür, dass öffentliche Alternativen verfügbar sind, bevor wir Nicht-SDK-Schnittstellen einschränken.

Wenn Ihre App nicht auf Android 13 ausgerichtet ist, wirken sich einige dieser Änderungen möglicherweise nicht sofort auf Sie aus. Derzeit können Sie zwar einige Nicht-SDK-Schnittstellen verwenden (abhängig vom Ziel-API-Level Ihrer App), die Verwendung einer Nicht-SDK-Methode oder eines Nicht-SDK-Felds 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 das herauszufinden. Wenn Ihre App auf Nicht-SDK-Schnittstellen basiert, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Wir verstehen jedoch, dass einige Apps gültige Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen haben. 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 to non-SDK interface restrictions in Android 13. Weitere Informationen zu Nicht-SDK-Schnittstellen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen.