Wie in früheren Releases enthält Android 13 Verhaltensänderungen, die sich auf deine App auswirken können. Die folgenden Verhaltensänderungen gelten ausschließlich für Apps, die auf Android 13 oder höher ausgerichtet sind. Wenn deine App auf Android 13 oder höher ausgerichtet ist, solltest du sie gegebenenfalls anpassen, um diese Verhaltensweisen zu unterstützen.
Sieh dir auch die Liste der Verhaltensänderungen an, die alle Apps unter Android 13 betreffen.
Datenschutz
Die Berechtigung zum Senden von Benachrichtigungen wirkt sich auf die Darstellung des Dienstes im Vordergrund aus
Wenn der Nutzer die Berechtigung zum Senden von Benachrichtigungen ablehnt, werden in der Benachrichtigungsleiste keine Hinweise zu Diensten im Vordergrund angezeigt. Nutzer sehen jedoch im Task-Manager weiterhin Hinweise zu Diensten im Vordergrund, unabhängig davon, ob die Berechtigung zum Senden von Benachrichtigungen gewährt wurde.
Neue Laufzeitberechtigung für WLAN-Geräte in der Nähe
Bei früheren Android-Versionen muss der Nutzer Ihrer App die Berechtigung ACCESS_FINE_LOCATION erteilen, um mehrere gängige WLAN-Anwendungsfälle auszuführen.
Da es für Nutzer schwierig ist, Standortberechtigungen mit WLAN-Funktionen zu verknüpfen, wird mit Android 13 (API-Level 33) in der Berechtigungsgruppe NEARBY_DEVICES eine Laufzeitberechtigung für Apps eingeführt, die die Verbindungen eines Geräts zu Zugangspunkten in der Nähe über WLAN verwalten. Die Berechtigung NEARBY_WIFI_DEVICES erfüllt folgende WLAN-Anwendungsfälle:
- Geräte in der Nähe suchen oder eine Verbindung zu ihnen herstellen, z. B. Drucker oder Geräte zum Streamen von Medien
Mit diesem Workflow kann Ihre App folgende Arten von Aufgaben ausführen:
- AP-Informationen außerhalb des Bandes empfangen, z. B. über BLE.
- Erkennen und verbinden Sie sich über Wi-Fi Aware mit einem Hotspot, der nur lokal verfügbar ist.
- Geräte erkennen und über Wi-Fi Direct verbinden
- Verbindung mit einer bekannten SSID herstellen, z. B. einem Auto oder Smart-Home-Gerät
- Starten Sie einen nur lokalen Hotspot.
- Reichweite auf WLAN-fähige Geräte in der Nähe.
Solange deine App keine Informationen zum physischen Standort von den Wi-Fi APIs ableitet, fordern Sie NEARBY_WIFI_DEVICES anstelle von ACCESS_FINE_LOCATION an, wenn Sie Ihre App auf Android 13 oder höher ausrichten und Wi-Fi APIs verwenden. Wenn du die Berechtigung NEARBY_WIFI_DEVICES festlegst, solltest du unbedingt darauf achten, dass deine App niemals Informationen zum physischen Standort von Wi-Fi APIs ableitet. Setzen Sie dazu das Attribut android:usesPermissionFlags auf neverForLocation. Dieser Vorgang ähnelt dem unter Android 12 (API-Level 31) und höher, wenn du versicherst, dass keine Bluetooth-Geräteinformationen zur Standortermittlung verwendet werden.
Weitere Informationen zum Anfordern einer Berechtigung für den Zugriff auf WLAN-Geräte in der Nähe
Detaillierte Medienberechtigungen
READ_MEDIA_AUDIO anfordern.Wenn deine App auf Android 13 oder höher ausgerichtet ist und auf Mediendateien zugreifen muss, die von anderen Apps erstellt wurden, musst du 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, prüfen Sie, ob der Nutzer Ihrer App die entsprechenden detaillierten Medienberechtigungen gewährt hat.
Abbildung 1 zeigt eine App, die die Berechtigung READ_MEDIA_AUDIO anfordert.
Wenn Sie die Berechtigungen READ_MEDIA_IMAGES und READ_MEDIA_VIDEO gleichzeitig anfordern, wird nur ein Dialogfeld für Systemberechtigungen 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 aktualisierte 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
Mit Android 13 wird das Konzept des Zugriffs auf Körpersensoren während der Nutzung, wie die Herzfrequenz, die Temperatur und die Sauerstoffsättigung, eingeführt. Dieses Zugriffsmodell ähnelt sehr dem, das das System für den Standort in Android 10 (API-Ebene 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 die neue Berechtigung BODY_SENSORS_BACKGROUND zusätzlich zur bestehenden Berechtigung BODY_SENSORS deklarieren.
Leistung und Akku
Akkuressourcennutzung
Wenn der Nutzer deine App aufgrund der Akkunutzung im Hintergrund in den Status „Eingeschränkt“ vergibt, während deine App auf Android 13 ausgerichtet ist, liefert das System die Übertragung BOOT_COMPLETED oder LOCKED_BOOT_COMPLETED erst aus, wenn die App aus anderen Gründen gestartet wird.
Nutzererfahrung
Von PlaybackState abgeleitete Mediensteuerelemente
Für Apps, die auf Android 13 (API-Level 33) und höher ausgerichtet sind, leitet das System Mediensteuerelemente aus PlaybackState-Aktionen ab. So kann das System mehr Steuerelemente anzeigen, die technisch einheitlich auf Smartphones und Tablets dargestellt werden und sich an die Darstellung von Mediensteuerelementen auf anderen Android-Plattformen wie Android Auto und Android TV anpassen.
Abbildung 2 zeigt ein Beispiel dafür, wie dies auf einem Smartphone bzw. Tablet aussieht.
Vor Android 13 hat das 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 werden vom System bis zu fünf Aktionsschaltflächen basierend auf PlaybackState angezeigt, wie in der folgenden Tabelle beschrieben. Im kompakten Modus werden nur die ersten drei Aktionsslots angezeigt. Bei Apps, die nicht auf Android 13 ausgerichtet sind oder keine PlaybackState enthalten, zeigt das System Steuerelemente auf der Grundlage der Liste Action an, die der MediaStyle-Benachrichtigung hinzugefügt wurde, wie im vorherigen Abschnitt beschrieben.
| Stellen | Aktion | Kriterien |
|---|---|---|
| 1 | Abspielen |
Der aktuelle Status des PlaybackState ist einer der folgenden:
|
| Rotierendes Ladesymbol |
Der aktuelle Status des PlaybackState ist einer der folgenden:
|
|
| Pausieren | Der aktuelle Status von PlaybackState entspricht keinem der oben genannten Werte. |
|
| 2 | Zurück | PlaybackState Aktionen umfassen ACTION_SKIP_TO_PREVIOUS. |
| Benutzerdefiniert | PlaybackState Aktionen enthalten ACTION_SKIP_TO_PREVIOUS nicht und PlaybackState benutzerdefinierte Aktionen enthalten eine noch nicht platzierte benutzerdefinierte Aktion. |
|
| Leer | PlaybackState Extras enthalten einen booleschen Wert true für den Schlüssel SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV. |
|
| 3 | Weiter | PlaybackState Aktionen umfassen ACTION_SKIP_TO_NEXT. |
| Benutzerdefiniert | PlaybackState Aktionen enthalten ACTION_SKIP_TO_NEXT nicht und PlaybackState benutzerdefinierte Aktionen enthalten eine noch nicht platzierte benutzerdefinierte Aktion. |
|
| Leer | PlaybackState Extras enthalten 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.
App-Farbdesign wird automatisch auf WebView-Inhalte angewendet
Bei Apps, die auf Android 13 (API-Level 33) oder höher ausgerichtet sind, wird die Methode setForceDark() eingestellt. Wenn die Methode aufgerufen wird, erfolgt ein Nullbefehl.
Stattdessen legt WebView die Medienabfrage prefers-color-scheme jetzt immer gemäß dem Themenattribut isLightTheme der App fest. Mit anderen Worten: Wenn isLightTheme true ist oder nicht angegeben ist, ist prefers-color-scheme light. Andernfalls ist es dark. Das bedeutet, dass der helle oder dunkle Stil der Webinhalte automatisch an das Design der App angepasst wird, sofern der Inhalt dies unterstützt.
Bei den meisten Apps werden durch das neue Verhalten die entsprechenden App-Stile automatisch angewendet. Sie sollten Ihre App jedoch testen, um zu prüfen, ob Sie die Einstellungen für den dunklen Modus möglicherweise manuell festgelegt haben.
Wenn Sie das Farbschema Ihrer App trotzdem anpassen möchten, verwenden Sie stattdessen die Methode setAlgorithmicDarkeningAllowed(). Aus Gründen der Abwärtskompatibilität mit früheren Android-Versionen empfehlen wir die Verwendung der entsprechenden Methode setAlgorithmicDarkeningAllowed() in AndroidX.
In der Dokumentation zu dieser Methode findest du weitere Informationen dazu, welches Verhalten du je nach targetSdkVersion- und Designeinstellungen deiner App in deiner App erwarten kannst.
Konnektivität
BluetoothAdapter#enable() und BluetoothAdapter#disable() eingestellt
Für Apps, die auf Android 13 (API-Level 33) oder höher ausgerichtet sind, werden die Methoden BluetoothAdapter#enable() und BluetoothAdapter#disable() eingestellt. Sie geben immer false zurück.
Die folgenden Arten von Apps sind von diesen Änderungen ausgenommen:
- Apps von Geräteeigentümern
- Apps von Profilinhabern
- System-Apps
Google Play-Dienste
Berechtigung für Werbe-ID erforderlich
Für Apps, die die Werbe-ID der Google Play-Dienste verwenden und auf Android 13 (API-Level 33) und höher ausgerichtet sind, muss in der Manifestdatei der App die normale Berechtigung AD_ID so 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 diese Berechtigung für Ihre App bei der Ausrichtung auf Android 13 oder höher nicht deklariert ist, wird die Werbe-ID automatisch entfernt und durch eine Reihe von Nullen ersetzt.
Wenn Ihre App SDKs verwendet, 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 musst du die Berechtigung nicht in der Manfiest-Datei deiner App deklarieren.
Weitere Informationen findest du in der Play Console-Hilfe unter Werbe-ID.
Nicht-SDK-Einschränkungen aktualisiert
Android 13 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 13 ausgerichtet ist, betreffen dich einige dieser Änderungen möglicherweise nicht sofort. Derzeit können Sie zwar einige Nicht-SDK-Schnittstellen verwenden (je nach Ziel-API-Level Ihrer App), aber bei Verwendung von Nicht-SDK-Methoden und -Feldern besteht immer ein hohes Risiko, dass Ihre App nicht mehr funktioniert.
Wenn du nicht sicher bist, ob deine App Nicht-SDK-Schnittstellen verwendet, kannst du die App testen, um es herauszufinden. Wenn Ihre App Nicht-SDK-Schnittstellen benötigt, sollten Sie eine Migration zu SDK-Alternativen planen. Uns ist aber bewusst, dass es bei einigen Apps gültige Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen gibt. Wenn Sie für ein Feature 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 Updates für Nicht-SDK-Schnittstelleneinschränkungen in Android 13. Allgemeine Informationen zu Nicht-SDK-Schnittstellen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen.