Verhaltensänderungen: alle Apps

Die Android 15-Plattform umfasst Verhaltensänderungen, die sich auf Ihre App auswirken können. Die folgenden Verhaltensänderungen gelten für alle Apps, die unter Android 15 ausgeführt werden, unabhängig von targetSdkVersion. Teste deine App und passe sie gegebenenfalls an, damit sie korrekt unterstützt werden.

Sieh dir auch die Liste der Verhaltensänderungen an, die nur Apps betreffen, die auf Android 15 ausgerichtet sind.

Hauptfunktion

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

Änderungen am Status „Paket gestoppt“

Die Absicht des Paketstatus FLAG_STOPPED, bei dem Nutzer AOSP-Builds durch langes Drücken eines App-Symbols und Auswählen von „Beenden erzwingen“ durchführen können, wurde schon immer in diesem Zustand belassen, bis der Nutzer die App explizit aus diesem Status entfernt, indem er sie startet oder indirekt mit der App interagiert (über das Sharesheet oder ein Widget, indem er die App als Live-Hintergrund auswählt usw.). In Android 15 aktualisieren wir das Verhalten des Systems, um es an dieses beabsichtigte Verhalten anzupassen. Apps sollten nur durch direkte oder indirekte Nutzeraktionen aus dem beendeten Zustand entfernt werden.

Zusätzlich zu den vorhandenen Einschränkungen bricht das System alle ausstehenden Intents ab, wenn die App auf einem Gerät mit Android 15 in den beendeten Status wechselt. Wenn die Aktion des Nutzers die App aus dem Status „Angehalten“ entfernt, wird die ACTION_BOOT_COMPLETED-Broadcast an die App gesendet. So haben Sie die Möglichkeit, ausstehende Intents noch einmal zu registrieren.

Mit der neuen Methode ApplicationStartInfo.wasForceStopped() können Sie prüfen, ob die App beendet wurde.

Unterstützung für Seitengrößen von 16 KB

In der Vergangenheit wurden bei Android nur Seiten mit einer Größe von 4 KB unterstützt. Dadurch wurde die Systemspeicherleistung für die durchschnittliche Gesamtarbeitsspeichergröße von Android-Geräten optimiert. Ab Android 15 werden Geräte mit einer Seitengröße von 16 KB (16 KB-Geräte) unterstützt.

Da Gerätehersteller auch weiterhin Geräte mit größerem physischem Arbeitsspeicher (RAM) entwickeln, werden viele dieser Geräte wahrscheinlich mit Seitengrößen von 16 KB (und schließlich auch mit größeren Seiten) konfiguriert, um die Geräteleistung zu optimieren. Wenn Sie die Unterstützung für 16-KB-Geräte hinzufügen, kann Ihre App auf diesen Geräten ausgeführt werden und Ihre App profitiert von den damit verbundenen Leistungsverbesserungen. Um Ihnen dabei zu helfen, haben wir Ihnen Anleitungen dazu zusammengestellt, wie Sie prüfen, ob Ihre App betroffen ist, wie Sie Ihre Anwendung neu erstellen (falls zutreffend) und wie Sie Ihre App in einer 16 KB-Umgebung mit Emulatoren und physischen Geräten testen.

Vorteile und Leistungssteigerungen

Geräte, die mit einer Seitengröße von 16 KB konfiguriert wurden, benötigen im Durchschnitt etwas mehr Arbeitsspeicher, erzielen aber auch verschiedene Leistungsverbesserungen für das System und die Anwendungen:

  • Kürzere App-Startzeiten bei Speicherauslastung – im Durchschnitt um 3,16 % niedriger, mit größeren Verbesserungen (bis zu 30%) für einige getestete Apps
  • Geringerer Stromverbrauch beim Start der App: durchschnittlich 4,56% weniger
  • Schnellerer Start der Kamera: 4,48% schnellere Heißstarts im Durchschnitt und 6,60% schnellere Kaltstarts im Durchschnitt
  • Verbesserte Systemstartzeit: durchschnittlich um 1,5% (ungefähr 0,8 Sekunden) verbessert

Diese Verbesserungen basieren auf unseren ersten Tests und die Ergebnisse auf tatsächlichen Geräten werden wahrscheinlich abweichen. Im Verlauf der Tests werden wir zusätzliche Analysen möglicher Vorteile für Apps bereitstellen.

Prüfen, ob Ihre App betroffen ist

Wenn Ihre App nativen Code verwendet, sollten Sie sie neu erstellen, sodass sie 16-KB-Geräte unterstützt. Wenn Sie sich nicht sicher sind, ob Ihre App nativen Code verwendet, können Sie mithilfe des APK Analyzer ermitteln, ob nativer Code vorhanden ist.

Wenn Ihre App nur Code verwendet, der in der Programmiersprache Java oder in Kotlin geschrieben ist (einschließlich aller Bibliotheken oder SDKs), unterstützt sie bereits 16-KB-Geräte. Trotzdem empfehlen wir Ihnen, Ihre Anwendung in einer 16 KB-Umgebung zu testen, um sicherzustellen, dass es keine unerwarteten Regressionen beim Verhalten der Anwendung gibt.

Erforderliche Änderungen für einige Apps zur Unterstützung des privaten Bereichs

Der Privatbereich ist eine neue Funktion in Android 15, mit der Nutzer einen separaten Bereich auf ihrem Gerät erstellen können, in dem sie vertrauliche Apps vor neugierigen Blicken schützen können – und zwar über eine zusätzliche Authentifizierungsebene. Da die Sichtbarkeit von Anwendungen im privaten Bereich eingeschränkt ist, müssen einige Arten von Anwendungen zusätzliche Schritte ausführen, um die Anwendungen im privaten Bereich eines Nutzers sehen und mit ihnen interagieren zu können.

Alle Apps

Da Anwendungen im privaten Bereich, ähnlich wie Arbeitsprofile, in einem separaten Nutzerprofil verwaltet werden, sollten Anwendungen nicht davon ausgehen, dass installierte Kopien ihrer Anwendung, die sich nicht im Hauptprofil befinden, im Arbeitsprofil enthalten sind. Wenn die Logik Ihrer Anwendung auf Apps mit Arbeitsprofilen basiert, die diese Annahme treffen, müssen Sie diese Logik anpassen.

Launcher-Apps

Wenn Sie eine Launcher-App entwickeln, müssen Sie Folgendes tun, damit Apps im privaten Bereich sichtbar sind:

  1. Deine App muss als Standard-Launcher-App für das Gerät zugewiesen sein, also die Rolle ROLE_HOME haben.
  2. Deine App muss die normale Berechtigung ACCESS_HIDDEN_PROFILES in der Manifestdatei deiner App deklarieren.

Launcher-Apps, die die Berechtigung ACCESS_HIDDEN_PROFILES deklarieren, müssen die folgenden Anwendungsfälle für den privaten Bereich bewältigen:

  1. Deine App muss einen separaten Launcher-Container für Apps haben, die im privaten Bereich installiert sind.
  2. Der Nutzer muss den Container für den privaten Bereich ein- und ausblenden können.
  3. Der Nutzer muss den Container für den privaten Bereich sperren und entsperren können.
  4. Wenn die Option gesperrt ist, sollten keine Anwendungen im Container für den privaten Bereich über Mechanismen wie die Suche sichtbar oder auffindbar sein.

App-Shop-Apps

Der private Bereich enthält die Schaltfläche „Apps installieren“, die einen impliziten Intent zum Installieren von Apps im privaten Bereich des Nutzers auslöst. Damit deine App diesen impliziten Intent empfangen kann, musst du in der Manifestdatei deiner App ein <intent-filter> mit einem <category> von CATEGORY_APP_MARKET deklarieren.

Minimale SDK-Zielversion wurde von 23 auf 24 erhöht

Android 15 baut auf den Änderungen in Android 14 auf und erweitert diese Sicherheit noch. Unter Android 15 können Apps mit einem targetSdkVersion unter 24 nicht installiert werden. Wenn Anwendungen die modernen API-Levels erfüllen müssen, werden Sicherheit und Datenschutz verbessert.

Malware zielt häufig auf niedrigere API-Levels ab, um die mit höheren Android-Versionen eingeführten Sicherheits- und Datenschutzfunktionen zu umgehen. Bei einigen Malware-Apps wird beispielsweise für targetSdkVersion der Wert 22 verwendet, damit sie nicht dem 2015 von Android 6.0 Marshmallow (API-Level 23) eingeführten Laufzeitberechtigungsmodell unterliegen. Durch diese Änderung bei Android 15 wird es Malware schwerer, Verbesserungen bei der Sicherheit und beim Datenschutz zu vermeiden. Der Versuch, eine Anwendung zu installieren, die auf eine niedrigere API-Ebene ausgerichtet ist, führt zu einem Installationsfehler und in Logcat wird eine Meldung wie die folgende angezeigt:

INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 24, but found 7

Auf Geräten, die auf Android 15 aktualisiert werden, bleiben alle Apps mit einer targetSdkVersion unter 24 installiert.

Wenn Sie eine App testen müssen, die auf ein älteres API-Level ausgerichtet ist, verwenden Sie den folgenden ADB-Befehl:

adb install --bypass-low-target-sdk-block FILENAME.apk

Kamera und Medien

Unter Android 15 werden die folgenden Änderungen am Kamera- und Medienverhalten für alle Apps vorgenommen.

Bei der direkten und ausgelagerten Audiowiedergabe werden jetzt die zuvor geöffneten direkten und ausgelagerten Audiotracks ungültig, wenn Ressourcenlimits erreicht sind.

Vor Android 15 forderte eine App die direkte oder Auslagerung der Audiowiedergabe an, während eine andere App Audio abspielte. Wenn die Ressourcenlimits erreicht wurden, konnte die App kein neues AudioTrack öffnen.

Wenn eine App die Wiedergabe direkt oder auslagernd anfordert und die Ressourcenlimits erreicht sind, werden ab Android 15 alle derzeit geöffneten AudioTrack-Objekte ungültig, sodass die neue Trackanfrage nicht ausgeführt werden kann.

Direkte und ausgelagerte Audiotracks werden in der Regel für die Wiedergabe komprimierter Audioformate geöffnet. Zu den häufigsten Anwendungsfällen für die direkte Audiowiedergabe gehört das Streaming von codiertem Audio über HDMI auf einen Fernseher. Offload-Tracks werden normalerweise verwendet, um komprimierte Audiodaten auf einem Mobilgerät mit Hardware-DSP-Beschleunigung abzuspielen.)

Nutzererfahrung und System-UI

Android 15 umfasst einige Änderungen, die eine einheitlichere, intuitivere User Experience schaffen sollen.

Vorausschauende Rückanimationen für Apps aktiviert, die diese Option aktiviert haben

Ab Android 15 wurde die Entwickleroption für vorhergehende Back-Animationen entfernt. Systemanimationen wie „Zurück zum Startbildschirm“, „Cross-Tasks“ und „Cross-Aktivitäten“ werden jetzt für Apps angezeigt, die entweder vollständig oder auf Aktivitätsebene die vorausschauende „Zurück“-Touch-Geste aktiviert haben. Wenn Ihre App betroffen ist, gehen Sie so vor:

  • Prüfen Sie, ob Ihre App ordnungsgemäß migriert wurde, um die automatische Prognosefunktion zu verwenden.
  • Sorgen Sie dafür, dass die Fragmentübergänge mit der vorausschauenden Zurück-Navigation funktionieren.
  • Migrieren Sie weg von Animations- und Framework-Übergängen und verwenden Sie stattdessen Animator- und Androidx-Übergänge.
  • Migrieren Sie weg von Back-Stacks, die FragmentManager nicht bekannt sind. Verwenden Sie stattdessen Back Stacks, die von FragmentManager oder der Navigationskomponente verwaltet werden.

Widgets sind deaktiviert, wenn der Nutzer das Beenden einer App erzwingt

Wenn ein Nutzer das Beenden einer App auf einem Gerät mit Android 15 erzwingt, deaktiviert das System vorübergehend alle Widgets der App. Die Widgets sind ausgegraut und der Nutzer kann nicht mit ihnen interagieren. Das liegt daran, dass ab Android 15 alle ausstehenden Intents einer App abgebrochen werden, wenn das Beenden der App erzwungen wird.

Das System aktiviert diese Widgets wieder, wenn der Nutzer die App das nächste Mal startet.

Weitere Informationen finden Sie unter Änderungen am Status „Paket angehalten“.

Einstellung von Produkten und Funktionen

Mit jedem Release können bestimmte Android-APIs veraltet sein oder refaktoriert werden, um die Entwicklung zu verbessern oder neue Plattformfunktionen zu unterstützen. In diesen Fällen stellen wir die veralteten APIs offiziell ein und leiten Entwickler zu alternativen APIs weiter.

Das bedeutet, dass wir den offiziellen Support für die APIs eingestellt haben. Sie sind jedoch weiterhin für Entwickler verfügbar. Weitere Informationen zu wichtigen Einstellungen in dieser Android-Version finden Sie auf der Seite zu den Einstellungen.