Verhaltensänderungen: Apps, die auf Android 13 oder höher ausgerichtet sind

Wie frühere Versionen enthält auch 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 so anpassen, dass sie diese Verhaltensweisen gegebenenfalls 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 zum Senden von Benachrichtigungen wirkt sich auf die Darstellung von Diensten im Vordergrund aus

Wenn der Nutzer die Berechtigung zum Senden von Benachrichtigungen ablehnt, werden ihm im Benachrichtigungsbereich keine Benachrichtigungen zu Diensten im Vordergrund angezeigt. Nutzer sehen jedoch weiterhin Benachrichtigungen 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, damit sie mehrere gängige WLAN-Anwendungsfälle ausführen kann.

Da es für Nutzer schwierig ist, Berechtigungen zur Standortermittlung mit der WLAN-Funktion 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 nahegelegenen Zugriffspunkten ü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. Drucker oder Geräte für Medien-Streaming. Mit diesem Workflow kann Ihre App die folgenden Aufgaben ausführen:
  • AP-Informationen Out-of-Band empfangen, z. B. über BLE.
  • Geräte über Wi-Fi Aware finden und verbinden und eine Verbindung über einen lokalen Hotspot herstellen.
  • Geräte über Wi-Fi Direct finden und mit ihnen verbinden.
• Verbindung zu einer bekannten SSID herstellen, z. B. zu einem Auto oder Smart-Home-Gerät.
• Starten Sie einen lokalen Hotspot.
• Entfernung zu Wi-Fi Aware-Geräten in der Nähe

Solange Ihre App keine Informationen zum physischen Standort aus den WLAN-APIs ableitet, sollten Sie NEARBY_WIFI_DEVICES anstelle von ACCESS_FINE_LOCATION anfordern, wenn Sie Android 13 oder höher als Ziel verwenden und WLAN-APIs nutzen. Wenn du die Berechtigung NEARBY_WIFI_DEVICES deklarierst, musst du ausdrücklich bestätigen, dass deine App niemals Standortinformationen von WLAN-APIs ableitet. Legen Sie dazu das Attribut android:usesPermissionFlags auf neverForLocation fest. Dieser Vorgang ähnelt dem in Android 12 (API-Level 31) und höher, wenn Sie bestätigen, dass Bluetooth-Geräteinformationen nie für die Standortermittlung verwendet werden.

Weitere Informationen zum Anfordern der Berechtigung für den Zugriff auf WLAN-Geräte in der Nähe

Detaillierte Medienberechtigungen

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, 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 die Systemberechtigung angezeigt.

Wenn deiner 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 das Konzept des Zugriffs „während der Nutzung“ für Körpersensoren wie Herzfrequenz, Temperatur und Sauerstoffsättigung eingeführt. Dieses Zugriffsmodell ist dem sehr ähnlich, das das System für den Standort in Android 10 (API-Level 29) eingeführt hat.

Wenn deine App auf Android 13 ausgerichtet ist und Zugriff auf Körpersensordaten im Hintergrund benötigt, musst du zusätzlich zur bestehenden 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 Zustand versetzt, während Ihre App auf Android 13 ausgerichtet ist, stellt das System die Übertragung BOOT_COMPLETED oder LOCKED_BOOT_COMPLETED erst dann bereit, wenn die App aus anderen Gründen gestartet wird.

Nutzererfahrung

Aus PlaybackState abgeleitete Mediensteuerung

Bei Apps, die auf Android 13 (API-Level 33) und höher ausgerichtet sind, leitet das System die Mediensteuerung von PlaybackState-Aktionen ab. Dadurch kann das System eine größere Auswahl an Steuerelementen anzeigen, die auf Smartphones und Tablets technisch konsistent sind und auch der Darstellung von Mediensteuerungen auf anderen Android-Plattformen wie Android Auto und Android TV entsprechen.

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

Vor Android 13 wurden bis zu fünf Aktionen aus der MediaStyle-Benachrichtigung in der Reihenfolge angezeigt, in der sie hinzugefügt wurden. Im Kompaktmodus, 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 Kompaktmodus werden nur die ersten drei Aktionsslots angezeigt. Bei Apps, die nicht auf Android 13 ausgerichtet sind, oder bei Apps, die keinen PlaybackState enthalten, zeigt das System Steuerelemente basierend auf der Action-Liste an, 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.

Farbschema der App wird automatisch auf WebView-Inhalte angewendet

Bei Apps, die auf Android 13 (API-Level 33) oder höher ausgerichtet sind, wird die Methode setForceDark() nicht mehr unterstützt. Wenn die Methode aufgerufen wird, wird sie nicht ausgeführt.

Stattdessen legt WebView die Medienabfrage prefers-color-scheme jetzt immer gemäß dem Designattribut der App fest, isLightTheme. Mit anderen Worten: Wenn isLightTheme den Wert true hat oder nicht angegeben ist, ist prefers-color-scheme light, andernfalls dark. Das bedeutet, dass der helle oder dunkle Stil des Webinhalts automatisch an das Design der App angepasst wird, wenn der Inhalt dies unterstützt.

Bei den meisten Apps sollten die entsprechenden App-Stile automatisch angewendet werden. Sie sollten Ihre App jedoch auf Fälle prüfen, in denen Sie die Einstellungen für den dunklen Modus manuell festgelegt haben.

Wenn Sie das Verhalten des Farbschemas Ihrer App dennoch anpassen müssen, verwenden Sie stattdessen die Methode setAlgorithmicDarkeningAllowed(). Für die Abwärtskompatibilität mit früheren Android-Versionen empfehlen wir die Verwendung der entsprechenden setAlgorithmicDarkeningAllowed()-Methode in AndroidX.

In der Dokumentation zu dieser Methode finden Sie weitere Informationen dazu, welches Verhalten Sie in Ihrer App je nach targetSdkVersion und Designeinstellungen Ihrer App erwarten können.

Verbindung

BluetoothAdapter#enable() und BluetoothAdapter#disable() eingestellt

Bei Apps, die auf Android 13 (API-Level 33) oder höher ausgerichtet sind, sind die Methoden BluetoothAdapter#enable() und BluetoothAdapter#disable() veraltet und geben immer false zurück.

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

• Geräteeigentümer-Apps
• Profilinhaber-Apps
• 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 die normale Berechtigung AD_ID in der Manifestdatei der App 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 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 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 Manifestdatei Ihrer App deklarieren.

Weitere Informationen finden Sie in der Play Console-Hilfe unter Werbe-ID.

Aktualisierte Einschränkungen für Nicht-SDK-Schnittstellen

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 stellen nach Möglichkeit öffentliche Alternativen zur Verfügung, bevor wir Nicht-SDK-Schnittstellen einschränken.

Wenn deine App nicht auf Android 13 ausgerichtet ist, wirken sich einige dieser Änderungen möglicherweise nicht sofort auf dich aus. Derzeit können Sie zwar einige Nicht-SDK-Schnittstellen verwenden (abhängig vom Ziel-API-Level Ihrer App), die Verwendung von Nicht-SDK-Methoden oder ‑Feldern 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 dies herauszufinden. Wenn Ihre App auf Nicht-SDK-Schnittstellen basiert, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Wir wissen jedoch, dass es für einige Apps gültige Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen gibt. 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 Android-Version 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.