Lors du lancement d'Android 16 en 2025, nous avons partagé notre vision d'un écosystème d'appareils dans lequel 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 de bureau, 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, qu'ils déplient un appareil pour lire confortablement ou qu'ils exécutent des applications dans un environnement de fenêtrage de bureau, les utilisateurs s'attendent à ce que l'interface utilisateur 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 offrant une option de désactivation temporaire pour vous aider à effectuer la transition. Nous avons déjà constaté que de nombreux développeurs s'étaient adaptés à cette transition en ciblant 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 l'option de désactivation pour les développeurs concernant les restrictions d'orientation et de redimensionnement sur les appareils à grand écran (largeur d'écran > 600 dp). Lorsque vous ciblez le niveau d'API 37, votre application doit être capable de s'adapter à différentes tailles d'écran.

Les modifications de comportement garantissent que l'écosystème Android offre une expérience cohérente et de haute qualité sur tous les facteurs de forme d'appareils.

Qu'est-ce qui change dans Android 17 ?

Les applications ciblant Android 17 doivent s'assurer de leur compatibilité avec la suppression progressive des attributs de fichier manifeste et des API d'exécution introduits 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 l'option de désactivation pour les développeurs n'est plus disponible. Pour rappel, lorsque votre application s'exécute sur un grand écran (c'est-à-dire lorsque la plus petite dimension de l'écran est supérieure ou égale à 600 dp), les attributs de fichier manifeste et les API suivants sont ignorés :

Remarque :  Comme mentionné précédemment avec 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 de l'indicateur android:appCategory. 

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

Préparer votre application

Les applications devront être compatibles avec les mises en page en mode paysage et portrait pour les tailles d'écran dans toute la gamme de formats dans lesquels les utilisateurs peuvent choisir d'utiliser des applications, 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 Pixel Tablet et Pixel Fold dans Android Studio, puis 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 interface utilisateur 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 historiquement limité l'orientation et le format, nous constatons souvent des problèmes avec des aperçus de l'appareil photo déformés ou mal orientés, des mises en page étirées, des boutons inaccessibles ou une perte d'état de l'utilisateur lors de la gestion des modifications de configuration. 

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

Assurer la compatibilité de l'appareil photo

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

Assurez-vous que l'aperçu de votre appareil photo 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 appareil photo 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'interface utilisateur 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 l'appareil photo, généralement en la centrant et en la recadrant (FILL_CENTER).
• Vous pouvez définir le type d'échelle sur FIT_CENTER pour mettre l'aperçu au format letterbox si nécessaire.

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

Solution 2 : CameraViewfinder 

Si vous utilisez une base de code Camera2 existante, la bibliothèque CameraViewfinder (rétrocompatible avec le niveau d'API 21) est une autre solution moderne. Elle simplifie l'affichage du flux de l'appareil photo en utilisant un TextureView ou un SurfaceView et en appliquant toutes les transformations nécessaires (format, échelle et rotation).

Pour en savoir plus, consultez l'article de blog 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 configuration :

• Obtenez l'orientation du capteur de l'appareil photo (par exemple, 0, 90, 180, 270 degrés) à partir de CameraCharacteristics.
• Obtenez la rotation actuelle de l'écran de l'appareil (par exemple, 0, 90, 180, 270 degrés).
• Utilisez les valeurs d'orientation du capteur de l'appareil photo 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 Surface de sortie correspond à celui de l'aperçu de l'appareil photo pour éviter toute distorsion.

Important : Notez que l'application Appareil photo peut s'exécuter dans une partie de l'écran, en mode multifenêtre ou en mode fenêtrage de bureau, 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 la fenêtre. Sinon, vous risquez d'obtenir un aperçu de l'appareil photo étiré.

Pour en savoir plus, consultez le guide du développeur Aperçu de l'appareil photo et la vidéo Votre application 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'effectuer une intégration avec une bibliothèque d'appareils 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écifique, 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 les boutons, les champs de texte et les cartes sur fillMaxWidth ou match_parent. Sur un téléphone, cela fonctionne très bien. Toutefois, sur une tablette ou un appareil pliable en mode paysage, les éléments d'interface utilisateur s'étirent sur tout le 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 en dehors de l'écran. Si le conteneur n'est pas déroulant, l'utilisateur peut être bloqué. 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

La suppression des restrictions d'orientation et de format signifie que la taille de la fenêtre de votre application changera beaucoup plus fréquemment. Les utilisateurs peuvent faire pivoter leur appareil, le plier/le déplier ou redimensionner votre application de manière dynamique en mode Écran partagé ou en mode fenêtrage 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, 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 l'état lors de ces modifications de configuration. Avec Jetpack Compose, vous pouvez désactiver la recréation et autoriser les modifications de la taille de la fenêtre à recomposer votre interface utilisateur pour refléter la nouvelle quantité d'espace disponible.

Consultez notre guide sur l'enregistrement de l'état de l'interface utilisateur.

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

Si votre application avait précédemment désactivé ces modifications lors du ciblage du niveau d'API 36, elle ne sera affectée par la suppression de la désactivation d'Android 17 qu'après avoir ciblé le niveau d'API 37. Pour vous aider à planifier 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 seront l'expérience de base pour les appareils à grand écran (largeur d'écran minimale > 600 dp) pour les applications qui ciblent le niveau d'API 37. Les développeurs n'auront pas la possibilité de se désactiver.

Les délais pour cibler un niveau d'API spécifique sont propres à chaque plate-forme de téléchargement d'applications. Pour Google Play, les nouvelles applications et mises à jour devront cibler le niveau d'API 37, ce qui rendra ce comportement obligatoire pour la distribution en août 2027.

Préparer Android 17

Consultez la page des modifications d'Android 17 pour connaître toutes les modifications qui affectent les applications dans Android 17. Pour tester votre application, téléchargez Android 17 bêta 1 et passez à 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 à Android 17, nous vous encourageons à consulter nos guides sur la création de mises en page adaptatives et nos consignes relatives à la qualité des grands écrans. 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. Commencez dès aujourd'hui à vous préparer à Android 17.