Wie bei früheren Releases umfasst Android 13 Verhaltensänderungen, die sich auf eure Die folgenden Verhaltensänderungen gelten ausschließlich für Apps mit Ausrichtung auf Android 13 oder höher. Wenn deine App auf Android 13 oder höher ausgerichtet ist, solltest du Ihre App gegebenenfalls anpassen, um diese Verhaltensweisen zu unterstützen.
Sehen Sie sich auch die Liste der Verhaltensänderungen an, die alle Apps betreffen mit Android 13.
Datenschutz
Die Berechtigung zum Senden von Benachrichtigungen wirkt sich auf die Darstellung des Dienstes im Vordergrund aus
Wenn der Nutzer Berechtigung zum Senden von Benachrichtigungen werden keine Hinweise zu Diensten im Vordergrund angezeigt, Benachrichtigungsleiste Nutzer sehen jedoch weiterhin Hinweise zu Diensten im Vordergrund in der Task-Manager unabhängig davon, ob die Berechtigung zum Senden von Benachrichtigungen erteilt wurde.
Neue Laufzeitberechtigung für WLAN-Geräte in der Nähe
Bei früheren Android-Versionen muss der Nutzer deiner App die
ACCESS_FINE_LOCATION
um einige gängige WLAN-Anwendungsfälle auszuführen.
Weil es für Nutzer schwierig ist, WLAN-Berechtigungen zur Standortermittlung zu verknüpfen
wird mit Android 13 (API-Level 33) eine Laufzeitberechtigung in der
NEARBY_DEVICES
Berechtigungsgruppe für Apps, die die Verbindungen eines Geräts mit dem Zugriff in der Nähe verwalten
WLAN-Zugriffspunkte. Diese 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 Aufgaben ausführen:
<ph type="x-smartling-placeholder">
- </ph>
- 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 Ihre App keine Informationen zum physischen Standort aus dem WLAN ableitet,
APIs, fordern Sie NEARBY_WIFI_DEVICES
statt ACCESS_FINE_LOCATION
an, wenn Sie
auf Android 13 oder höher ausrichten und Wi-Fi APIs verwenden. Wenn Sie
die Berechtigung NEARBY_WIFI_DEVICES
haben, versichern Sie, dass Ihre App nie
ermittelt Informationen zum physischen Standort von Wi-Fi APIs. Legen Sie dazu das Feld
Attribut android:usesPermissionFlags
zu neverForLocation
. Dieser Prozess ist
ähnlich wie in Android 12 (API-Level 31) und höher,
sicherstellen, dass Informationen zu Bluetooth-Geräten niemals
Standort.
Weitere Informationen zur Zugriff auf WLAN-Geräte in der Nähe anfordern
Detaillierte Medienberechtigungen
<ph type="x-smartling-placeholder">Wenn Ihre App auf Android 13 oder höher ausgerichtet ist und
auf Mediendateien zugreifen, die andere Apps haben
erstellt haben, müssen Sie
Fordern Sie eine oder mehrere der folgenden detaillierten Medienberechtigungen statt der
READ_EXTERNAL_STORAGE
Berechtigung:
Medientyp | Berechtigung zum Anfordern |
---|---|
Bilder und Fotos | READ_MEDIA_IMAGES |
Videos | READ_MEDIA_VIDEO |
Audiodateien | READ_MEDIA_AUDIO |
Bevor du auf die Mediendateien einer anderen App zugreifen kannst, musst du prüfen, ob der Nutzer folgende Berechtigungen erteilt hat: über die entsprechenden detaillierten Medienberechtigungen für Ihre App verfügen.
Abbildung 1 zeigt eine App, die die Berechtigung READ_MEDIA_AUDIO
anfordert.
Wenn Sie sowohl die Berechtigung READ_MEDIA_IMAGES
als auch die
READ_MEDIA_VIDEO
gleichzeitige Berechtigung, nur eine Systemberechtigung
wird angezeigt.
Wenn Ihrer App zuvor die Berechtigung
READ_EXTERNAL_STORAGE
werden die angeforderten READ_MEDIA_*
-Berechtigungen gewährt,
automatisch beim Upgrade. Mit dem folgenden ADB-Befehl können Sie
Aktualisierte Berechtigungen:
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 „während der Nutzung“ eingeführt Zugriff für Körpersensoren, z. B. die Herzfrequenz, die Temperatur und den Sauerstoffgehalt im Blut. Dieses dem Zugriffsmodell sehr ähnlich ist wie das, das im System für die Standortermittlung in Android 10 (API-Level 29).
Ihre App ist auf Android 13 ausgerichtet und benötigt Zugriff auf den Körpersensor
während die Ausführung im Hintergrund läuft, müssen Sie das neue
BODY_SENSORS_BACKGROUND
Berechtigung zusätzlich zur vorhandenen
BODY_SENSORS
Berechtigung.
Leistung und Akku
Akkuressourcennutzung
Wenn Nutzende Ihre App in der
„eingeschränkt“ Bundesland für
Akkunutzung im Hintergrund
Ihre App ist zwar auf Android 13 ausgerichtet, liefert aber nicht
BOOT_COMPLETED
-Übertragung oder LOCKED_BOOT_COMPLETED
-Übertragung, bis die
App wurde aus anderen Gründen gestartet.
Nutzererfahrung
Von PlaybackState
abgeleitete Mediensteuerelemente
Für Apps, die auf Android 13 (API-Level 33) und höher ausgerichtet sind, leitet das System
Mediensteuerung von
PlaybackState
Aktionen. Dieses
kann das System mehr Steuerelemente anzeigen, die technisch gesehen
auf Mobiltelefonen und Tablets einheitlich sind und sich an die Art und Weise
werden auch auf anderen Android-Plattformen wie Android Auto und
Android TV
Abbildung 2 zeigt ein Beispiel dafür, wie dies auf einem Smartphone und Tablet aussieht. .
<ph type="x-smartling-placeholder">Vor Android 13 zeigte das System bis zu fünf Aktionen aus der MediaStyle
in der Reihenfolge angezeigt, in der sie hinzugefügt wurden.
Im kompakten Modus, zum Beispiel in den minimierten Schnelleinstellungen, bis zu
drei Aktionen mit setShowActionsInCompactView()
angegeben
angezeigt wurden.
Ab Android 13 werden bis zu fünf Aktionsschaltflächen
zu PlaybackState
, wie in der folgenden Tabelle beschrieben. Im kompakten Modus sind nur die ersten drei
werden eingeblendet. Apps, die nicht auf Android 13 ausgerichtet sind, oder solche,
die kein PlaybackState
enthalten, zeigt das System Steuerelemente basierend auf
Die Liste Action
wurde der MediaStyle
-Benachrichtigung hinzugefügt, wie in den
vorherigen Absatz.
Stellen | Aktion | Kriterien |
---|---|---|
1 | Wiedergeben |
Der aktuelle Status des PlaybackState ist einer der folgenden:
<ph type="x-smartling-placeholder">
|
Rotierendes Ladesymbol |
Der aktuelle Status des PlaybackState ist einer der folgenden:
<ph type="x-smartling-placeholder">
|
|
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 zum
PlaybackState
App-Farbdesign wird automatisch auf WebView-Inhalte angewendet
Für Apps, die auf Android 13 (API-Level 33) oder höher ausgerichtet sind,
setForceDark()
-Methode nicht mehr unterstützt wird, was beim Aufruf der Methode zu einem Null-Vorgang führt.
Stattdessen legt WebView jetzt immer
die Medienabfrage prefers-color-scheme
gemäß dem Designattribut der App,
isLightTheme
In anderen
Wörter: Wenn isLightTheme
den Wert true
hat oder nicht angegeben ist, ist prefers-color-scheme
light
; andernfalls dark
. Dieses Verhalten bedeutet, dass der
wird der helle oder dunkle Stil automatisch an das App-Design angepasst, wenn
die Inhalte dies unterstützen.
Bei den meisten Apps sollten durch das neue Verhalten die passenden App-Stile angewendet werden. automatisch testen. Du solltest deine App jedoch testen, um zu prüfen, Einstellungen für den dunklen Modus manuell gesteuert haben.
Wenn Sie das Farbschema Ihrer App noch anpassen möchten, verwenden Sie die
setAlgorithmicDarkeningAllowed()
. Für die Abwärtskompatibilität mit früheren Android-Versionen
die äquivalente
setAlgorithmicDarkeningAllowed()
in AndroidX an.
In der Dokumentation zu dieser Methode erfahren Sie mehr über das Verhalten,
die Sie in Ihrer App erwarten. Dies hängt davon ab,
targetSdkVersion
und Design
Einstellungen.
Konnektivität
BluetoothAdapter#enable() und BluetoothAdapter#disable() eingestellt
Für Apps, die auf Android 13 (API-Level 33) oder höher ausgerichtet sind,
BluetoothAdapter#enable()
und
BluetoothAdapter#disable()
-Methoden wurden verworfen und gelten immer
geben 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
Apps, die Google Play-Dienste Werbung nutzen
ID und
muss auf Android 13 (API-Level 33) und höher
die normale Berechtigung AD_ID
in den
Manifestdatei so an:
<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 wird die Werbe-ID automatisch entfernt und durch einen String von Nullen.
Wenn deine App SDKs verwendet, die die Berechtigung AD_ID
in der Bibliothek
Manifestdatei wird die Berechtigung dann mit der Manifestdatei Ihrer App zusammengeführt.
Standardeinstellung. In diesem Fall musst du die Berechtigung nicht im
zu verwalten.
Weitere Informationen finden Sie unter Werbung ID in in der Play Console-Hilfe.
Nicht-SDK-Einschränkungen aktualisiert
Android 13 enthält aktualisierte Listen mit eingeschränktem Nicht-SDK Benutzeroberflächen basierend auf der Zusammenarbeit mit Android-Entwicklern internen Tests. Wann immer möglich, achten wir darauf, dass öffentliche Alternativen bevor wir Nicht-SDK-Schnittstellen einschränken.
Wenn deine App nicht auf Android 13 ausgerichtet ist, gibt es einige dieser Änderungen nicht sofort betreffen. Obwohl Sie derzeit einige Nicht-SDK-Schnittstellen (abhängig von der Ziel-API Ihrer App Level) die Verwendung einer Nicht-SDK-Methode oder eines Nicht-SDK-Felds birgt immer ein hohes Risiko, dass Ihre
Wenn Sie sich nicht sicher sind, ob Ihre App Nicht-SDK-Schnittstellen verwendet, können Sie Ihre App um es herauszufinden. Wenn Ihre App Nicht-SDK-Schnittstellen benötigt, sollten Sie mit der Planung eine Migration zu SDK-Alternativen. Dennoch ist uns bewusst, dass einige Apps Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen. Wenn Sie keine Alternative finden für eine Funktion in Ihrer App eine Nicht-SDK-Schnittstelle verwenden, sollten Sie eine neue öffentliche API.
Weitere Informationen zu den Änderungen in dieser Android-Version findest du unter Updates für Einschränkungen für Nicht-SDK-Schnittstellen in Android 13 Allgemeine Informationen zu Nicht-SDK-Schnittstellen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen Benutzeroberflächen.