Wie auch in früheren Versionen umfasst auch Android 13 Verhaltensänderungen, die sich auf deine App auswirken können. Die folgenden Ä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 diese Verhaltensweisen korrekt unterstützt werden.
Sehen Sie sich unbedingt auch die Liste der Verhaltensänderungen an, die sich auf alle Apps unter Android 13 auswirken.
Datenschutz
Die Berechtigung für Benachrichtigungen wirkt sich auf die Darstellung von Diensten im Vordergrund aus
Wenn der Nutzer die Benachrichtigungsberechtigung ablehnt, werden auf der Benachrichtigungsleiste keine Hinweise zu Diensten im Vordergrund angezeigt. Nutzer sehen jedoch weiterhin Hinweise zu Diensten im Vordergrund im Task-Manager, unabhängig davon, ob die Berechtigung zum Senden von Benachrichtigungen gewährt wurde.
Neue Laufzeitberechtigung für WLAN-Geräte in der Nähe
In früheren Android-Versionen muss der Nutzer deiner App die Berechtigung ACCESS_FINE_LOCATION erteilen, um mehrere gängige WLAN-Anwendungsfälle auszuführen.
Da es für Nutzer schwierig ist, der WLAN-Funktion Standortberechtigungen zuzuordnen, führt Android 13 (API-Level 33) eine Laufzeitberechtigung in der Berechtigungsgruppe NEARBY_DEVICES für Apps ein, die die Verbindungen eines Geräts zu nahe gelegenen Zugangspunkten über WLAN verwalten. Die Berechtigung NEARBY_WIFI_DEVICES dient unter anderem für WLAN-Anwendungsfälle:
- Geräte in der Nähe finden oder eine Verbindung zu ihnen herstellen, z. B. Drucker oder Geräte zum Streamen von Medien.
Mit diesem Workflow kann Ihre App folgende Aufgaben ausführen:
- AP-Informationen außerhalb des Bandes empfangen, z. B. über BLE.
- Du kannst Geräte über WLAN-Aware finden, mit ihnen verbinden und eine Verbindung über einen lokalen Hotspot herstellen.
- Geräte über Wi-Fi Direct erkennen und mit ihnen verbinden.
- Stelle eine Verbindung zu einer bekannten SSID her, z. B. zu einem Auto oder Smart-Home-Gerät.
- Starten Sie einen lokalen Hotspot.
- Reichweite zu WLAN-Aware-Geräten in der Nähe.
Wenn 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 eine Ausrichtung auf Android 13 oder höher vornehmen und Wi-Fi APIs verwenden. Wenn du die Berechtigung NEARBY_WIFI_DEVICES angibst, solltest du unbedingt darauf hinweisen, 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 bestätigst, dass nie Bluetooth-Geräteinformationen 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 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 | Anfrageberechtigung |
|---|---|
| Bilder und Fotos | READ_MEDIA_IMAGES |
| Videos | READ_MEDIA_VIDEO |
| Audiodateien | READ_MEDIA_AUDIO |
Bevor Sie auf die Mediendateien einer anderen Anwendung zugreifen, prüfen Sie, 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 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 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
Mit Android 13 wird der Zugriff auf Körpersensoren wie Herzfrequenz, Temperatur und Sauerstoffsättigung während der Nutzung eingeführt. Dieses Zugriffsmodell ist demjenigen sehr ähnlich, das das System für die Standortbestimmung 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 bestehenden BODY_SENSORS-Berechtigung die neue Berechtigung BODY_SENSORS_BACKGROUND deklarieren.
Leistung und Akku
Verbrauch von Akkuressourcen
Wenn der Nutzer Ihre App für die Nutzung des Hintergrundakkus in den Status „Eingeschränkt“ versetzt, während sie auf Android 13 ausgerichtet ist, sendet das System die BOOT_COMPLETED- oder LOCKED_BOOT_COMPLETED-Broadcasts erst, wenn die App aus anderen Gründen gestartet wurde.
Nutzererfahrung
Von „PlaybackState“ abgeleitete Mediensteuerelemente
Bei Apps, die auf Android 13 (API-Level 33) und höher ausgerichtet sind, leitet das System die Mediensteuerelemente von PlaybackState-Aktionen ab. Dadurch kann das System mehr Steuerelemente anzeigen, die technisch auf Smartphones und Tablets einheitlich sind und der Darstellung von Mediensteuerelementen auf anderen Android-Plattformen wie Android Auto und Android TV entsprechen.
Abbildung 2 zeigt ein Beispiel dafür, wie dies auf einem Smartphone bzw. Tablet dargestellt wird.
Vor Android 13 wurden vom 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 PlaybackState an, wie in der folgenden Tabelle beschrieben. Im kompakten Modus werden nur die ersten drei
Aktionsflächen angezeigt. Für Apps, die nicht auf Android 13 ausgerichtet sind, oder Apps, die kein PlaybackState enthalten, zeigt das System Steuerelemente auf Grundlage der Action-Liste an, die der MediaStyle-Benachrichtigung hinzugefügt wurde, wie im vorherigen Abschnitt beschrieben.
| Stellen | Aktion | Kriterien |
|---|---|---|
| 1 | Spielen |
Aktueller Status von PlaybackState ist einer der folgenden:
|
| Rotierendes Ladesymbol |
Aktueller Status von PlaybackState ist einer der folgenden:
|
|
| Pausieren | Aktueller Status von PlaybackState entspricht keiner der oben genannten Optionen. |
|
| 2 | Zurück | PlaybackState Aktionen umfassen 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 enthalten den 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 keine ACTION_SKIP_TO_NEXT und PlaybackState benutzerdefinierte Aktionen enthalten eine benutzerdefinierte Aktion, die noch nicht platziert wurde. |
|
| Leer | PlaybackState Extras enthalten den booleschen Wert true für den Schlüssel SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT. |
|
| 4 | Benutzerdefiniert | PlaybackState benutzerdefinierte Aktionen umfassen eine benutzerdefinierte Aktion, die noch nicht platziert wurde. |
| 5 | Benutzerdefiniert | PlaybackState benutzerdefinierte Aktionen umfassen eine benutzerdefinierte Aktion, die noch nicht platziert wurde. |
Benutzerdefinierte Aktionen werden in der Reihenfolge angeordnet, in der sie dem PlaybackState hinzugefügt wurden.
App-Farbdesign wird automatisch auf WebView-Inhalte angewendet
Für Apps, die auf Android 13 (API-Level 33) oder höher ausgerichtet sind, wurde die Methode setForceDark() verworfen. Beim Aufruf der Methode kommt es zu einem Nullvorgang.
Stattdessen wird die Medienabfrage prefers-color-scheme jetzt immer gemäß dem Theme-Attribut der App (isLightTheme) festgelegt. 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 des Webinhalts automatisch an das Design der App angepasst wird, sofern der Inhalt dies unterstützt.
Bei den meisten Apps sollten durch das neue Verhalten 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 möglicherweise manuell geändert haben.
Wenn Sie das Farbschema Ihrer App trotzdem anpassen müssen, verwenden Sie stattdessen die Methode setAlgorithmicDarkeningAllowed(). Für die 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 abhängig von den targetSdkVersion- und Designeinstellungen Ihrer App in Ihrer Anwendung erwarten können.
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() verworfen und geben immer false zurück.
Die folgenden Arten von Apps sind von diesen Änderungen ausgenommen:
- Geräteeigentümer-Apps
- Apps des Profilinhabers
- 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 deine App diese Berechtigung bei der Ausrichtung auf Android 13 oder höher nicht deklariert, 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 müssen Sie die Berechtigung nicht in der Manfiest-Datei Ihrer App deklarieren.
Weitere Informationen finden Sie 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. Sie können derzeit zwar einige Nicht-SDK-Schnittstellen verwenden (abhängig von der Ziel-API-Ebene Ihrer App), aber die Verwendung von Nicht-SDK-Methoden oder -Feldern birgt immer ein hohes Risiko für Probleme mit Ihrer App.
Wenn Sie sich nicht sicher sind, ob Ihre Anwendung Nicht-SDK-Schnittstellen verwendet, können Sie die Anwendung testen. Wenn Ihre App Nicht-SDK-Schnittstellen verwendet, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Trotzdem können einige Apps für die Verwendung von Nicht-SDK-Schnittstellen infrage kommen. Wenn Sie für eine Funktion 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 Aktualisierungen der Einschränkungen für Nicht-SDK-Schnittstellen in Android 13. Weitere Informationen zu Nicht-SDK-Schnittstellen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen.