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
READ_MEDIA_AUDIO
anfordern.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:
Medientyp | Berechtigung zum Anfordern |
---|---|
Bilder und Fotos | READ_MEDIA_IMAGES |
Videos | READ_MEDIA_VIDEO |
Audiodateien | READ_MEDIA_AUDIO |
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.
Stellen | Aktion | Kriterien |
---|---|---|
1 | Wiedergeben |
Der aktuelle Status von PlaybackState ist einer der folgenden:
|
Rotierendes Ladesymbol |
Der aktuelle Status von PlaybackState ist einer der folgenden:
|
|
Pausieren | Der aktuelle Status von PlaybackState ist keiner der oben genannten. |
|
2 | Zurück | PlaybackState actions umfasst ACTION_SKIP_TO_PREVIOUS . |
Benutzerdefiniert | PlaybackState -Aktionen enthalten keine ACTION_SKIP_TO_PREVIOUS und PlaybackState -benutzerdefinierte Aktionen enthalten eine benutzerdefinierte Aktion, die noch nicht platziert wurde. |
|
Leer | PlaybackState extras enthält einen booleschen Wert true für den Schlüssel SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV . |
|
3 | Weiter | PlaybackState actions umfasst ACTION_SKIP_TO_NEXT . |
Benutzerdefiniert | PlaybackState -Aktionen enthalten keine ACTION_SKIP_TO_NEXT und PlaybackState -benutzerdefinierte Aktionen enthalten eine benutzerdefinierte Aktion, die noch nicht platziert wurde. |
|
Leer | PlaybackState extras enthält einen booleschen Wert true für den Schlüssel SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT . |
|
4 | Benutzerdefiniert | PlaybackState Benutzerdefinierte Aktionen enthalten eine benutzerdefinierte Aktion, die noch nicht platziert wurde. |
5 | Benutzerdefiniert | PlaybackState Benutzerdefinierte Aktionen enthalten eine benutzerdefinierte Aktion, die noch nicht platziert wurde. |
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.