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

Wie in früheren Releases umfasst auch Android 15 Verhaltensänderungen, die sich auf deine App auswirken können. Die folgenden Änderungen gelten ausschließlich für Apps, die auf Android 15 oder höher ausgerichtet sind. Wenn deine App auf Android 15 oder höher ausgerichtet ist, solltest du sie gegebenenfalls so anpassen, dass diese Verhaltensweisen ordnungsgemäß unterstützt werden.

Sehen Sie sich auch die Liste der Änderungen des Verhaltens an, die unabhängig vom targetSdkVersion Ihrer App Auswirkungen auf alle Apps unter Android 15 haben.

Hauptfunktion

Mit Android 15 werden verschiedene Kernfunktionen des Android-Systems modifiziert oder erweitert.

Änderungen an Diensten im Vordergrund

Mit Android 15 nehmen wir die folgenden Änderungen an Diensten im Vordergrund vor.

• Neuer Typ des Diensts für die Medienverarbeitung im Vordergrund
• Einschränkungen für BOOT_COMPLETED Broadcast-Empfänger, die Dienste im Vordergrund starten

Zeitlimit für die Datensynchronisierung im Vordergrund

Mit Android 15 wird für Apps, die auf Android 15 oder höher ausgerichtet sind, ein neues Verhalten bei Zeitüberschreitungen in dataSync eingeführt. Dieses Verhalten gilt auch für den neuen Diensttyp mediaProcessing im Vordergrund.

Das System lässt die dataSync-Dienste einer App für insgesamt 6 Stunden in einem 24-Stunden-Zeitraum zu. Anschließend ruft das System die in Android 15 eingeführte Methode Service.onTimeout(int, int) des laufenden Dienstes auf. Derzeit hat der Dienst einige Sekunden Zeit, Service.stopSelf() aufzurufen. Wenn Service.onTimeout() aufgerufen wird, gilt der Dienst nicht mehr als Dienst im Vordergrund. Wenn der Dienst Service.stopSelf() nicht aufruft, tritt ein Fehler mit der folgenden Fehlermeldung auf: „Ein Vordergrunddienst mit <fgs_type> wurde nicht innerhalb seines Zeitlimits beendet: <Komponentenname>). In Beta 2 wird die Fehlermeldung als ANR-Fehler angezeigt. In einem zukünftigen Betarelease löst diese Fehlermeldung eine benutzerdefinierte Ausnahme aus.

Führen Sie einen oder mehrere der folgenden Schritte aus, um Probleme mit dieser Verhaltensänderung zu vermeiden:

1. Bitten Sie Ihren Dienst, die neue Methode Service.onTimeout(int, int) zu implementieren. Wenn deine App den Callback empfängt, musst du stopSelf() innerhalb weniger Sekunden aufrufen. Wenn Sie die Anwendung nicht sofort beenden, löst das System einen Fehler aus.
2. Die dataSync-Dienste deiner Anwendung dürfen in einem Zeitraum von 24 Stunden maximal 6 Stunden ausgeführt werden (es sei denn, der Nutzer interagiert mit der App und setzt den Timer zurück).
3. Starten Sie dataSync-Dienste im Vordergrund nur als Ergebnis einer direkten Nutzerinteraktion. Da sich Ihre Anwendung beim Start des Dienstes im Vordergrund befindet, verbleiben volle sechs Stunden, nachdem die Anwendung in den Hintergrund versetzt wurde.
4. Verwenden Sie anstelle eines dataSync-Dienstes im Vordergrund eine alternative API.

Wenn die dataSync-Dienste im Vordergrund Ihrer App in den letzten 24 Stunden 6 Stunden ausgeführt wurden, können Sie keinen weiteren dataSync-Dienst im Vordergrund starten, es sei denn, der Nutzer hat Ihre App in den Vordergrund gebracht. Dadurch wird der Timer zurückgesetzt. Wenn Sie versuchen, einen anderen dataSync-Dienst im Vordergrund zu starten, gibt das System ForegroundServiceStartNotAllowedException mit einer Fehlermeldung wie „Zeitlimit für Diensttyp „dataSync“ im Vordergrund bereits erschöpft“ aus.

Neuer Typ des Diensts für die Medienverarbeitung im Vordergrund

Mit Android 15 wird der neue Diensttyp mediaProcessing im Vordergrund eingeführt. Dieser Diensttyp eignet sich für Vorgänge wie das Transcodieren von Mediendateien. Eine Medien-App lädt beispielsweise eine Audiodatei herunter und muss sie vor der Wiedergabe in ein anderes Format konvertieren. Mit einem mediaProcessing-Dienst im Vordergrund können Sie dafür sorgen, dass die Konvertierung auch dann fortgesetzt wird, wenn die App im Hintergrund ausgeführt wird.

Das System lässt die mediaProcessing-Dienste einer App für insgesamt 6 Stunden in einem 24-Stunden-Zeitraum zu. Danach ruft das System die in Android 15 eingeführte Methode Service.onTimeout(int, int) des laufenden Dienstes auf. Derzeit hat der Dienst einige Sekunden Zeit, Service.stopSelf() aufzurufen. Wenn der Dienst Service.stopSelf() nicht aufruft, tritt ein Fehler mit der folgenden Fehlermeldung auf: „Ein Vordergrunddienst mit <fgs_type> wurde nicht innerhalb seines Zeitlimits beendet: <Komponentenname>). In Beta 2 wird die Fehlermeldung als ANR-Fehler angezeigt. In einem zukünftigen Betarelease löst diese Fehlermeldung eine benutzerdefinierte Ausnahme aus.

So kannst du ANR-Fehler vermeiden:

1. Bitten Sie Ihren Dienst, die neue Methode Service.onTimeout(int, int) zu implementieren. Wenn deine App den Callback empfängt, musst du stopSelf() innerhalb weniger Sekunden aufrufen. Wenn Sie die Anwendung nicht sofort beenden, löst das System einen Fehler aus.
2. Die mediaProcessing-Dienste deiner Anwendung dürfen in einem Zeitraum von 24 Stunden maximal 6 Stunden ausgeführt werden (es sei denn, der Nutzer interagiert mit der App und setzt den Timer zurück).
3. Starten Sie mediaProcessing-Dienste im Vordergrund nur als Ergebnis einer direkten Nutzerinteraktion. Da sich Ihre Anwendung beim Start des Dienstes im Vordergrund befindet, verbleiben volle sechs Stunden, nachdem die Anwendung in den Hintergrund versetzt wurde.
4. Verwende anstelle eines mediaProcessing-Dienstes im Vordergrund eine alternative API wie WorkManager.

Wenn die mediaProcessing-Dienste im Vordergrund Ihrer App in den letzten 24 Stunden 6 Stunden ausgeführt wurden, können Sie keinen weiteren mediaProcessing-Dienst im Vordergrund starten, es sei denn, der Nutzer hat Ihre App in den Vordergrund gebracht. Dadurch wird der Timer zurückgesetzt. Wenn Sie versuchen, einen anderen mediaProcessing-Dienst im Vordergrund zu starten, gibt das System ForegroundServiceStartNotAllowedException mit einer Fehlermeldung wie „Zeitlimit für Diensttyp „mediaProcessing“ im Vordergrund bereits erschöpft“ aus.

Weitere Informationen zum Diensttyp mediaProcessing findest du unter Änderungen an den Diensttypen im Vordergrund für Android 15: Medienverarbeitung.

Einschränkungen für BOOT_COMPLETED Sender, die Dienste im Vordergrund starten

Es gibt neue Einschränkungen für BOOT_COMPLETED-Sender, die Dienste im Vordergrund starten. BOOT_COMPLETED-Empfänger dürfen die folgenden Arten von Diensten im Vordergrund nicht starten:

• dataSync
• camera
• mediaPlayback
• phoneCall
• mediaProjection
• microphone (diese Einschränkung gilt für microphone seit Android 14)

Wenn ein BOOT_COMPLETED-Empfänger versucht, einen dieser Arten von Diensten im Vordergrund zu starten, gibt das System ForegroundServiceStartNotAllowedException aus.

Einschränkungen beim Starten von Diensten im Vordergrund, während eine App die Berechtigung „SYSTEM_ALERT_WINDOW“ hat

Wenn eine App bisher die Berechtigung SYSTEM_ALERT_WINDOW hatte, konnte sie auch dann einen Dienst im Vordergrund starten, wenn die App sich derzeit im Hintergrund befand (siehe Ausnahmen von Einschränkungen beim Starten im Hintergrund).

Wenn eine App auf Android 15 ausgerichtet ist, wird diese Ausnahme jetzt enger gefasst. Die App benötigt jetzt die Berechtigung SYSTEM_ALERT_WINDOW und außerdem ein sichtbares Overlay-Fenster. Das heißt, die App muss zuerst ein TYPE_APPLICATION_OVERLAY-Fenster starten und das Fenster muss sichtbar sein, bevor Sie einen Dienst im Vordergrund starten.

Wenn Ihre App versucht, einen Dienst im Vordergrund aus dem Hintergrund zu starten, ohne diese neuen Anforderungen zu erfüllen (und es keine andere Ausnahme gibt), löst das System ForegroundServiceStartNotAllowedException aus.

Wenn Ihre App die Berechtigung SYSTEM_ALERT_WINDOW deklariert und Dienste im Vordergrund aus dem Hintergrund startet, ist sie möglicherweise von dieser Änderung betroffen. Wenn Ihre App ein ForegroundServiceStartNotAllowedException erhält, prüfen Sie die Reihenfolge der Vorgänge in der App und achten Sie darauf, dass die App bereits ein aktives Overlay-Fenster hat, bevor versucht wird, einen Dienst im Vordergrund aus dem Hintergrund zu starten. Sie können prüfen, ob das Overlay-Fenster derzeit sichtbar ist, indem Sie View.getWindowVisibility() aufrufen. Sie können auch View.onWindowVisibilityChanged() überschreiben, um benachrichtigt zu werden, wenn sich die Sichtbarkeit ändert.

Änderungen daran, wann Apps den globalen Status des „Bitte nicht stören“-Modus ändern können

Apps, die auf Android 15 ausgerichtet sind, können den globalen Status oder die Richtlinie für „Bitte nicht stören“ auf einem Gerät nicht mehr ändern (entweder durch Ändern der Nutzereinstellungen oder durch Deaktivieren des Modus „Nicht stören“). Stattdessen müssen Apps ein AutomaticZenRule-Element bereitstellen, das vom System zu einer globalen Richtlinie mit dem bestehenden „most-restrictive-policy-wins“-Schema kombiniert wird. Aufrufe an vorhandene APIs, die sich zuvor auf den globalen Status (setInterruptionFilter, setNotificationPolicy) ausgewirkt haben, führen zur Erstellung oder Aktualisierung einer impliziten AutomaticZenRule, die je nach Aufrufzyklus dieser API-Aufrufe ein- und ausgeschaltet wird.

Diese Änderung wirkt sich nur dann auf das beobachtbare Verhalten aus, wenn die App setInterruptionFilter(INTERRUPTION_FILTER_ALL) aufruft und erwartet, dass durch diesen Aufruf ein AutomaticZenRule deaktiviert wird, das zuvor von ihren Inhabern aktiviert wurde.

Änderungen in OpenJDK 17

Unter Android 15 werden die Kernbibliotheken von Android fortlaufend aktualisiert, damit sie den Funktionen der neuesten OpenJDK-LTS-Releases entsprechen.

Eine der folgenden Änderungen kann sich auf die Kompatibilität von Apps für Android 15 auswirken:

• Änderungen an den APIs für die Stringformatierung: Die Validierung von Argumentindex, Flags, Breite und Genauigkeit ist jetzt strenger, wenn die folgenden String.format()- und Formatter.format()-APIs verwendet werden:

  • String.format(String, Object[])
  • String.format(Locale, String, Object[])
  • Formatter.format(String, Object[])
  • Formatter.format(Locale, String, Object[])

  Die folgende Ausnahme wird beispielsweise ausgelöst, wenn der Argumentindex 0 verwendet wird (%0 im Formatstring):

  IllegalFormatArgumentIndexException: Illegal format argument index = 0
  

  In diesem Fall kann das Problem mit dem Argumentindex 1 (%1 im Formatstring) behoben werden.

• Änderungen am Komponententyp von Arrays.asList(...).toArray(): Wenn Sie Arrays.asList(...).toArray() verwenden, ist der Komponententyp des resultierenden Arrays jetzt ein Object und nicht der Typ der zugrunde liegenden Array-Elemente. Daher wird mit dem folgenden Code ein ClassCastException ausgelöst:

  String[] elements = (String[]) Arrays.asList("one", "two").toArray();
  

  Um in diesem Fall String als Komponententyp im resultierenden Array beizubehalten, können Sie stattdessen Collection.toArray(Object[]) verwenden:

  String[] elements = Arrays.asList("two", "one").toArray(new String[0]);
  

• Änderungen bei der Sprachcodeverarbeitung: Bei Verwendung der Locale API werden Sprachcodes für Hebräisch, Jiddisch und Indonesisch nicht mehr in ihre veraltete Form konvertiert (Hebräisch: iw, Jiddisch: ji und Indonesisch: in). Wenn Sie den Sprachcode für eine dieser Sprachen angeben, verwenden Sie stattdessen die Codes aus ISO 639-1 (Hebräisch: he, Y, Heidisch: he, Y, Heidisch: he, Y.yiid

• Änderungen an zufälligen Ganzzahlen: Gemäß den Änderungen in https://bugs.openjdk.org/browse/JDK-8301574 geben die folgenden Random.ints()-Methoden jetzt eine andere Zahlenfolge zurück als die Random.nextInt()-Methoden:

  • Random.ints(long)
  • Random.ints(long, int, int)
  • Random.ints(int, int)
  • Random.ints()

  Im Allgemeinen sollte diese Änderung nicht zu Appfehlern führen. Im Code sollte aber nicht erwartet werden, dass die von Random.ints()-Methoden generierte Sequenz mit Random.nextInt() übereinstimmt.

Sicherheit

Android 15 umfasst Änderungen, die die Systemsicherheit fördern, um Anwendungen und Nutzer vor schädlichen Apps zu schützen.

Einführung sicherer Hintergrundaktivitäten

Android 15 schützt Nutzer vor schädlichen Apps und gibt ihnen mehr Kontrolle über ihre Geräte. Dazu werden Änderungen hinzugefügt, durch die verhindert wird, dass schädliche Hintergrund-Apps andere Apps in den Vordergrund stellen, ihre Berechtigungen erhöhen und Nutzerinteraktionen missbrauchen. Die Einführung von Hintergrundaktivitäten ist seit Android 10 (API-Level 29) eingeschränkt.

Apps, die nicht mit der obersten UID auf dem Stack übereinstimmen, dürfen keine Aktivitäten starten

Schädliche Apps können die Aktivitäten einer anderen App innerhalb derselben Aufgabe starten und sich dann überlagern, sodass der Eindruck entsteht, diese App zu sein. Bei diesem „Task-Hijacking“-Angriff werden die aktuellen Einschränkungen beim Start im Hintergrund umgangen, da alles innerhalb derselben sichtbaren Aufgabe stattfindet. Um dieses Risiko zu verringern, fügt Android 15 ein Flag hinzu, das Apps, die nicht mit der obersten UID im Stack übereinstimmen, daran hindert, Aktivitäten zu starten. Aktualisieren Sie das Attribut allowCrossUidActivitySwitchFromBelow in der Datei AndroidManifest.xml Ihrer App, um sich für alle Aktivitäten Ihrer App anzumelden:

<application android:allowCrossUidActivitySwitchFromBelow="false" >

Die neuen Sicherheitsmaßnahmen sind aktiv, wenn alle der folgenden Bedingungen erfüllt sind:

• Die App, die den Start durchführt, ist auf Android 15 ausgerichtet.
• Die App über dem Aufgaben-Stack ist auf Android 15 ausgerichtet.
• Die neuen Schutzmaßnahmen wurden für alle sichtbaren Aktivitäten aktiviert

Wenn die Sicherheitsmaßnahmen aktiviert sind, kehren Anwendungen möglicherweise statt der letzten sichtbaren Anwendung zur Startseite zurück, wenn sie ihre eigene Aufgabe beenden.

Sonstige Änderungen

Zusätzlich zur Einschränkung für den UID-Abgleich gibt es die folgenden Änderungen:

• Ändern Sie die PendingIntent-Creator so, dass die Einführung von Hintergrundaktivitäten standardmäßig blockiert wird. Dadurch wird verhindert, dass Apps versehentlich ein PendingIntent erstellen, das von böswilligen Akteuren missbraucht werden könnte.
• Bringen Sie eine App nur dann in den Vordergrund, wenn der PendingIntent-Absender dies zulässt. Mit dieser Änderung soll verhindert werden, dass schädliche Apps die Möglichkeit missbrauchen, im Hintergrund Aktivitäten zu starten. Standardmäßig dürfen Apps den Aufgaben-Stack nicht in den Vordergrund bringen, es sei denn, der Ersteller hat Berechtigungen zum Starten von Hintergrundaktivitäten oder der Absender hat Berechtigungen zum Starten von Hintergrundaktivitäten.
• Steuern, wie die Top-Aktivität eines Aufgabenstapels ihre Aufgabe beenden kann. Wenn die Top-Aktivität eine Aufgabe beendet, kehrt Android zur letzten aktiven Aufgabe zurück. Wenn die Aufgabe einer Aktivität, die nicht zu den Top-Aktivitäten führt, abgeschlossen wird, kehrt Android zum Startbildschirm zurück. Das Ende dieser Aktivität wird nicht blockiert.
• Verhindern Sie das Starten beliebiger Aktivitäten aus anderen Anwendungen in Ihrer eigenen Aufgabe. Durch diese Änderung wird verhindert, dass schädliche Anwendungen Aktivitäten erstellen, die scheinbar von anderen Apps stammen.
• Verhindern, dass nicht sichtbare Fenster bei Hintergrundaktivitäten berücksichtigt werden. Dadurch wird verhindert, dass schädliche Apps Hintergrundaktivitäten missbrauchen, um Nutzern unerwünschte oder schädliche Inhalte anzuzeigen.

Sicherere Intents

Mit Android 15 werden neue Sicherheitsmaßnahmen eingeführt, um Intents sicherer und robuster zu machen. Diese Änderungen sollen potenzielle Sicherheitslücken und den Missbrauch von Intents verhindern, die von schädlichen Anwendungen ausgenutzt werden können. Es gibt zwei wesentliche Verbesserungen für die Sicherheit von Intents in Android 15:

• An Ziel-Intent-Filter anpassen:Intents, die auf bestimmte Komponenten abzielen, müssen genau mit den Intent-Filterspezifikationen des Ziels übereinstimmen. Wenn Sie einen Intent senden, um die Aktivität einer anderen App zu starten, muss die Ziel-Intent-Komponente den deklarierten Intent-Filtern der empfangenden Aktivität entsprechen.
• Intents müssen Aktionen haben:Intents ohne Aktion stimmen nicht mehr mit Intent-Filtern überein. Das bedeutet, dass Intents, die zum Starten von Aktivitäten oder Diensten verwendet werden, eine klar definierte Aktion haben müssen.

fun onCreate() {
    StrictMode.setVmPolicy(VmPolicy.Builder()
        .detectUnsafeIntentLaunch()
        .build()
    )
}

public void onCreate() {
    StrictMode.setVmPolicy(new VmPolicy.Builder()
            .detectUnsafeIntentLaunch()
            .build());
}

Nutzererfahrung und System-UI

Android 15 umfasst einige Änderungen, die für eine einheitlichere und intuitivere Nutzererfahrung sorgen sollen.

Änderungen des Fenstereinsatzes

In Android 15 gibt es zwei Änderungen im Zusammenhang mit Fenstereinsätzen: Edge-to-Edge-Änderungen werden standardmäßig erzwungen. Außerdem gibt es Konfigurationsänderungen, z. B. die Standardkonfiguration von Systemleisten.

Edge-to-Edge-Erzwingung

Apps sind auf Geräten mit Android 15 standardmäßig Edge-to-Edge-Geräten, wenn sie auf Android 15 ausgerichtet sind.

Dies ist eine funktionsgefährdende Änderung, die sich negativ auf die Benutzeroberfläche Ihrer App auswirken kann. Die Änderungen betreffen die folgenden UI-Bereiche:

• Navigationsleiste mit Gesten-Ziehpunkt
  • Standardmäßig transparent.
  • Der untere Offset ist deaktiviert, sodass der Inhalt hinter die Systemnavigationsleiste gezogen wird, sofern keine Einsätze angewendet werden.
  • setNavigationBarColor und R.attr#navigationBarColor wurden verworfen und wirken sich nicht auf die Bedienung über Gesten aus.
  • setNavigationBarContrastEnforced und R.attr#navigationBarContrastEnforced haben weiterhin keinen Einfluss auf die Bedienung über Gesten.
• Bedienung über 3 Schaltflächen
  • Die Deckkraft ist standardmäßig auf 80% festgelegt, wobei die Farbe möglicherweise dem Fensterhintergrund entspricht.
  • Unterer Offset ist deaktiviert, sodass der Inhalt hinter die Navigationsleiste des Systems zieht, wenn keine Einsätze angewendet werden.
  • setNavigationBarColor und R.attr#navigationBarColor sind standardmäßig so eingestellt, dass sie dem Fensterhintergrund entsprechen. Der Fensterhintergrund muss ein Farb-Drawable sein, damit diese Standardeinstellung angewendet wird. Diese API wurde eingestellt, hat aber weiterhin Auswirkungen auf die Bedienung über 3 Schaltflächen.
  • setNavigationBarContrastEnforced und R.attr#navigationBarContrastEnforced sind standardmäßig auf „true“ gesetzt, wodurch bei der Bedienung über 3 Schaltflächen ein undurchsichtiger Hintergrund von 80% hinzugefügt wird.
• Statusleiste
  • Standardmäßig transparent.
  • Der obere Offset ist deaktiviert, sodass der Inhalt hinter der Statusleiste angezeigt wird, sofern keine Einsätze angewendet werden.
  • setStatusBarColor und R.attr#statusBarColor wurden verworfen und haben keine Auswirkungen auf Android 15.
  • setStatusBarContrastEnforced und R.attr#statusBarContrastEnforced wurden eingestellt, haben aber weiterhin Auswirkungen unter Android 15.
• Display-Aussparung
  • layoutInDisplayCutoutMode der nicht unverankerten Fenster muss LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS sein. SHORT_EDGES, NEVER und DEFAULT werden als ALWAYS interpretiert, damit Nutzer keinen schwarzen Balken sehen, der durch die Display-Aussparung verursacht wurde, und nicht randvoll erscheinen.

Das folgende Beispiel zeigt eine App vor und nach dem Targeting auf Android 15 sowie vor und nach dem Anwenden von Einsätzen.

Prüfen, ob Ihre App bereits randlos ist

Wenn Ihre Anwendung bereits Edge-to-Edge-fähig ist und Einsätze anwendet, sind Sie weitgehend nicht betroffen, mit Ausnahme der folgenden Szenarien. Auch wenn Sie glauben, dass Sie nicht betroffen sind, empfehlen wir Ihnen, Ihre App zu testen.

• Sie haben ein nicht schwebendes Fenster, z. B. ein Activity, das SHORT_EDGES, NEVER oder DEFAULT anstelle von LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS verwendet. Wenn Ihre App beim Start abstürzt, kann das an Ihrem Ladebildschirm liegen. Sie können die Abhängigkeit für den Begrüßungsbildschirm auf 1.2.0-alpha01 oder höher upgraden oder window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always festlegen.
• Möglicherweise sind Displays mit geringerem Traffic mit verdeckter Benutzeroberfläche zu sehen. Diese Bildschirme, die seltener aufgerufen werden, dürfen keine verdeckte Benutzeroberfläche haben. Zu den Bildschirmen mit geringerem Traffic gehören:
  • Onboarding- oder Anmeldebildschirme
  • Einstellungsseiten

Prüfen, ob Ihre App nicht bereits randvoll ist

Wenn Ihre App noch nicht auf dem neuesten Stand ist, sind Sie höchstwahrscheinlich betroffen. Zusätzlich zu den Szenarien für bereits Edge-to-Edge-Anwendungen sollten Sie Folgendes in Betracht ziehen:

• Wenn in Ihrer Anwendung Material 3-Komponenten (androidx.compose.material3) beim Schreiben verwendet werden, z. B. TopAppBar, BottomAppBar und NavigationBar, sind diese Komponenten wahrscheinlich nicht betroffen, da sie Einsätze automatisch verarbeiten.
• Wenn Ihre Anwendung Material 2-Komponenten (androidx.compose.material) in Compose verwendet, verarbeiten diese Komponenten nicht automatisch Einsätze. Sie können jedoch Zugriff auf die Einsätze erhalten und sie manuell anwenden. Verwenden Sie in androidx.compose.material 1.6.0 und höher den Parameter windowInsets, um die Einsätze manuell auf BottomAppBar, TopAppBar, BottomNavigation und NavigationRail anzuwenden. Verwenden Sie ebenso den Parameter contentWindowInsets für Scaffold.
• Wenn Ihre Anwendung Ansichten und Materialkomponenten (com.google.android.material) verwendet, verarbeiten die meisten ansichtsbasierten Materialkomponenten wie BottomNavigationView, BottomAppBar, NavigationRailView oder NavigationView Einsätze und erfordern keine zusätzliche Arbeit. Sie müssen jedoch android:fitsSystemWindows="true" hinzufügen, wenn Sie AppBarLayout verwenden.
• Wenden Sie bei benutzerdefinierten zusammensetzbaren Funktionen die Einfügungen manuell als Abstand an. Wenn sich Ihr Inhalt in einer Scaffold befindet, können Sie Einsätze mithilfe der Scaffold-Padding-Werte verarbeiten. Andernfalls wenden Sie das Padding mit einer der WindowInsets an.
• Wenn Ihre Anwendung Ansichten und BottomSheet, SideSheet oder benutzerdefinierte Container verwendet, wenden Sie mit ViewCompat.setOnApplyWindowInsetsListener das Padding an. Wenden Sie für RecyclerView mit diesem Listener das Padding an und fügen Sie außerdem clipToPadding="false" hinzu.

Prüfen, ob deine App benutzerdefinierten Hintergrundschutz anbieten muss

Wenn Ihre App einen benutzerdefinierten Hintergrundschutz für die Bedienung über 3 Schaltflächen oder die Statusleiste anbieten muss, sollten Sie mit WindowInsets.Type#tappableElement() eine zusammensetzbare Funktion oder Ansicht hinter der Systemleiste platzieren, um die Höhe der Navigationsleiste mit 3 Schaltflächen oder WindowInsets.Type#statusBars zu erhalten.

Zusätzliche Edge-to-Edge-Ressourcen

Weitere Informationen zum Anwenden von Einsätzen finden Sie in den Leitfäden Edge-to-Edge-Ansichten und Edge-to-Edge-Compose.

Eingestellte APIs

Die folgenden APIs wurden eingestellt:

• R.attr#enforceStatusBarContrast
• R.attr#navigationBarColor
• R.attr#navigationBarDividerColor
• R.attr#statusBarColor
• Window#getNavigationBarColor
• Window#getNavigationBarDividerColor
• Window#getStatusBarColor
• Window#isStatusBarContrastEnforced
• Window#setDecorFitsSystemWindows
• Window#setNavigationBarColor
• Window#setNavigationBarDividerColor
• Window#setStatusBarColor
• Window#setStatusBarContrastEnforced

Stabile Konfiguration

Wenn Ihre App auf Android 15 oder höher ausgerichtet ist, schließt Configuration die Systemleisten nicht mehr aus. Wenn Sie die Bildschirmgröße in der Klasse Configuration für die Layoutberechnung verwenden, sollten Sie sie je nach Ihren Anforderungen durch bessere Alternativen wie eine geeignete ViewGroup, WindowInsets oder WindowMetricsCalculator ersetzen.

Configuration ist seit API 1 verfügbar. Sie wird normalerweise aus Activity.onConfigurationChanged abgerufen. Sie liefert Informationen wie Fensterdichte, Ausrichtung und Größe. Ein wichtiges Merkmal der von Configuration zurückgegebenen Fenstergrößen ist, dass die Systemleisten zuvor ausgeschlossen wurden.

Die Konfigurationsgröße wird in der Regel für die Ressourcenauswahl verwendet, z. B. /res/layout-h500dp, und dies ist immer noch ein gültiger Anwendungsfall. Wir raten jedoch immer davon ab, sie für Layoutberechnungen zu verwenden. In diesem Fall sollten Sie sich jetzt davon entfernen. Sie sollten die Verwendung von Configuration je nach Anwendungsfall durch einen geeigneteren Wert ersetzen.

Wenn Sie ihn zur Berechnung des Layouts nutzen, verwenden Sie ein geeignetes ViewGroup-Element, z. B. CoordinatorLayout oder ConstraintLayout. Wenn Sie damit die Höhe der Systemnavigationsleiste ermitteln möchten, verwenden Sie WindowInsets. Wenn Sie die aktuelle Größe Ihres App-Fensters wissen möchten, verwenden Sie computeCurrentWindowMetrics.

In der folgenden Liste werden die von dieser Änderung betroffenen Felder beschrieben:

• Bei den Größen Configuration.screenWidthDp und screenHeightDp werden die Systemleisten nicht mehr ausgeschlossen.
• Configuration.smallestScreenWidthDp ist indirekt von Änderungen an screenWidthDp und screenHeightDp betroffen.
• Configuration.orientation ist indirekt von Änderungen an screenWidthDp und screenHeightDp auf Close-to- Square-Geräten betroffen.
• Display.getSize(Point) ist indirekt von den Änderungen in Configuration betroffen. Seit API-Level 30 wurde dies eingestellt.
• Display.getMetrics() funktioniert schon seit API-Level 33 so.

Der Standardwert für das eleganteTextHeight-Attribut ist „true“.

Bei Apps, die auf Android 15 ausgerichtet sind, wird das elegantTextHeight-TextView-Attribut standardmäßig auf true gesetzt. Dabei wird die standardmäßig verwendete kompakte Schriftart durch einige Skripts mit großen vertikalen Messwerten durch eine Schriftart ersetzt, die viel besser lesbar ist. Die kompakte Schriftart wurde eingeführt, um fehlerhafte Layouts zu verhindern. Android 13 (API-Level 33) verhindert viele dieser Fehler, da das Textlayout mithilfe des Attributs fallbackLineSpacing die vertikale Höhe erweitert.

In Android 15 ist die kompakte Schriftart weiterhin im System vorhanden. Daher kann deine App elegantTextHeight auf false setzen, um dasselbe Verhalten wie zuvor zu erzielen, wird aber in zukünftigen Releases wahrscheinlich nicht unterstützt. Wenn deine App also die folgenden Skripts unterstützt: Arabisch, Laotisch, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Ordia, Telugu oder Thai, teste deine App, indem du elegantTextHeight auf true setzt.

Änderungen der TextView-Breite für komplexe Buchstabenformen

In früheren Android-Versionen kann es vorkommen, dass bei einigen kursiv geformten Schriftarten oder Sprachen mit komplizierter Form die Buchstaben im Bereich des vorherigen oder nächsten Zeichens eingezeichnet werden. In einigen Fällen wurden solche Buchstaben an der Anfangs- oder Endposition abgeschnitten. Ab Android 15 weist ein TextView die Breite zu, damit genügend Platz für solche Buchstaben ist, und ermöglicht es Apps, zusätzliche Abstände auf der linken Seite anzufordern, um zu verhindern, dass sie abgeschnitten werden.

Da sich diese Änderung darauf auswirkt, wie ein TextView die Breite bestimmt, weist TextView standardmäßig mehr Breite zu, wenn die App auf Android 15 oder höher ausgerichtet ist. Sie können dieses Verhalten aktivieren oder deaktivieren, indem Sie die setUseBoundsForWidth API für TextView aufrufen.

Da das Hinzufügen eines Abstands nach links zu einer Abstimmung bei vorhandenen Layouts führen kann, wird er auch in Apps, die auf Android 15 oder höher ausgerichtet sind, nicht standardmäßig hinzugefügt. Sie können jedoch setShiftDrawingOffsetForStartOverhang aufrufen, um ein Abschneiden zu verhindern, damit das Bild nicht abgeschnitten wird.

Die folgenden Beispiele zeigen, wie diese Änderungen das Textlayout für einige Schriftarten und Sprachen verbessern können.

Standardlayout für englischen Text in Kursivschrift. Einige Buchstaben sind abgeschnitten. Hier der entsprechende XML-Code:

<TextView
    android:fontFamily="cursive"
    android:text="java" />

Layout für denselben englischen Text mit zusätzlicher Breite und Abstand. Hier der entsprechende XML-Code:

<TextView
    android:fontFamily="cursive"
    android:text="java"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />

Standardlayout für thailändischen Text. Einige Buchstaben sind abgeschnitten. Hier der entsprechende XML-Code:

<TextView
    android:text="คอมพิวเตอร์" />

Layout für denselben thailändischen Text mit zusätzlicher Breite und größerem Abstand. Hier der entsprechende XML-Code:

<TextView
    android:text="คอมพิวเตอร์"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />

Sprachbasierte Standardzeilenhöhe für EditText

In früheren Android-Versionen wurde durch das Textlayout die Höhe des Texts so weit erweitert, dass sie der Zeilenhöhe der Schriftart entspricht, die der aktuellen Sprache entsprach. Wenn der Inhalt beispielsweise auf Japanisch war, da die Zeilenhöhe der japanischen Schriftart etwas größer als die einer lateinischen Schriftart ist, wurde die Höhe des Texts etwas größer. Trotz dieser unterschiedlichen Zeilenhöhen wurde die Größe des Elements EditText unabhängig von der verwendeten Sprache jedoch einheitlich, wie in der folgenden Abbildung dargestellt:

Für Apps, die auf Android 15 ausgerichtet sind, ist jetzt für EditText eine Mindestzeilenhöhe reserviert, die mit der Referenzschrift für das angegebene Gebietsschema übereinstimmt, wie in der folgenden Abbildung dargestellt:

Bei Bedarf können Sie das vorherige Verhalten Ihrer App wiederherstellen, indem Sie das Attribut useLocalePreferredLineHeightForMinimum auf false festlegen. Außerdem können in Ihrer App mithilfe der setMinimumFontMetrics API in Kotlin und Java benutzerdefinierte vertikale Mindestmesswerte festgelegt werden.

Kamera und Medien

Unter Android 15 werden die folgenden Änderungen am Kamera- und Medienverhalten für Apps vorgenommen, die auf Android 15 oder höher ausgerichtet sind.

Einschränkungen beim Anfordern des Audiofokus

Apps, die auf Android 15 ausgerichtet sind, müssen die Top-Apps sein oder einen audiobezogenen Dienst im Vordergrund ausführen, um den Audiofokus anzufordern. Wenn eine App versucht, den Fokus anzufordern, obwohl sie eine dieser Anforderungen nicht erfüllt, gibt der Aufruf AUDIOFOCUS_REQUEST_FAILED zurück.

Ein Dienst im Vordergrund gilt als audiobezogen, wenn sein Typ mediaPlayback, camera, microphone oder phoneCall ist.

Weitere Informationen zum Audiofokus finden Sie unter Audiofokus verwalten.

Nicht-SDK-Einschränkungen aktualisiert

Android 15 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 15 ausgerichtet ist, betreffen dich einige dieser Änderungen möglicherweise nicht sofort. Ihre App kann zwar je nach Ziel-API-Level Ihrer App auf einige Nicht-SDK-Schnittstellen zugreifen, 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 App Nicht-SDK-Schnittstellen verwendet, können Sie Ihre App testen. Wenn Ihre App Nicht-SDK-Schnittstellen verwendet, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Trotzdem sind wir uns bewusst, dass einige Anwendungen gültige Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen haben. Wenn Sie für ein Feature in Ihrer App keine Alternative zur Verwendung einer Benutzeroberfläche ohne SDK 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 15. Weitere Informationen zu Nicht-SDK-Schnittstellen im Allgemeinen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen.