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 (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 finaux statiques 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 complexe au clavier physique avec un IME

This feature introduces new AccessibilityEvent and TextAttribute APIs to enhance screen reader spoken feedback for CJKV language input. CJKV IME apps can now signal whether a text conversion candidate has been selected during text composition. Apps with edit fields can specify text change types when sending text changed accessibility events. For example, apps can specify that a text change occurred during text composition, or that a text change resulted from a commit. Doing this enables accessibility services such as screen readers to deliver more precise feedback based on the nature of the text modification.

App adoption

  • IME Apps: When setting composing text in edit fields, IMEs can use TextAttribute.Builder.setTextSuggestionSelected() to indicate whether a specific conversion candidate was selected.

  • Apps with Edit Fields: Apps that maintain a custom InputConnection can retrieve candidate selection data by calling TextAttribute.isTextSuggestionSelected(). These apps should then call AccessibilityEvent.setTextChangeTypes() when dispatching TYPE_VIEW_TEXT_CHANGED events. Apps targeting Android 17 (API level 37) that use the standard TextView will have this feature enabled by default. (That is, TextView will handle retrieving data from the IME and setting text change types when sending events to accessibility services).

  • Accessibility Services: Accessibility services that process TYPE_VIEW_TEXT_CHANGED events can call AccessibilityEvent.getTextChangeTypes() to identify the nature of the modification and adjust their feedback strategies accordingly.

Confidentialité

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

ECH (Encrypted Client Hello) activé

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 d'accès au 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.

Masquer les 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 par code secret à usage unique pour les SMS standards

À partir d'Android 17, Android étend sa protection des OTP par SMS aux messages SMS standards (messages SMS contenant un OTP qui n'utilisent pas les formats WebOTP ni SMS Retriever). Pour la plupart des applications ciblant Android 17 (niveau d'API 37) ou une version ultérieure, ces messages SMS ne sont disponibles que trois heures après leur réception. Ce délai vise à empêcher le piratage des OTP. Pendant ce délai de trois heures, la SMS_RECEIVED_ACTION diffusion est bloquée et les requêtes de base de données du fournisseur de SMS sont filtrées. Le message SMS est disponible pour ces applications après le délai.

Certaines applications, telles que l'application d'assistance SMS par défaut, les applications associées aux appareils connectés, etc., sont exemptées de ce délai. Toutes les applications qui s'appuient sur la lecture de messages SMS pour l'extraction d'OTP doivent passer à l'utilisation des API SMS Retriever ou SMS User Consent pour garantir la continuité de leur fonctionnement.

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.

Activer la CT par défaut

If an app targets Android 17 (API level 37) or higher, certificate transparency (CT) is enabled by default. (On Android 16, CT is available but apps had to opt in.)

Safer Native DCL-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.

Restreindre les champs d'informations permettant d'identifier personnellement l'utilisateur 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.

Appliquer des vérifications SQL strictes dans CP2

For apps targeting Android 17 (API level Android 17 (API level 37)) and higher, Contacts Provider 2 (CP2) enforces strict SQL query validation when the ContactsContract.Data table is accessed without READ_CONTACTS permission.

With this change, if an app doesn't have READ_CONTACTS permission, StrictColumns and StrictGrammar options are set when querying the ContactsContract.Data table. If a query uses a pattern that isn't compatible with these, it will be rejected and cause an exception to be thrown.

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 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)

We introduced Platform API changes in Android 16 to ignore orientation, aspect ratio, and resizability restrictions on large screens (sw >= 600dp) for apps targeting API level 36 or higher. Developers have the option to opt out of these changes with SDK 36, but this opt-out will no longer be available for apps that target Android 17 (API level 37) or higher.

For more information, see Restrictions on orientation and resizability are ignored.

Connectivité

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

Comportement cohérent de BluetoothSocket read() pour RFCOMM

For apps targeting Android 17 (API level 37), the read() method of the InputStream obtained from an RFCOMM-based BluetoothSocket now returns -1 when the socket is closed or the connection is dropped.

This change makes RFCOMM socket behavior consistent with LE CoC sockets and aligns with the standard InputStream.read() documentation, which states that -1 is returned when the end of the stream is reached.

Apps that rely solely on catching an IOException to break out of a read loop may be impacted by this change and should update the BluetoothSocket read loops to explicitly check for a return value of -1. This ensures the loop terminates correctly when the remote device disconnects or the socket is closed. For an example of the recommended implementation, see the code snippet in the Transfer Bluetooth data guide.