Le changement important concerne le format, pas une promesse de compatibilité universelle

Le Galaxy Z Fold8 a été présenté le 22 juillet 2026. Dans son guide à destination des développeurs, publié le même jour, Google met en avant une caractéristique qui a un effet direct sur les logiciels : le téléphone introduit un écran principal ultra-large dont l’orientation naturelle est le paysage. Il ne s’agit pas d’ajouter une version spéciale pour un modèle précis, mais d’abandonner les hypothèses rigides concernant l’orientation et les proportions. Les développeurs sont ainsi invités à réfléchir au comportement d’une application lorsque la configuration de l’écran varie, au lieu de prendre une disposition habituelle en portrait comme unique point de départ. (Android Developers Blog)

Samsung décrit le Fold8 comme doté d’un écran principal au format 4:3, qui peut être tourné pour la lecture, et d’un écran externe au format 10:16. Une même application doit donc composer avec deux contextes distincts : une surface extérieure étroite et une surface intérieure plus large. Les informations disponibles permettent de parler d’un nouveau défi de conception ; elles ne démontrent pas, à elles seules, que toutes les applications fonctionneront mal ni que chacune nécessite une reconstruction complète. La question pratique est de savoir comment une interface existante réagit lorsque l’utilisateur passe d’une surface à l’autre, et si son contenu ainsi que ses commandes s’adaptent à l’espace réellement disponible. Les proportions expliquent l’importance de plusieurs mises en page, mais ne prouvent pas l’existence d’un problème universel de compatibilité. (Samsung Newsroom)

Il faut d’abord concevoir l’interface pour l’espace disponible dans l’application

Google conseille de faire répondre l’interface en priorité à la largeur disponible, puis de tenir compte de la hauteur. Dans une fenêtre large, il peut être pertinent d’afficher davantage de colonnes, de panneaux ou de contenu à la fois ; lorsque l’espace se réduit, ces éléments peuvent être réorganisés, redimensionnés ou présentés autrement. L’essentiel est que la mise en page puisse se redistribuer, au lieu de dépendre de coordonnées ou de dimensions fixes. Cela ne signifie pas que chaque écran doit toujours afficher la même quantité d’informations. L’organisation peut changer de façon réfléchie lorsque la fenêtre de l’application évolue, afin que les commandes et le contenu restent utilisables au lieu d’être simplement comprimés dans une disposition conçue pour une autre forme d’écran. (Android Developers Blog)

Il importe aussi de distinguer la taille physique de l’écran de l’espace occupé par la fenêtre de l’application. En écran partagé ou dans d’autres modes multitâches, une application peut ne disposer que d’une partie de la surface, et sa fenêtre peut même avoir une orientation différente de celle de l’appareil. Google cite Window Size Classes et Jetpack WindowManager comme outils permettant d’identifier cet espace réel et les caractéristiques de la fenêtre. L’interface peut ainsi répondre aux conditions effectives plutôt qu’à une supposition fondée sur la taille totale du téléphone. Cette distinction compte pour l’utilisateur : un grand écran ne signifie pas que chaque application dispose toujours de toute sa surface. La taille de la fenêtre, son orientation et la manière dont l’utilisateur organise ses applications déterminent l’espace dans lequel l’interface doit fonctionner. (Android Developers Blog)

Pliures, changements de posture et continuité

Sur un appareil pliable, le passage de l’état fermé à l’état ouvert modifie la configuration reçue par l’application. Les recommandations adaptatives d’Android demandent de tenir compte de ces états, mais aussi des orientations portrait et paysage, du mode multifenêtre et des préférences de l’utilisateur. Pour les interfaces qui traversent la zone de la charnière, Jetpack WindowManager fournit des informations sur les plis et les charnières : une application peut éviter d’y placer du contenu important ou utiliser cette zone comme séparation entre des panneaux. La charnière devient ainsi un élément à prendre en compte dans la mise en page, et non un simple détail matériel. Le choix dépend de l’interface : il peut être préférable d’éloigner le contenu de la pliure ou de placer des parties distinctes de l’application de chaque côté lorsque cela est pertinent. (Android Developers)

Google recommande également de conserver l’état de l’interface pendant ces changements, par exemple avec ViewModel, afin que l’utilisateur ne perde pas le fil lorsqu’il plie ou déplie l’appareil. Il s’agit d’une consigne de développement, et non d’une description de ce que ferait automatiquement n’importe quelle application installée. En pratique, lorsque la configuration de l’écran change, la tâche en cours, la sélection ou la position de lecture devrait être conservée si l’application le permet. La qualité de cette continuité dépend de la manière dont chaque application est conçue. Un appareil pliable peut modifier la disposition disponible sans que l’utilisateur souhaite recommencer ; une application bien préparée doit donc déterminer quelles informations doivent survivre à cette transition. Cette recommandation ne signifie pas que toutes les applications préservent déjà leur état, ni que la plateforme peut fournir à leur place une continuité qui n’a pas été programmée. (Android Developers Blog)

Android 17 supprime une dérogation pour les applications grand écran, mais ne redessine pas leurs interfaces

Android 17 apporte un changement important pour les applications ciblant le niveau d’API 37 : l’option permettant de se soustraire aux règles Android qui ignorent les restrictions d’orientation, de format et de redimensionnement sur les grands écrans d’au moins 600 dp de largeur n’est plus disponible. Google explique que ces règles avaient déjà été introduites dans Android 16 pour les applications ciblant le niveau d’API 36 ou supérieur. Le changement concerne la manière dont une application réagit à la taille et à l’orientation de la fenêtre ; il ne crée pas à lui seul une interface adaptative. Autrement dit, le système peut ne plus appliquer certaines restrictions de la même façon pour les applications concernées, mais ce comportement reste distinct du travail nécessaire pour organiser correctement leur contenu. (Android Developers)

Il est donc utile de séparer la règle du système du travail de conception. Android peut autoriser le redimensionnement d’une application ou son affichage dans une orientation différente de celle qu’elle imposait auparavant, mais il ne réorganise pas comme par magie ses boutons, listes ou panneaux pour les rendre agréables à utiliser. La documentation de Google présente, comme mesure temporaire, une stratégie qui restreint le mode portrait sur les écrans compacts et autorise l’orientation choisie par l’utilisateur sur les écrans de 600 dp ou plus. Le guide la présente comme une étape limitée, et non comme un substitut à une prise en charge complète. Les développeurs doivent toujours examiner l’apparence et le fonctionnement de l’interface dans les configurations autorisées par le système. Un changement de comportement de la plateforme peut révéler les faiblesses d’une mise en page, mais ne constitue pas une refonte automatique ni la garantie que chaque commande sera bien placée. (Android Developers)

Appareil photo : un autre test d’adaptation, distinct de l’interface générale

Le guide de Google traite séparément la capture avec l’appareil photo. Lorsqu’on passe d’un écran externe compact à un écran interne plus grand, les proportions de la zone d’aperçu changent, même si l’orientation de l’appareil ne change pas nécessairement. Une implémentation qui suppose un rapport fixe entre le capteur et l’écran risque d’afficher un aperçu pivoté, déformé ou recadré. Google recommande CameraX pour les nouvelles implémentations et cite PreviewView comme aide à la gestion de l’orientation du capteur, de la rotation et de la mise à l’échelle. Cet exemple montre pourquoi vérifier l’interface générale ne suffit pas toujours : l’aperçu de la caméra a sa propre géométrie et doit s’adapter à la surface sur laquelle il est affiché. (Android Developers Blog)

Pour les projets existants qui utilisent Camera2, la même publication mentionne CameraViewfinder comme solution permettant d’appliquer des transformations de proportions et de rotation sans reconstruire toute l’architecture. Ces recommandations s’adressent aux personnes qui développent ou maintiennent les applications ; elles ne signifient pas que le système peut corriger tous les problèmes logiciels d’appareils photo tiers. Pour évaluer une application photo sur un pliable, il est donc utile d’observer le cadrage et la transition entre les écrans, plutôt que de déduire une compatibilité complète du simple fait que l’application s’ouvre. Le lancement n’est qu’un signe visible parmi d’autres. L’aperçu peut toujours mal réagir au changement d’espace disponible, et les outils cités sont des recommandations de développement, pas la promesse qu’une application les utilise déjà. (Android Developers Blog)

Ce que l’utilisateur peut vérifier, et les limites de ces vérifications

Pour l’utilisateur, un test utile consiste à ouvrir une application sur l’écran externe, à déplier le téléphone, à le faire pivoter et, si l’application le permet, à essayer l’écran partagé. Il faut observer si le contenu se redistribue, si des barres ou des zones vides apparaissent, si les commandes restent accessibles et si la tâche se poursuit après le changement. Dans les applications de lecture, de vidéo ou d’appareil photo, il importe également de vérifier que le format du contenu et l’aperçu ne sont pas recadrés de façon inattendue. Ce sont des signes observables, pas une certification technique ni le résultat de tests réalisés pour cet article. Essayer plusieurs configurations peut montrer le comportement habituel d’une application, mais ne prouve pas qu’elle prend en charge toutes les tailles de fenêtre ou toutes les postures possibles. L’intérêt du test est précisément de se concentrer sur ce qui est visible sans prétendre aller au-delà.

L’annonce de Google fournit des recommandations aux développeurs et des outils de plateforme ; elle ne publie pas d’audit de compatibilité pour des applications précises. Elle ne permet pas non plus de conclure que le Galaxy Z Fold8 oblige à redessiner chaque application, ni qu’Android 17 garantit une expérience optimale pour toutes. Le constat vérifiable est plus limité : les formats orientés paysage et les fenêtres variables rendent plus important l’adaptation de l’interface à l’espace disponible, et Android 17 limite une dérogation liée à l’orientation pour les applications ciblant l’API 37 ou une version ultérieure. La différence entre accepter une configuration et concevoir une interface qui y fonctionne bien continuera de dépendre de chaque développeur. L’utilisateur peut observer cette différence, mais les recommandations ne certifient le comportement d’aucune application en particulier. (Android Developers Blog)