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
Beginning with Android 17, apps targeting Android 17 (API level 37)
or higher receive a new lock-free implementation of
android.os.MessageQueue. The new implementation improves performance and
reduces missed frames, but may break clients that reflect on MessageQueue
private fields and methods.
For more information, including mitigation strategies, see MessageQueue behavior change guidance.
Les champs statiques finals ne sont plus modifiables
Apps running on Android 17 or higher that target
Android 17 (API level 37) or higher cannot change static final fields. If
an app attempts to change a static final field by using reflection, it will
cause an IllegalAccessException. Attempting to modify one of these fields
through JNI APIs (such as SetStaticLongField()) will cause the app to crash.
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
InputConnectionpersonnalisé peuvent récupérer les données de sélection des candidats en appelantTextAttribute.isTextSuggestionSelected(). Ces applications doivent ensuite appelerAccessibilityEvent.setTextChangeTypes()lors de la distribution d'événementsTYPE_VIEW_TEXT_CHANGED. Cette fonctionnalité est activée par défaut pour les applications ciblant Android 17 (niveau d'API 37) qui utilisent leTextViewstandard. (Autrement dit,TextViewgè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_CHANGEDpeuvent appelerAccessibilityEvent.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
À 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é des activités
Dans Android 17, la plate-forme poursuit sa transition vers une architecture "sécurisée par défaut", en introduisant une série d'améliorations conçues pour atténuer les failles de sécurité de haute gravité telles que le hameçonnage, le détournement d'interaction et les attaques par délégation confuse. Cette mise à jour exige des développeurs qu'ils activent explicitement les nouvelles normes de sécurité pour maintenir la compatibilité des applications et la protection des utilisateurs.
Voici les principaux impacts pour les développeurs :
- Renforcement de BAL et amélioration de l'activation : nous affinons les restrictions concernant le lancement d'activités en arrière-plan (BAL, Background Activity Launch) en étendant les protections à
IntentSender. Les développeurs doivent migrer depuis la constanteMODE_BACKGROUND_ACTIVITY_START_ALLOWEDhéritée. À la place, vous devez adopter des contrôles précis commeMODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, qui limite les démarrages d'activité aux scénarios où l'application appelante est visible, ce qui réduit considérablement la surface d'attaque. - Outils d'adoption : les développeurs doivent utiliser le mode strict et les vérifications lint mises à jour pour identifier les anciens modèles et s'assurer d'être prêts pour les futures exigences du SDK cible.
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
If your app targets Android 17 (API level 37) or higher, the Safer Dynamic Code Loading (DCL) protection introduced in Android 14 for DEX and JAR files now extends to native libraries.
All native files loaded using System.load() must be marked as read-only.
Otherwise, the system throws UnsatisfiedLinkError.
We recommend that apps avoid dynamically loading code whenever possible, as doing so greatly increases the risk that an app can be compromised by code injection or code tampering.
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
Pour les applications ciblant Android 17 (niveau d'API 37) ou version ultérieure, Contacts Provider 2 (CP2) applique une validation stricte des requêtes SQL lorsque la table ContactsContract.Data est consultée sans l'autorisation READ_CONTACTS.
Avec ce changement, si une application ne dispose pas de l'autorisation READ_CONTACTS, les options StrictColumns et StrictGrammar sont définies lors de l'interrogation de la table ContactsContract.Data. Si une requête utilise un modèle qui n'est pas compatible avec ceux-ci, elle sera refusée et une exception sera générée.
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)
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 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.