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, peu importe la 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 (niveau d'API 37) ou une 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 le nombre d'images manquées, mais peut interrompre 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 modifications du comportement de MessageQueue behavior change guidance.

Les champs statiques finals ne sont plus modifiables

Les applications exécutées sur Android 17 ou version ultérieure qui ciblent Android 17 (niveau d'API 37) ou version ultérieure ne peuvent pas modifier les champs static final. Si une application tente de modifier un champ static final à l'aide de la réflexion, cela entraînera une IllegalAccessException. Toute tentative de modification de l'un de ces champs via les API JNI (telles que SetStaticLongField()) entraînera le plantage de l'application.

Accessibilité

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

Prise en charge de l'accessibilité pour la saisie au clavier physique IME complexe

Cette fonctionnalité introduit de nouvelles AccessibilityEvent et TextAttribute API pour améliorer le retour vocal du lecteur d'écran pour la saisie de langues CJKV. Les applications IME CJKV peuvent désormais indiquer si un candidat de conversion de texte a été sélectionné lors de la composition de 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 de texte ou qu'elle 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 de 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 la distribution d'événements TYPE_VIEW_TEXT_CHANGED. Cette fonctionnalité est activée par défaut pour les applications ciblant Android 17 (niveau d'API 37) qui utilisent le TextView standard. (Autrement dit, TextView gère 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.

Confidentialité

Android 17 inclut les modifications suivantes pour améliorer la confidentialité des utilisateurs.

Activation d'ECH (Encrypted Client Hello)

Android 17 introduces platform support for Encrypted Client Hello (ECH), a TLS extension that enhances user privacy by encrypting the Server Name Indication (SNI) in the TLS handshake. This encryption helps prevent network observers from easily identifying the specific domain your app is connecting to.

For apps targeting Android 17 (API level 37) or higher, ECH is used for TLS connections. ECH is active only if the networking library used by the app (for example, HttpEngine, WebView, or OkHttp) has integrated ECH support and the remote server also supports the ECH protocol. If ECH cannot be negotiated, the client sends an ECH extension with randomized contents (a mechanism called ECH GREASE). See RFC 9849 for more details on how ECH GREASE works.

To allow apps to customize this behavior, Android 17 adds a new <domainEncryption> element to the Network Security Configuration file. Developers can use <domainEncryption> within <base-config> or <domain-config> tags to select an ECH mode (for example, "enabled" or "disabled") on a global or per-domain basis.

For more information, see the Encrypted Client Hello documentation.

Autorisation de réseau local requise pour les applications ciblant Android 17

Android 17 introduces the ACCESS_LOCAL_NETWORK runtime permission to protect users from unauthorized local network access. Because this falls under the existing NEARBY_DEVICES permission group, users who have already granted other NEARBY_DEVICES permissions aren't prompted again. This new requirement prevents malicious apps from exploiting unrestricted local network access for covert user tracking and fingerprinting. By declaring and requesting this permission, your app can discover and connect to devices on the local area network (LAN), such as smart home devices or casting receivers.

Apps targeting Android 17 (API level 37) or higher now have two paths to maintain communication with LAN devices: Adopt system-mediated, privacy-preserving device pickers to skip the permission prompt, or explicitly request this new permission at runtime to maintain local network communication.

For more information, see the Local network permission documentation.

Masquage des mots de passe sur les appareils physiques

Si une application cible Android 17 (niveau d'API 37) ou une version ultérieure et que l'utilisateur utilise un périphérique d'entrée physique (par exemple, un clavier externe), le système d'exploitation Android applique le nouveau paramètre show_passwords_physical à tous les caractères du champ de mot de passe. Par défaut, ce paramètre masque tous les caractères du mot de passe.

Le système Android affiche le dernier caractère du mot de passe saisi pour aider l'utilisateur à voir s'il a fait une erreur de frappe. Toutefois, cela est beaucoup moins nécessaire avec les grands claviers externes. De plus, les appareils dotés de claviers externes ont souvent des écrans plus grands, ce qui augmente le risque que quelqu'un voie le mot de passe saisi.

Si l'utilisateur utilise l'écran tactile de l'appareil, le système applique le nouveau paramètre show_passwords_touch.

Protection OTP pour les messages SMS standards

从 Android 17 开始，Android 将扩展其短信验证码保护功能，以适用于标准短信（包含验证码但不使用 WebOTP 或 SMS Retriever 格式的短信）。对于以 Android 17（API 级别 37）或更高版本为目标平台的应用，这些短信在收到后三小时内不会提供。此延迟旨在帮助防止动态密码劫持。在这三小时的延迟期间，系统会保留 SMS_RECEIVED_ACTION广播，并过滤 短信提供商数据库查询。延迟结束后，这些应用即可使用短信。

某些应用（例如默认短信助理应用、已连接的设备配套应用等）不受此延迟限制。所有依赖于读取短信 来提取动态密码的应用都应改用 SMS Retriever 或 SMS User Consent API，以确保功能持续可用。

Sécurité

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

Sécurité des activités

在 Android 17 中，平台继续向“默认安全”架构转变，引入了一系列旨在缓解网络钓鱼、互动劫持和混淆代理攻击等高严重性漏洞的增强功能。此更新要求开发者明确选择启用新的安全标准，以保持应用兼容性和用户保护。

对开发者的主要影响包括：

  • BAL 安全加固和改进的选择启用： 我们正在优化后台活动启动 (BAL) 限制，方法是将保护范围扩展到 IntentSender。开发者必须从旧版 MODE_BACKGROUND_ACTIVITY_START_ALLOWED 常量迁移。相反，您应 采用精细控制，例如 MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE，它将 活动启动限制为调用应用可见的场景，从而显著 缩小攻击面。
  • 采用工具： 开发者应利用严格模式和更新后的 lint 检查来识别旧版模式，并确保为未来的目标 SDK 要求做好准备。

Activation de CT par défaut

Si une application cible Android 17 (niveau d'API 37) 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.)

DCL natif plus sûr : C

Si votre application cible Android 17 (niveau d'API 37) ou une version ultérieure, la protection du chargement dynamique du code (DCL) plus sécurisé 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.

Limitation des champs d'informations personnelles dans la vue de données CP2

For apps targeting Android 17 (API level Android 17 (API level 37)) and higher, Contacts Provider 2 (CP2) restricts certain columns containing Personally Identifiable Information (PII) from the data view. When this change is enabled, these columns are removed from the data view to enhance user privacy. The restricted columns include:

Apps that are using these columns from ContactsContract.Data can extract them from ContactsContract.RawContacts instead, by joining with RAW_CONTACT_ID.

Application de vérifications SQL strictes dans CP2

对于以 Android 17（API 级别 37）及更高版本为目标平台的应用，当在没有 READ_CONTACTS 权限的情况下访问 ContactsContract.Data 表时，联系人提供程序 2 (CP2) 会强制执行严格的 SQL 查询验证。

在此项更改生效后，如果应用没有 READ_CONTACTS 权限，则在查询 ContactsContract.Data 表时会设置 StrictColumns 和 StrictGrammar 选项。如果查询使用的模式与这些模式不兼容，则会被拒绝并导致抛出异常。

Contenus multimédias

Android 17 inclut les modifications suivantes concernant le comportement des contenus multimédias.

Renforcement de l'audio en arrière-plan

À partir d'Android 17, le framework audio applique des restrictions sur les interactions audio en arrière-plan, y compris la lecture audio, les requêtes de priorité audio et les API de modification du volume, afin de s'assurer que ces modifications sont lancées intentionnellement par l'utilisateur.

Certaines restrictions audio s'appliquent à toutes les applications. Toutefois, les restrictions sont plus strictes si une application cible Android 17 (niveau d'API 37). Si l'une de ces applications interagit avec l'audio en arrière-plan, elle doit exécuter un service de premier plan. De plus, l'application doit répondre à une ou aux deux exigences suivantes :

  • Le service de premier plan doit disposer de fonctionnalités "pendant l'utilisation" (WIU, while-in-use).
  • L'application doit disposer de l'autorisation Alarme exacte et interagir avec les flux audio USAGE_ALARM.

Pour en savoir plus, y compris sur les stratégies d'atténuation, consultez Renforcement de la sécurité de l'audio en arrière-plan.

Facteurs de forme d'appareil

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

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

Dans Android 16, nous avons apporté des modifications aux API de plate-forme pour ignorer les restrictions d'orientation, de format et de redimensionnement sur les grands écrans (sw >= 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 (niveau d'API 37) ou version ultérieure.

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

Connectivité

Android 17 introduit la modification suivante pour améliorer la cohérence et s'aligner sur le comportement standard InputStream Java pour les sockets RFCOMM Bluetooth.

Comportement cohérent de BluetoothSocket read() pour RFCOMM

Pour les applications ciblant Android 17 (niveau d'API 37), la read() méthode de l'InputStream obtenue à partir d'un BluetoothSocket basé sur RFCOMM renvoie désormais -1 lorsque le socket est fermé ou que la connexion est interrompue.

Cette modification rend le comportement du socket RFCOMM cohérent avec les sockets LE CoC et s'aligne sur la documentation standard InputStream.read(), qui indique que -1 est renvoyé lorsque la fin du flux est atteinte.

Les applications qui reposent uniquement sur l'interception d'une IOException pour sortir d'une boucle de lecture peuvent être affectées par cette modification et doivent mettre à jour les boucles de lecture BluetoothSocket pour vérifier explicitement une valeur de retour de -1. Cela garantit que la boucle se termine correctement lorsque l'appareil distant se déconnecte ou que le socket est fermé. Pour obtenir un exemple de l'implémentation recommandée, consultez l' extrait de code du guide Transférer des données Bluetooth.