Changements de comportement : toutes les applications

La plate-forme Android 14 inclut des modifications de comportement susceptibles d'affecter votre application. Les modifications de comportement suivantes s'appliquent à toutes les applications lorsqu'elles s'exécutent sur Android 14, quel que soit le targetSdkVersion. Vous devez tester votre application, puis la modifier si nécessaire afin de prendre en charge ces modifications, le cas échéant.

Veillez également à consulter la liste des modifications de comportement qui n'affectent que les applications ciblant Android 14.

Fonctionnalité de base

Les alarmes exactes programmées sont refusées par défaut

Exact alarms are meant for user-intentioned notifications, or for actions that need to happen at a precise time. Starting in Android 14, the SCHEDULE_EXACT_ALARM permission is no longer being pre-granted to most newly installed apps targeting Android 13 and higher—the permission is denied by default.

Learn more about the changes to the permission for scheduling exact alarms.

Les annonces diffusées en contexte sont mises en file d'attente pendant que les applications sont mises en cache.

On Android 14, the system can place context-registered broadcasts in a queue while the app is in the cached state. This is similar to the queuing behavior that Android 12 (API level 31) introduced for async binder transactions. Manifest-declared broadcasts aren't queued, and apps are removed from the cached state for broadcast delivery.

When the app leaves the cached state, such as returning to the foreground, the system delivers any queued broadcasts. Multiple instances of certain broadcasts might be merged into one broadcast. Depending on other factors, such as system health, apps might be removed from the cached state, and any previously queued broadcasts are delivered.

Les applications ne peuvent fermer que leurs propres processus en arrière-plan

À partir d'Android 14, lorsque votre application appelle killBackgroundProcesses(), seuls les processus en arrière-plan de votre propre application peuvent être fermés par l'API.

Si vous transmettez le nom de package d'une autre application, cette méthode n'a aucun effet sur les processus en arrière-plan de cette application et le message suivant s'affiche dans Logcat :

Invalid packageName: com.example.anotherapp

Votre application ne doit pas utiliser l'API killBackgroundProcesses() ni tenter d'influencer le cycle de vie d'autres applications, même sur des versions d'OS plus anciennes. Android est conçu pour conserver les applications mises en cache en arrière-plan et les fermer automatiquement lorsque le système a besoin de mémoire. Si votre application ferme d'autres applications de manière inutile, elle peut réduire les performances du système et augmenter la consommation de la batterie en exigeant un redémarrage complet de ces applications par la suite, ce qui nécessite beaucoup plus de ressources que la réactivation d'une application existante mise en cache.

La MTU est définie sur 517 pour le premier client GATT demandant une MTU.

À partir d'Android 14, la pile Bluetooth Android respecte plus strictement la version 5.2 de la spécification Bluetooth Core. Elle demande le MTU BLE ATT à 517 octets lorsque le premier client GATT demande un MTU à l'aide de l'API BluetoothGatt#requestMtu(int) et ignore toutes les demandes de MTU ultérieures sur cette connexion LCA.

Pour résoudre ce changement et renforcer la robustesse de votre application, envisagez les options suivantes:

  • Votre périphérique doit répondre à la requête de MTU de l'appareil Android avec une valeur raisonnable pouvant être acceptée par le périphérique. La valeur finale négociée correspondra au minimum à la valeur demandée par Android et à la valeur fournie à distance (par exemple, min(517, remoteMtu)).
    • L'implémentation de ce correctif peut nécessiter une mise à jour du micrologiciel pour les périphériques
  • Vous pouvez également limiter les écritures de caractéristiques GATT en fonction du minimum entre la valeur compatible connue de votre périphérique et la modification du MTU reçue.
    • Rappel : vous devez réduire de 5 octets la taille acceptée pour les en-têtes.
    • Par exemple : arrayMaxLength = min(SUPPORTED_MTU, GATT_MAX_ATTR_LEN(517)) - 5

Nouveau motif pour lequel une application peut être placée dans le bucket de secours restreint

Android 14 introduit une nouvelle raison pour laquelle une application peut être placée dans le bucket en veille limitée. Les tâches de l'application déclenchent des erreurs ANR à plusieurs reprises en raison des délais avant expiration des méthodes onStartJob, onStopJob ou onBind. Pour en savoir plus sur les modifications apportées à onStartJob et onStopJob, consultez la section JobScheduler renforce le comportement de rappel et du réseau.

Pour savoir si l'application est passée ou non dans le bucket de mise en veille limitée, nous vous recommandons de vous connecter avec l'API UsageStatsManager.getAppStandbyBucket() lors de l'exécution de la tâche ou UsageStatsManager.queryEventsForSelf() au démarrage de l'application.

mlock limité à 64 Ko

In Android 14 (API level 34) and higher, the platform reduces the maximum memory that can be locked using mlock() to 64 KB per process. In previous versions, the limit was 64 MB per process. This restriction promotes better memory management across apps and the system. To provide more consistency across devices, Android 14 adds a new CTS test for the new mlock() limit on compatible devices.

Le système applique l'utilisation des ressources des applications mises en cache

By design, an app's process is in a cached state when it's moved to the background and no other app process components are running. Such an app process is subject to being killed due to system memory pressure. Any work that Activity instances perform after the onStop() method has been called and returned, while in this state, is unreliable and strongly discouraged.

Android 14 introduces consistency and enforcement to this design. Shortly after an app process enters a cached state, background work is disallowed, until a process component re-enters an active state of the lifecycle.

Apps that use typical framework-supported lifecycle APIs – such as services, JobScheduler, and Jetpack WorkManager – shouldn't be impacted by these changes.

Expérience utilisateur

Modifications apportées à la façon dont les utilisateurs gèrent les notifications qu'ils ne peuvent pas ignorer

Si votre application affiche des notifications au premier plan que les utilisateurs peuvent ignorer, Android 14 a changé leur comportement pour permettre aux utilisateurs d'ignorer ces notifications.

Cette modification s'applique aux applications qui empêchent les utilisateurs d'ignorer les notifications de premier plan en définissant Notification.FLAG_ONGOING_EVENT via Notification.Builder#setOngoing(true) ou NotificationCompat.Builder#setOngoing(true). Le comportement de FLAG_ONGOING_EVENT a été modifié afin que l'utilisateur puisse ignorer ces notifications.

Vous ne pouvez pas ignorer ces types de notifications dans les conditions suivantes :

  • Lorsque le téléphone est verrouillé
  • Si l'utilisateur sélectionne une action de notification Tout effacer (ce qui facilite la fermeture accidentelle)

En outre, ce nouveau comportement ne s'applique pas aux notifications dans les cas d'utilisation suivants:

  • CallStyle notifications
  • Outil de contrôle des règles relatives aux appareils (DPC) et packages compatibles pour les entreprises
  • Notifications multimédias
  • Package de sélecteur de recherche par défaut

Amélioration de la visibilité des informations sur la sécurité des données

To enhance user privacy, Android 14 increases the number of places where the system shows the information you have declared in the Play Console form. Currently, users can view this information in the Data safety section on your app's listing in Google Play.

We encourage you to review your app's location data sharing policies and take a moment to make any applicable updates to your app's Google Play Data safety section.

Learn more in the guide about how data safety information is more visible on Android 14.

Accessibilité

Mise à l'échelle non linéaire de la police à 200 %

Starting in Android 14, the system supports font scaling up to 200%, providing low-vision users with additional accessibility options that align with Web Content Accessibility Guidelines (WCAG).

If you already use scaled pixels (sp) units to define text sizing, then this change probably won't have a high impact on your app. However, you should perform UI testing with the maximum font size enabled (200%) to ensure that your app can accommodate larger font sizes without impacting usability.

Sécurité

Niveau d'API cible installable minimal

Starting with Android 14, apps with a targetSdkVersion lower than 23 can't be installed. Requiring apps to meet these minimum target API level requirements improves security and privacy for users.

Malware often targets older API levels in order to bypass security and privacy protections that have been introduced in newer 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 14 change makes it harder for malware to avoid security and privacy improvements. Attempting to install an app targeting a lower API level will result in an installation failure, with the following message appearing in Logcat:

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

On devices upgrading to Android 14, any apps with a targetSdkVersion lower than 23 will 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

Les noms de package du propriétaire média peuvent être masqués

Le Media Store accepte les requêtes pour la colonne OWNER_PACKAGE_NAME, qui indique l'application qui a stocké un fichier multimédia spécifique. À partir d'Android 14, cette valeur sera masquée, sauf si au moins l'une des conditions suivantes est remplie :

  • Le nom de package de l'application qui a stocké le fichier multimédia est toujours visible par les autres applications.
  • L'application qui interroge le Media Store demande l'autorisation QUERY_ALL_PACKAGES.

Découvrez comment Android filtre la visibilité des packages à des fins de confidentialité.