Avec la sortie d'Android 16 en 2025, nous avons partagé notre vision d'un écosystème d'appareils où les applications s'adaptent de manière fluide à n'importe quel écran, qu'il s'agisse d'un téléphone, d'un appareil pliable, d'une tablette, d'un ordinateur, d'un écran de voiture ou d'un appareil XR. Les utilisateurs s'attendent à ce que leurs applications fonctionnent partout. Qu'ils effectuent plusieurs tâches à la fois sur une tablette, déplient un appareil pour lire confortablement ou exécutent des applications dans un environnement de fenêtres de bureau, les utilisateurs s'attendent à ce que l'UI remplisse l'espace d'affichage disponible et s'adapte à la position de l'appareil.

Nous avons apporté des modifications importantes aux API d'orientation et de redimensionnement pour faciliter le comportement adaptatif, tout en fournissant une option de désactivation temporaire pour vous aider à effectuer la transition. Nous avons déjà vu de nombreux développeurs s'adapter avec succès à cette transition lorsqu'ils ciblaient le niveau d'API 36.

Avec la sortie de la version bêta d'Android 17, nous passons à la phase suivante de notre feuille de route adaptative : Android 17 (niveau d'API 37) supprime la possibilité pour les développeurs de désactiver les restrictions d'orientation et de redimensionnement sur les appareils à grand écran (sw > 600 dp). Lorsque vous ciblez le niveau d'API 37, votre application doit être capable de s'adapter à différentes tailles d'écran.

Ces modifications de comportement permettent à l'écosystème Android d'offrir une expérience cohérente et de haute qualité sur tous les facteurs de forme des appareils.

Nouveautés d'Android 17

Les applications ciblant Android 17 doivent assurer leur compatibilité avec la suppression des attributs de fichier manifeste et des API d'exécution introduite dans Android 16. Nous comprenons que cette transition peut être importante pour certaines applications. C'est pourquoi nous avons inclus des bonnes pratiques et des outils pour vous aider à éviter les problèmes courants plus loin dans cet article de blog.

Aucune nouvelle modification n'a été introduite depuis Android 16, mais les développeurs ne peuvent plus désactiver cette fonctionnalité. Pour rappel, lorsque votre application s'exécute sur un grand écran (où grand écran signifie que la plus petite dimension de l'écran est supérieure ou égale à 600 dp), les attributs et API de fichier manifeste suivants sont ignorés :

Remarque  : Comme indiqué précédemment pour Android 16, ces modifications ne s'appliquent pas aux écrans dont la largeur est inférieure à 600 dp ni aux applications classées comme jeux en fonction du tag android:appCategory. 

De plus, les utilisateurs conservent le contrôle. Dans les paramètres de format, les utilisateurs peuvent explicitement choisir d'utiliser le comportement demandé par l'application.

Préparer votre application

Les applications devront prendre en charge les mises en page en mode Paysage et Portrait pour les tailles d'écran dans toute la gamme de formats que les utilisateurs peuvent choisir d'utiliser, y compris les fenêtres redimensionnables. En effet, il ne sera plus possible de limiter le format et l'orientation au mode Portrait ou Paysage.

Tester votre application

La première étape consiste à tester votre application avec ces modifications pour vous assurer qu'elle fonctionne correctement sur différentes tailles d'écran.

Utilisez Android 17 bêta 1 avec les émulateurs des séries Pixel Tablet et Pixel Fold dans Android Studio, et définissez targetSdkPreview = “CinnamonBun”. Vous pouvez également utiliser le framework de compatibilité des applications en activant l'indicateur UNIVERSAL_RESIZABLE_BY_DEFAULT si votre application ne cible pas encore le niveau d'API 36.

Nous disposons d'outils supplémentaires pour nous assurer que vos mises en page s'adaptent correctement. Vous pouvez auditer automatiquement votre UI et obtenir des suggestions pour la rendre plus adaptative avec Compose UI Check, et simuler des caractéristiques d'affichage spécifiques dans vos tests à l'aide de DeviceConfigurationOverride.

Pour les applications qui ont toujours limité l'orientation et le format, nous constatons souvent des problèmes d'aperçus de l'appareil photo inclinés ou mal orientés, de mises en page étirées, de boutons inaccessibles ou de perte de l'état de l'utilisateur lors de la gestion des changements de configuration. 

Examinons quelques stratégies pour résoudre ces problèmes courants.

Vérifier la compatibilité de la caméra

Un problème courant sur les appareils pliables en mode paysage ou pour les calculs de format dans des scénarios tels que le multifenêtre, le fenêtrage sur ordinateur ou les écrans connectés, se produit lorsque l'aperçu de la caméra apparaît étiré, pivoté ou recadré.

Assurez-vous que l'aperçu de votre caméra n'est pas étiré ni pivoté.

Ce problème se produit souvent sur les appareils à grand écran et pliables, car les applications supposent des relations fixes entre les fonctionnalités de l'appareil photo (comme le format et l'orientation du capteur) et les fonctionnalités de l'appareil (comme l'orientation de l'appareil et l'orientation naturelle).

Pour vous assurer que l'aperçu de votre caméra s'adapte correctement à n'importe quelle taille ou orientation de fenêtre, envisagez les quatre solutions suivantes :

Solution 1 : Jetpack CameraX (recommandée) 

La solution la plus simple et la plus robuste consiste à utiliser la bibliothèque Jetpack CameraX. Son élément d'UI PreviewView est conçu pour gérer automatiquement toutes les complexités de l'aperçu :

• PreviewView s'ajuste correctement à l'orientation du capteur, à la rotation de l'appareil et à la mise à l'échelle
• PreviewView conserve le format de l'image de la caméra, généralement en la centrant et en la recadrant (FILL_CENTER).
• Si nécessaire, vous pouvez définir le type d'échelle sur FIT_CENTER pour mettre l'aperçu au format Letterbox.

Pour en savoir plus, consultez Implémenter un aperçu dans la documentation CameraX.

Solution 2 : CameraViewfinder 

Si vous utilisez une codebase Camera2 existante, la bibliothèque CameraViewfinder (rétrocompatible avec le niveau d'API 21) est une autre solution moderne. Il simplifie l'affichage du flux de la caméra en utilisant un TextureView ou un SurfaceView et en appliquant toutes les transformations nécessaires (ratio d'aspect, échelle et rotation) pour vous.

Pour en savoir plus, consultez l'article de blog Introducing Camera Viewfinder (Présentation du viseur de l'appareil photo) et le guide du développeur Aperçu de l'appareil photo.

Solution 3 : Implémentation manuelle de Camera2 

Si vous ne pouvez pas utiliser CameraX ni CameraViewfinder, vous devez calculer manuellement l'orientation et le format, et vous assurer que les calculs sont mis à jour à chaque modification de la configuration :

• Obtenez l'orientation du capteur de caméras (par exemple, 0, 90, 180 ou 270 degrés) à partir de CameraCharacteristics.
• Obtenir la rotation actuelle de l'écran de l'appareil (par exemple, 0, 90, 180 ou 270 degrés)
• Utilisez les valeurs d'orientation du capteur de caméras et de rotation de l'écran pour déterminer les transformations nécessaires pour votre SurfaceView ou TextureView.
• Assurez-vous que le format de votre sortie Surface correspond à celui de l'aperçu de la caméra pour éviter toute distorsion.

Important : Notez que l'application de l'appareil photo peut s'exécuter sur une partie de l'écran, en mode multifenêtre ou en mode fenêtré pour ordinateur, ou sur un écran connecté. Pour cette raison, la taille de l'écran ne doit pas être utilisée pour déterminer les dimensions du viseur de l'appareil photo. Utilisez plutôt les métriques de fenêtre. Sinon, l'aperçu de la caméra risque d'être étiré.

Pour en savoir plus, consultez le guide du développeur Aperçu de l'appareil photo et la vidéo Votre application d'appareil photo sur différents facteurs de forme.

Solution 4 : Effectuer des actions de base sur l'appareil photo à l'aide d'un Intent 

Si vous n'avez pas besoin de nombreuses fonctionnalités de l'appareil photo, une solution simple et directe consiste à effectuer des actions de base sur l'appareil photo, comme prendre une photo ou enregistrer une vidéo à l'aide de l'application Appareil photo par défaut de l'appareil. Dans ce cas, vous pouvez simplement utiliser un Intent au lieu d'une bibliothèque d'appareil photo, pour faciliter la maintenance et l'adaptabilité. 

Pour en savoir plus, consultez Intents de l'appareil photo.

Éviter les interfaces utilisateur étirées ou les boutons inaccessibles

Si votre application suppose une orientation d'appareil ou un format d'écran spécifiques, elle peut rencontrer des problèmes lorsqu'elle est utilisée avec différentes orientations ou tailles de fenêtre.

Assurez-vous que les boutons, les champs de texte et les autres éléments ne sont pas étirés sur les grands écrans.

Vous avez peut-être défini des boutons, des champs de texte et des cartes sur fillMaxWidth ou match_parent.  Sur un téléphone, cela a l'air parfait. Toutefois, sur une tablette ou un appareil pliable en mode paysage, les éléments de l'UI s'étirent sur l'ensemble du grand écran. Dans Jetpack Compose, vous pouvez utiliser le modificateur widthIn pour définir une largeur maximale pour les composants afin d'éviter que le contenu ne soit étiré :

Box(
    contentAlignment = Alignment.Center,
    modifier = Modifier.fillMaxSize()
) {
    Column(
        modifier = Modifier
            .widthIn(max = 300.dp) // Prevents stretching beyond 300dp
            .fillMaxWidth()        // Fills width up to 300dp
            .padding(16.dp)
    ) {
        // Your content
    }
}

Si un utilisateur ouvre votre application en mode paysage sur un appareil pliable ou une tablette, les boutons d'action tels que Enregistrer ou Se connecter en bas de l'écran peuvent être affichés hors écran. Si le conteneur n'est pas défilable, l'utilisateur peut être empêché de continuer. Dans Jetpack Compose, vous pouvez ajouter un modificateur verticalScroll à votre composant :

Column(
    modifier = Modifier
        .fillMaxSize()
        .verticalScroll(rememberScrollState())
        .padding(16.dp)
)

En combinant des contraintes de largeur maximale avec le défilement vertical, vous vous assurez que votre application reste fonctionnelle et utilisable, quelle que soit la largeur ou la hauteur de la fenêtre de l'application.

Consultez notre guide sur la création de mises en page adaptatives.

Conserver l'état lors des modifications de configuration

Si vous supprimez les restrictions d'orientation et de format, la taille de la fenêtre de votre application changera beaucoup plus souvent. Les utilisateurs peuvent faire pivoter leur appareil, le plier/déplier ou redimensionner votre application de manière dynamique en mode Écran partagé ou Fenêtre de bureau.

Par défaut, ces modifications de configuration détruisent et recréent votre activité. Si votre application ne gère pas correctement cet événement de cycle de vie, les utilisateurs auront une expérience frustrante : les positions de défilement sont réinitialisées en haut de l'écran, les formulaires à moitié remplis sont effacés et l'historique de navigation est perdu. Pour garantir une expérience adaptative fluide, il est essentiel que votre application conserve son état lors de ces changements de configuration. Avec Jetpack Compose, vous pouvez désactiver la recréation et autoriser les changements de taille de fenêtre à recomposer votre UI pour refléter la nouvelle quantité d'espace disponible.

Consultez notre guide sur l'enregistrement de l'état de l'UI.

Cibler le niveau d'API 37 d'ici août 2027

Si votre application s'était précédemment désinscrite de ces modifications lorsqu'elle ciblait le niveau d'API 36, elle ne sera concernée par la suppression de la désinscription d'Android 17 qu'après avoir ciblé le niveau d'API 37. Pour vous aider à anticiper et à apporter les ajustements nécessaires à votre application, voici le calendrier d'entrée en vigueur de ces modifications :

• Android 17 : les modifications décrites ci-dessus constitueront l'expérience de base pour les appareils à grand écran (plus petite largeur d'écran > 600 dp) pour les applications ciblant le niveau d'API 37. Les développeurs ne pourront pas désactiver cette fonctionnalité.

Les délais pour cibler un niveau d'API spécifique dépendent de l'app store. Pour Google Play, les nouvelles applications et les mises à jour devront cibler le niveau d'API 37. Ce comportement deviendra obligatoire pour la distribution en août 2027.

Se préparer à Android 17

Consultez la page Modifications d'Android 17 pour connaître toutes les modifications ayant un impact sur les applications dans Android 17. Pour tester votre application, téléchargez la version bêta 1 d'Android 17 et mettez à jour targetSdkPreview = “CinnamonBun”, ou utilisez le framework de compatibilité des applications pour activer des modifications spécifiques.

L'avenir d'Android est adaptatif, et nous sommes là pour vous aider à y parvenir. Lorsque vous vous préparez pour Android 17, nous vous encourageons à consulter nos guides sur la création de mises en page adaptatives et nos consignes relatives à la qualité des applications sur grand écran. Ces ressources sont conçues pour vous aider à gérer plusieurs facteurs de forme et tailles de fenêtre en toute confiance.

N'attendez pas. Préparez-vous dès aujourd'hui à Android 17 !