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

Wie bei früheren Releases 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 ändern, dass sie diese Verhaltensweisen korrekt unterstützt.

Lesen Sie sich auch die Liste der Verhaltensänderungen durch, die sich auf alle Apps auswirken, die auf Android 13 ausgeführt werden.

Datenschutz

Benachrichtigungsberechtigung wirkt sich auf die Darstellung von Diensten im Vordergrund aus

Wenn der Nutzer die Berechtigung für Benachrichtigungen ablehnt, werden ihm im Benachrichtigungs-Pull-down-Menü 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 für Benachrichtigungen erteilt 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 gewähren, um mehrere gängige WLAN-Anwendungsfälle auszuführen.

Da es für Nutzer schwierig ist, Berechtigungen zur Standortermittlung mit WLAN-Funktionen zu verknüpfen, 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 WLAN-Zugangspunkten in der Nähe verwalten. Diese Berechtigung, NEARBY_WIFI_DEVICES, erfüllt WLAN-Nutzungsfä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 die Medienübertragung. Mit diesem Workflow kann Ihre App folgende Aufgaben ausführen:
  • Out-of-Band-Zugriff auf ZP-Informationen, z. B. über BLE
  • Geräte über Wi‑Fi Aware finden und eine Verbindung über einen lokal beschränkten Hotspot herstellen
  • Geräte über Wi‑Fi Direct finden und eine Verbindung herstellen
• Stellen Sie 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

Solange Ihre App keine physischen Standortinformationen aus den WLAN-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 WLAN-APIs verwenden. Wenn Sie die Berechtigung NEARBY_WIFI_DEVICES angeben, müssen Sie ausdrücklich erklären, dass Ihre App niemals Informationen zum physischen Standort aus WLAN-APIs ableitet. Legen Sie dazu das android:usesPermissionFlags-Attribut auf neverForLocation fest. Dieser Vorgang ähnelt dem, den Sie unter Android 12 (API-Level 31) und höher ausführen, wenn Sie angeben, dass Bluetooth-Geräteinformationen niemals für die Standortermittlung verwendet werden.

Weitere Informationen zum Anfordern der Berechtigung zum 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 erteilt hat.

Abbildung 1 zeigt eine App, die die Berechtigung READ_MEDIA_AUDIO anfordert.

Wenn Sie sowohl die Berechtigung READ_MEDIA_IMAGES als auch die Berechtigung READ_MEDIA_VIDEO gleichzeitig 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

Verwendung von Körpersensoren im Hintergrund erfordert neue Berechtigung

In Android 13 wird das Konzept des Zugriffs „bei Nutzung“ für Körpersensoren wie Herzfrequenz, Temperatur und Sauerstoffsättigung eingeführt. Dieses Zugriffsmodell ähnelt dem, das das System für die Standortermittlung unter Android 10 (API-Level 29) eingeführt hat.

Wenn Ihre App auf Android 13 ausgerichtet ist und Zugriff auf Informationen von Körpersensoren 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 Status eingeschränkt versetzt, während Ihre App 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 wird.

Nutzererfahrung

Mediensteuerelemente, die aus PlaybackState abgeleitet wurden

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

Abbildung 2 zeigt, wie das auf einem Smartphone und einem Tablet jeweils aussieht.

Vor Android 13 zeigte das System bis zu fünf Aktionen aus der MediaStyle-Benachrichtigung in der Reihenfolge an, 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 an, die auf der PlaybackState basieren, 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 an, die auf der Action-Liste basieren, die der MediaStyle-Benachrichtigung wie im vorherigen Abschnitt beschrieben hinzugefügt wurde.

Benutzerdefinierte Aktionen werden in der Reihenfolge platziert, in der sie der PlaybackState hinzugefügt wurden.

Das 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 sie aufgerufen wird, führt dies zu keiner Aktion.

Stattdessen legt WebView die Medienabfrage prefers-color-scheme jetzt immer gemäß dem Designattribut der App fest, also isLightTheme. 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 dies von den Inhalten unterstützt wird.

Bei den meisten Apps sollten die entsprechenden App-Styles durch das neue Verhalten automatisch angewendet werden. Sie sollten Ihre App jedoch testen, um Fälle zu finden, in denen Sie die Einstellungen für den dunklen Modus möglicherweise manuell gesteuert haben.

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

In der Dokumentation zu dieser Methode erfahren Sie mehr darüber, welches Verhalten in Ihrer App je nach targetSdkVersion- und Themeneinstellungen zu erwarten ist.

Konnektivität

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

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

Die folgenden App-Typen sind von diesen Änderungen ausgenommen:

• Apps vom 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) oder 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 in Ihrer App nicht deklariert ist und Ihre App 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, für die die Berechtigung AD_ID im Manifest der Bibliothek 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-basierter 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 jedoch einige Nicht-SDK-Schnittstellen verwenden (je nach 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 nicht sicher sind, ob Ihre App Nicht-SDK-Schnittstellen verwendet, können Sie Ihre App testen, um das herauszufinden. Wenn Ihre App Nicht-SDK-Schnittstellen verwendet, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Uns ist jedoch bewusst, 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-Benutzeroberfläche 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 Änderungen an den Einschränkungen für nicht SDK-spezifische Oberflächen in Android 13. Weitere Informationen zu Nicht-SDK-Schnittstellen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen.