L’échéance de Google Play ne signifie pas ce qu’elle semble signifier

Le 31 août 2026 est passé : depuis cette date, les nouvelles apps et les mises à jour envoyées à Google Play doivent cibler Android 16, niveau d’API 36, ou une version ultérieure. La règle est différente pour les apps existantes : pour rester disponibles auprès de nouveaux utilisateurs sur des appareils exécutant des versions récentes d’Android, elles doivent cibler au minimum Android 15, API 35. Affirmer que toutes les apps existantes doivent cibler l’API 36 est donc une simplification inexacte de la politique. Google indique qu’une prolongation peut être demandée, jusqu’au 1er novembre 2026, pour certaines exigences. (support.google.com)

Cibler une API est une déclaration technique de compatibilité adressée à Android ; cela ne certifie pas que l’interface a été bien conçue pour chaque taille d’écran. La politique de Play porte sur le niveau d’API exigé pour publier ou distribuer une app. L’adaptation visuelle dépend d’autres aspects : la manière dont l’app répond à l’espace disponible, aux changements d’orientation et à la configuration des fenêtres. Il est utile de distinguer ces deux sujets avant de conclure que la nouvelle exigence de Play garantit une meilleure expérience sur un appareil pliable. (support.google.com)

Ce qu’Android 16 modifie sur un grand écran

Dans Android 16, pour les apps ciblant l’API 36, le système peut cesser de respecter certaines demandes d’orientation fixe, de format d’image maximal ou minimal, ainsi que des restrictions de redimensionnement, lorsqu’une fenêtre a une largeur minimale d’au moins 600 dp. Le mode multifenêtre est également autorisé dans ce contexte. La documentation mentionne les tablettes, les grands écrans intérieurs des appareils pliables et le mode fenêtré de bureau ; elle ne décrit pas un changement qui s’appliquerait de la même manière à tous les écrans ou à toutes les positions du téléphone. (developer.android.com)

Concrètement, une app auparavant confinée à un rectangle vertical ou entourée de bandes pourrait occuper davantage d’espace et être disponible dans d’autres orientations ou tailles de fenêtre. Cela ne signifie pas nécessairement que son interface a été repensée : le système peut lui accorder plus de place, mais c’est à l’app de bien y répartir ses éléments. Le changement peut donc rendre plus visible une interface qui ne s’adapte pas, plutôt que la corriger automatiquement. Google signale des problèmes possibles, comme des composants étirés ou qui se chevauchent, si la conception n’a pas été préparée pour ces nouvelles dimensions. (developer.android.com)

Le seuil de 600 dp et les exceptions

Cette limite est particulièrement importante pour les appareils pliables. La règle d’Android 16 dépend de la largeur minimale de l’écran ou de la fenêtre, et non simplement de la présence d’une charnière. Google indique que les écrans de moins de 600 dp font exception ; cette catégorie comprend la plupart des téléphones ainsi que les écrans externes des grands appareils pliables. Une même app peut donc se comporter différemment sur l’écran extérieur et l’écran intérieur, selon leurs dimensions et les conditions d’utilisation. (developer.android.com)

La documentation exclut aussi les jeux identifiés par la catégorie correspondante et prévoit que l’utilisateur puisse activer le comportement par défaut de l’app dans les paramètres de format d’image. Avec l’API 36, les développeurs peuvent en outre déclarer une propriété de compatibilité afin d’exclure de ce comportement une activité précise ou toute l’application. Cela ne permet pas de conserver toutes les restrictions à l’identique : Google précise que, pour les apps ciblant l’API 36 ou une version ultérieure, cette propriété ne verrouille pas l’orientation et n’empêche pas la rotation sur les grands écrans. La documentation indique que cette possibilité d’exclusion sera supprimée avec l’API 37. (developer.android.com)

Ce que les utilisateurs d’un appareil pliable peuvent remarquer

En dépliant leur téléphone, les utilisateurs pourraient voir une app en plein écran au lieu de la retrouver dans une colonne étroite, ou la voir s’ajuster lorsqu’ils changent l’orientation ou la taille de la fenêtre. Ils pourraient aussi l’utiliser en mode multifenêtre si le système et l’app le permettent dans ce contexte. Ce sont des possibilités découlant du comportement décrit par Android, et non la promesse que chaque app affichera davantage de contenu ou proposera de nouvelles commandes. La documentation ne permet pas de prévoir le résultat pour une app donnée sans connaître son implémentation et la tester sur l’appareil concerné. (developer.android.com)

Si un écran semble étiré, qu’une commande devient inaccessible ou que l’aperçu de la caméra apparaît mal orienté, cela peut indiquer que l’interface répond mal à cette configuration. Android recommande de vérifier que les écrans peuvent défiler, de limiter la largeur des composants qui seraient déformés en s’agrandissant et de valider les vues de caméra en orientations portrait et paysage. Il s’agit de recommandations de développement, pas de réglages que l’utilisateur peut appliquer pour corriger lui-même le code d’une app. (developer.android.com)

Les vérifications à effectuer par les développeurs

S’adapter consiste à répondre à l’espace réellement disponible, et pas simplement à faire pivoter une composition conçue pour un téléphone en mode portrait. Android recommande d’utiliser les classes de taille de fenêtre et des mises en page adaptatives pour choisir une organisation correspondant aux dimensions. Dans une app de lecture, par exemple, l’équipe peut choisir d’afficher davantage de contenu ou plusieurs panneaux ; pour d’autres interfaces, il peut être préférable de conserver une colonne lisible avec une largeur maximale. L’objectif est d’éviter qu’une fenêtre plus large ne se traduise simplement par des commandes démesurées ou une disposition difficile à utiliser. (developer.android.com)

Il faut également préserver l’état de l’app lorsque la configuration change. Faire pivoter, plier ou déplier l’appareil, ou modifier la taille d’une fenêtre, peut amener Android à recréer une activité. Le guide conseille de préserver des données comme le texte saisi dans un formulaire, afin que la personne ne perde ni son travail ni le contexte de navigation. C’est pourquoi une simple capture statique de l’écran intérieur ne suffit pas : il est utile de parcourir des actions réelles et les transitions entre tailles, positions et fenêtres. (developer.android.com)

Pour vérifier une app précise, son équipe peut la tester dans des émulateurs grand écran et pliables et utiliser les outils de compatibilité documentés par Android. Les utilisateurs peuvent mettre Android et l’app à jour, tester les écrans extérieur et intérieur et signaler des problèmes précis au développeur, mais la fiche Play ne permet pas, à elle seule, de savoir si la conception s’est correctement adaptée. La conclusion pratique est plus limitée que ne le laisse penser un titre sur une politique : l’API 36 permet à Android d’imposer moins de restrictions héritées dans certains contextes grand écran ; la qualité de l’expérience dépend toujours de l’implémentation, de la taille effective de la fenêtre et des exceptions actives. (developer.android.com)