Verhaltensänderungen: alle Apps

Die Android 15-Plattform enthält 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. Sie sollten Ihre App testen und sie gegebenenfalls so ändern, dass sie diese Anforderungen erfüllt.

Lesen Sie sich auch die Liste der Verhaltensänderungen durch, die sich nur auf Apps auswirken, die auf Android 15 ausgerichtet sind.

Hauptfunktion

In Android 15 wurden verschiedene Kernfunktionen des Android-Systems geändert oder erweitert.

Änderungen am Status „Angehalten“ des Pakets

The intention of the package FLAG_STOPPED state (which users can engage in AOSP builds by long-pressing an app icon and selecting "Force Stop") has always been to keep apps in this state until the user explicitly removes the app from this state by directly launching the app or indirectly interacting with the app (through the sharesheet or a widget, selecting the app as live wallpaper, etc.). In Android 15, we've updated the behavior of the system to be aligned with this intended behavior. Apps should only be removed from the stopped state through direct or indirect user action.

To support the intended behavior, in addition to the existing restrictions, the system also cancels all pending intents when the app enters the stopped state on a device running Android 15. When the user's actions remove the app from the stopped state, the ACTION_BOOT_COMPLETED broadcast is delivered to the app providing an opportunity to re-register any pending intents.

You can call the new ApplicationStartInfo.wasForceStopped() method to confirm whether the app was put into the stopped state.

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

Bisher wurden in Android nur Seitengrößen von 4 KB unterstützt, eine optimierte Systemspeicherleistung für die durchschnittliche In der Regel gab es Android-Geräte. Ab Android 15 unterstützt AOSP Geräte, die für die Verwendung einer Seitengröße von 16 KB (16 KB) konfiguriert sind Geräte). Wenn Ihre App NDK-Bibliotheken verwendet, können Sie entweder direkt oder indirekt über ein SDK, müssen Sie Ihre App die auf diesen 16-KB-Geräten funktionieren.

Da Gerätehersteller immer mehr Geräte entwickeln, physischen Arbeitsspeicher (RAM), verwenden viele dieser Geräte 16 KB (und größer werden), um die Leistung des Geräts zu optimieren. Wird hinzugefügt wird die Unterstützung für Geräte mit einer Seitengröße von 16 KB ermöglicht, Geräte und unterstützt Ihre App dabei, von der damit verbundenen Leistung Verbesserungen. Ohne Neukompilierung funktionieren Apps auf Geräten mit 16 KB möglicherweise nicht wenn sie in zukünftigen Android-Versionen produktionsreif sind.

Damit Sie Unterstützung für Ihre App hinzufügen können, haben wir eine Anleitung zur Überprüfung der falls Ihre App betroffen ist, Ihre App neu zu erstellen (falls zutreffend) und wie Sie Ihre App eine 16 KB-Umgebung mit Emulatoren (einschließlich Android 15) System-Images für den Android-Emulator).

Benefits and performance gains

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

  • Kürzere App-Startzeiten, während das System unter Speicherauslastung steht: im Durchschnitt 3,16 % niedriger, mit deutlicheren Verbesserungen (bis zu 30%) bei einigen von uns getesteten Apps
  • Verringerter Stromverbrauch beim Starten der App: durchschnittlich 4,56% weniger
  • Schnellerer Kamerastart: 4,48% schnellere Heißstarts und 6,60% schnellere Kaltstarts im Durchschnitt
  • Verbesserte Systemstartzeit: durchschnittlich um 8% (ca. 950 Millisekunden)

Diese Verbesserungen basieren auf unseren ersten Tests. Die Ergebnisse auf tatsächlichen Geräten werden sich wahrscheinlich unterscheiden. Im Rahmen unserer Tests werden wir zusätzliche Analysen zu den potenziellen Vorteilen für Apps durchführen.

Check if your app is impacted

Wenn Ihre App nativen Code verwendet, sollten Sie Ihre App mit Unterstützung für 16 KB-Geräte neu erstellen. Wenn Sie nicht sicher sind, ob Ihre App nativen Code verwendet, können Sie mit dem APK-Analysetool prüfen, ob nativer Code vorhanden ist, und dann die Ausrichtung der ELF-Segmente für alle gefundenen freigegebenen Bibliotheken prüfen.

Wenn in Ihrer App nur Code verwendet wird, der in der Programmiersprache Java oder Kotlin geschrieben ist, einschließlich aller Bibliotheken oder SDKs, unterstützt Ihre App bereits Geräte mit 16 KB. Wir empfehlen Ihnen jedoch, Ihre App in einer 16-KB-Umgebung zu testen, um sicherzustellen, dass es keine unerwarteten Rückschritte beim App-Verhalten gibt.

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

Vertrauliche Profile sind eine neue Funktion in Android 15. Damit können Nutzer einen separaten Bereich auf ihrem Gerät erstellen, in dem sensible Apps durch eine zusätzliche Authentifizierung vor neugierigen Blicken geschützt werden. Da die Sichtbarkeit von Apps im vertraulichen Profil eingeschränkt ist, müssen bei einigen Arten von Apps zusätzliche Schritte ausgeführt werden, damit sie im vertraulichen Profil eines Nutzers angezeigt werden und damit Nutzer mit ihnen interagieren können.

Alle Apps

Da Apps im privaten Bereich in einem separaten Nutzerprofil gespeichert werden, ähnlich wie Arbeitsprofile, sollten Apps nicht davon ausgehen, dass installierte Kopien ihrer App, die sich nicht im Hauptprofil befinden, sich im Arbeitsprofil befinden. Wenn Ihre App Logik für Apps mit Arbeitsprofil enthält, die diese Annahme treffen, müssen Sie diese Logik anpassen.

Medizinische Apps

Wenn ein Nutzer das vertrauliche Profil sperrt, werden alle Apps darin angehalten. Diese Apps können dann keine Aktivitäten im Vordergrund oder Hintergrund ausführen, z. B. keine Benachrichtigungen anzeigen. Dieses Verhalten kann sich erheblich auf die Nutzung und Funktion von medizinischen Apps auswirken, die im vertraulichen Profil installiert sind.

Bei der Einrichtung des vertraulichen Profils werden Nutzer darauf hingewiesen, dass es sich nicht für Apps eignet, die wichtige Aktivitäten im Vordergrund oder Hintergrund ausführen müssen, z. B. die Anzeige von Benachrichtigungen von medizinischen Apps. Apps können jedoch nicht feststellen, ob sie im privaten Profil verwendet werden, und können dem Nutzer daher in diesem Fall keine Warnung anzeigen.

Wenn Sie also eine medizinische App entwickeln, sollten Sie prüfen, wie sich diese Funktion auf Ihre App auswirken könnte, und entsprechende Maßnahmen ergreifen, z. B. Ihre Nutzer darüber informieren, dass sie Ihre App nicht in einem vertraulichen Profil installieren sollen, um Unterbrechungen wichtiger App-Funktionen zu vermeiden.

Launcher-Apps

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

  1. Ihre App muss als Standard-Launcher-App für das Gerät zugewiesen sein, d. h. sie muss die Rolle ROLE_HOME haben.
  2. Ihre App muss die normale Berechtigung ACCESS_HIDDEN_PROFILES in der Manifestdatei Ihrer App deklarieren.

Launcher-Apps, die die Berechtigung ACCESS_HIDDEN_PROFILES angeben, müssen die folgenden Anwendungsfälle für vertrauliche Profile unterstützen:

  1. Ihre App muss einen separaten Launcher-Container für Apps haben, die im vertraulichen Profil installiert sind. Mit der Methode getLauncherUserInfo() kannst du feststellen, welcher Nutzerprofiltyp verarbeitet wird.
  2. Der Nutzer muss den Container für das vertrauliche Profil ausblenden und einblenden können.
  3. Der Nutzer muss den Container für das vertrauliche Profil sperren und entsperren können. Verwenden Sie die Methode requestQuietModeEnabled(), um das vertrauliche Profil zu sperren (true übergeben) oder zu entsperren (false übergeben).
  4. Wenn das vertrauliche Profil gesperrt ist, sollten keine Apps im Container des vertraulichen Profils sichtbar sein oder über Mechanismen wie die Suche gefunden werden können. Ihre App sollte einen Empfänger für die Übertragungen von ACTION_PROFILE_AVAILABLE und ACTION_PROFILE_UNAVAILABLE registrieren und die Benutzeroberfläche in Ihrer App aktualisieren, wenn sich der gesperrte oder entsperrte Status des Containers für den privaten Bereich ändert. Beide Streams enthalten EXTRA_USER, mit dem sich in Ihrer App auf den Nutzer mit privatem Profil Bezug nehmen lässt.

    Sie können auch die Methode isQuietModeEnabled() verwenden, um zu prüfen, ob das Profil des privaten Bereichs gesperrt ist.

App-Shop-Apps

Das vertrauliche Profil enthält die Schaltfläche „Apps installieren“, über die Apps implizit im vertraulichen Profil des Nutzers installiert werden. Damit Ihre App diese implizite Absicht erhält, müssen Sie in der Manifestdatei Ihrer App eine <intent-filter> mit einer <category> von CATEGORY_APP_MARKET deklarieren.

PNG-basierte Emoji-Schriftart entfernt

The legacy, PNG-based emoji font file (NotoColorEmojiLegacy.ttf) has been removed, leaving just the vector-based file. Beginning with Android 13 (API level 33), the emoji font file used by the system emoji renderer changed from a PNG-based file to a vector based file. The system retained the legacy font file in Android 13 and 14 for compatibility reasons, so that apps with their own font renderers could continue to use the legacy font file until they were able to upgrade.

To check if your app is affected, search your app's code for references to the NotoColorEmojiLegacy.ttf file.

You can choose to adapt your app in a number of ways:

  • Use platform APIs for text rendering. You can render text to a bitmap-backed Canvas and use that to get a raw image if necessary.
  • Add COLRv1 font support to your app. The FreeType open source library supports COLRv1 in version 2.13.0 and higher.
  • As a last resort, you can bundle the legacy emoji font file (NotoColorEmoji.ttf) into your APK, although in that case your app will be missing the latest emoji updates. For more information, see the Noto Emoji GitHub project page.

Die Mindestversion der SDK-Zielversion wurde von 23 auf 24 erhöht

Android 15 builds on the the changes that were made in Android 14 and extends this security further. In Android 15, apps with a targetSdkVersion lower than 24 can't be installed. Requiring apps to meet modern API levels helps to ensure better security and privacy.

Malware often targets lower API levels in order to bypass security and privacy protections that have been introduced in higher Android versions. For example, some malware apps use a targetSdkVersion of 22 to avoid being subjected to the runtime permission model introduced in 2015 by Android 6.0 Marshmallow (API level 23). This Android 15 change makes it harder for malware to avoid security and privacy improvements. Attempting to install an app targeting a lower API level results in an installation failure, with a message like the following one appearing in Logcat:

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

On devices upgrading to Android 15, any apps with a targetSdkVersion lower than 24 remain installed.

If you need to test an app targeting an older API level, use the following ADB command:

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

Sicherheit und Datenschutz

Android 15 introduces robust measures to combat one-time passcode (OTP) fraud and to protect the user's sensitive content, focusing on hardening the Notification Listener Service and screenshare protections. Key enhancements include redacting OTPs from notifications accessible to untrusted apps, hiding notifications during screenshare, and securing app activities when OTPs are posted. These changes aim to keep the user's sensitive content safe from unauthorized actors.

Developers need to be aware of the following to ensure their apps are compatible with the changes in Android 15:

OTP Redaction

Android will stop untrusted apps that implement a NotificationListenerService from reading unredacted content from notifications where an OTP has been detected. Trusted apps such as companion device manager associations are exempt from these restrictions.

Screenshare Protection

  • Notification content is hidden during screen sharing sessions to preserve the user's privacy. If the app implements setPublicVersion(), Android shows the public version of the notification which serves as a replacement notification in insecure contexts. Otherwise, the notification content is redacted without any further context.
  • Sensitive content like password input is hidden from remote viewers to prevent revealing the user's sensitive information.
  • Activities from apps that post notifications during screenshare where an OTP has been detected will be hidden. App content is hidden from the remote viewer when launched.
  • Beyond Android's automatic identification of sensitive fields, developers can manually mark parts of their app as sensitive using setContentSensitivity, which is hidden from remote viewers during screenshare.
  • Developers can choose to toggle the Disable screen share protections option under Developer Options to be exempted from the screenshare protections for demo or testing purposes. The default system screen recorder is exempted from these changes, since the recordings remain on-device.

Kamera und Medien

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

Bei der direkten und Offload-Audiowiedergabe werden zuvor geöffnete direkte oder Offload-Audiotracks ungültig, wenn die Ressourcenlimits erreicht werden.

Before Android 15, if an app requested direct or offload audio playback while another app was playing audio and the resource limits were reached, the app would fail to open a new AudioTrack.

Beginning with Android 15, when an app requests direct or offload playback and the resource limits are reached, the system invalidates any currently open AudioTrack objects which prevent fulfilling the new track request.

(Direct and offload audio tracks are typically opened for playback of compressed audio formats. Common use-cases for playing direct audio include streaming encoded audio over HDMI to a TV. Offload tracks are typically used to play compressed audio on a mobile device with hardware DSP acceleration.)

Nutzerfreundlichkeit und System-UI

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

Animationen für intelligente „Zurück“-Touch-Geste für Apps aktiviert, die die Funktion aktiviert haben

Beginning in Android 15, the developer option for predictive back animations has been removed. System animations such as back-to-home, cross-task, and cross-activity now appear for apps that have opted in to the predictive back gesture either entirely or at an activity level. If your app is affected, take the following actions:

  • Ensure that your app has been properly migrated to use the predictive back gesture.
  • Ensure that your fragment transitions work with predictive back navigation.
  • Migrate away from animation and framework transitions and use animator and androidx transitions instead.
  • Migrate away from back stacks that FragmentManager doesn't know about. Use back stacks managed by FragmentManager or by the Navigation component instead.

Widgets werden deaktiviert, wenn der Nutzer eine App erzwungen beendet

Wenn ein Nutzer eine App auf einem Gerät mit Android 15 erzwungen beendet, 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 vom System abgebrochen werden, wenn die App erzwungen beendet 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 „Angehalten“ für Pakete.

Statusleiste-Chip für die Medienprojektion benachrichtigt Nutzer über Bildschirmfreigabe, Streaming und Aufzeichnung

Screen projection exploits expose private user data such as financial information because users don't realize their device screen is being shared.

For apps running on devices with Android 15 QPR1 or higher, a status bar chip that is large and prominent alerts users to any in‑progress screen projection. Users can tap the chip to stop their screen from being shared, cast, or recorded. Also, screen projection automatically stops when the device screen is locked.

Status bar chip for screen sharing, casting, and recording.

Check if your app is impacted

By default, your app includes the status bar chip and automatically suspends screen projection when the lock screen activates.

To learn more about how to test your app for these use cases, see Status bar chip and auto stop.

Einschränkungen für den Netzwerkzugriff im Hintergrund

In Android 15, apps that start a network request outside of a valid process lifecycle receive an exception. Typically, an UnknownHostException or other socket-related IOException. Network requests that happen outside of a valid lifecycle are usually due to apps unknowingly continuing a network request even after the app is no longer active.

To mitigate this exception, ensure your network requests are lifecycle aware and cancelled upon leaving a valid process lifecycle by using lifecycle aware components. If it is important that the network request should happen even when the user leaves the application, consider scheduling the network request using WorkManager or continue a user visible task using Foreground Service.

Einstellung von Produkten und Funktionen

Mit jeder Version können bestimmte Android APIs veraltet werden oder müssen umgestaltet werden, um Entwicklern mehr Möglichkeiten zu bieten oder neue Plattformfunktionen zu unterstützen. In diesen Fällen werden die veralteten APIs offiziell eingestellt und Entwickler werden auf alternative APIs verwiesen.

Das bedeutet, dass wir die offizielle Unterstützung für die APIs eingestellt haben, sie aber weiterhin für Entwickler verfügbar sind. Weitere Informationen zu wichtigen Einstellung von Funktionen in dieser Android-Version finden Sie auf der Seite zu eingestellten Funktionen.