Modifications de comportement : applications ciblant Android 17 ou version ultérieure

Comme les versions précédentes, Android 17 apporte des modifications de comportement pouvant affecter votre application. Les modifications de comportement suivantes s'appliquent exclusivement aux applications qui ciblent Android 17 ou version ultérieure. Si votre application cible Android 17 ou une version ultérieure, vous devez la modifier pour qu'elle prenne en charge ces comportements, le cas échéant.

Veillez également à consulter la liste des modifications de comportement qui affectent toutes les applications exécutées sur Android 17, quel que soit le targetSdkVersion de votre application.

Fonctionnalité de base

Android 17 inclut les modifications suivantes qui modifient ou étendent diverses fonctionnalités de base du système Android.

Nouvelle implémentation sans verrouillage de MessageQueue

À partir d'Android 17, les applications ciblant Android 17 ou version ultérieure reçoivent une nouvelle implémentation sans verrouillage de android.os.MessageQueue. La nouvelle implémentation améliore les performances et réduit les images manquantes, mais peut casser les clients qui reflètent les champs et méthodes privés MessageQueue.

Pour en savoir plus, y compris sur les stratégies d'atténuation, consultez le guide sur les changements de comportement de MessageQueue.

Accessibilité

Android 17 apporte les modifications suivantes pour améliorer l'accessibilité.

Cette fonctionnalité introduit de nouvelles API AccessibilityEvent et TextAttribute pour améliorer le retour vocal du lecteur d'écran pour la saisie de texte en langues CJKV. Les applications CJKV IME peuvent désormais signaler si un candidat à la conversion de texte a été sélectionné lors de la composition du texte. Les applications avec des champs de modification peuvent spécifier des types de modification de texte lors de l'envoi d'événements d'accessibilité de texte modifié. Par exemple, les applications peuvent spécifier qu'une modification de texte s'est produite lors de la composition du texte ou qu'une modification de texte résulte d'un commit. Cela permet aux services d'accessibilité tels que les lecteurs d'écran de fournir des commentaires plus précis en fonction de la nature de la modification du texte.

Nombre d'applications utilisant le SDK

Applications IME : lors de la définition de la composition de texte dans les champs de modification, les IME peuvent utiliser TextAttribute.Builder.setTextSuggestionSelected() pour indiquer si un candidat à la conversion spécifique a été sélectionné.
Applications avec des champs de modification : les applications qui gèrent un InputConnection personnalisé peuvent récupérer les données de sélection des candidats en appelant TextAttribute.isTextSuggestionSelected(). Ces applications doivent ensuite appeler AccessibilityEvent.setTextChangeTypes() lors de l'envoi d'événements TYPE_VIEW_TEXT_CHANGED. Les applications ciblant Android 17 qui utilisent le TextView standard verront cette fonctionnalité activée par défaut. (Autrement dit, TextView gérera la récupération des données de l'IME et la définition des types de modification de texte lors de l'envoi d'événements aux services d'accessibilité.)
Services d'accessibilité : les services d'accessibilité qui traitent les événements TYPE_VIEW_TEXT_CHANGED peuvent appeler AccessibilityEvent.getTextChangeTypes() pour identifier la nature de la modification et ajuster leurs stratégies de commentaires en conséquence.

Sécurité

Android 17 apporte les améliorations suivantes à la sécurité des appareils et des applications.

Sécurité de l'activité

In Android 17, the platform continues its shift toward a "secure-by-default" architecture, introducing a suite of enhancements designed to mitigate high-severity exploits such as phishing, interaction hijacking, and confused deputy attacks. This update requires developers to explicitly opt in to new security standards to maintain app compatibility and user protection.

Key impacts for developers include:

BAL hardening & improved opt-in: We are refining Background Activity Launch (BAL) restrictions by extending protections to IntentSender. Developers must migrate away from the legacy MODE_BACKGROUND_ACTIVITY_START_ALLOWED constant. Instead, you should adopt granular controls like MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, which restricts activity starts to scenarios where the calling app is visible, significantly reducing the attack surface.
Adoption tools: Developers should utilize strict mode and updated lint checks to identify legacy patterns and ensure readiness for future target SDK requirements.

Protections localhost

To improve platform security and user privacy, Android 17 introduces a new install-time permission, USE_LOOPBACK_INTERFACE. This change restricts cross-app and cross-profile communication over the loopback interface (for example, 127.0.0.1 or ::1), which was previously implicitly allowed with the INTERNET permission. For apps targeting Android 17 or higher, the following rules apply:

Mutual consent required: cross-app and cross-profile communication is now blocked by default. For a connection to succeed, both the sending app and the receiving app must explicitly declare the USE_LOOPBACK_INTERFACE permission in their manifests.
Intra-app traffic exempt: Loopback communication within the same app (intra-app communication) remains unaffected and does not require this new permission.
Target SDK behavior:
- App targets Android 17 or higher: The permission must be explicitly requested. If it is missing, socket operations (such as TCP connect or UDP send) fail, typically returning an EPERM (operation not permitted) error.
- App targets API level 36 or lower: The permission is treated as a split permission on INTERNET. Apps targeting lower API levels are auto-granted this permission if they hold INTERNET.
Compatibility warning: If a receiving app updates its target to Android 17 but fails to request this permission, incoming connections from other apps are be rejected, even if the sending app targets a lower API level.

Activer la CT par défaut

Si une application cible Android 17 ou version ultérieure, la transparence des certificats (CT) est activée par défaut. (Sur Android 16, la CT est disponible, mais les applications doivent l'activer.)

Safer Native DCL-C

Si votre application cible Android 17 ou version ultérieure, la protection Safer Dynamic Code Loading (DCL) introduite dans Android 14 pour les fichiers DEX et JAR s'étend désormais aux bibliothèques natives.

Tous les fichiers natifs chargés à l'aide de System.load() doivent être marqués en lecture seule. Sinon, le système génère une exception UnsatisfiedLinkError.

Nous vous recommandons d'éviter le chargement dynamique de code dans la mesure du possible, car cela augmente considérablement le risque que l'application soit compromise par une injection ou une falsification de code.

Facteurs de forme des appareils

Android 17 inclut les modifications suivantes pour améliorer l'expérience utilisateur sur différentes tailles d'appareils et différents facteurs de forme.

Modifications apportées aux API de la plate-forme pour ignorer les contraintes d'orientation, de redimensionnement et de format sur les grands écrans (sw>=600dp)

Nous avons introduit des modifications de l'API de plate-forme dans Android 16 pour ignorer les restrictions d'orientation, de format et de redimensionnement sur les grands écrans (largeur d'écran >= 600 dp) pour les applications ciblant le niveau d'API 36 ou supérieur. Les développeurs ont la possibilité de désactiver ces modifications avec le SDK 36, mais cette option ne sera plus disponible pour les applications ciblant Android 17 ou version ultérieure.

Pour en savoir plus, consultez Les restrictions concernant l'orientation et le redimensionnement sont ignorées.