Änderungen beim Verhalten: Apps, die auf Android 13 oder höher ausgerichtet sind

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>

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:

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>

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.

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.