La compatibilité avec différentes tailles d'écran permet à un plus grand nombre d'utilisateurs et à des appareils très divers d'accéder à votre application.
Pour accepter un maximum de tailles d'écran, concevez vos mises en page d'application de sorte qu'elles soient responsives et adaptatives. Les mises en page responsives et adaptatives offrent une expérience utilisateur optimisée, quelle que soit la taille de l'écran. Elles permettent ainsi à votre application de s'adapter aux téléphones, tablettes, appareils pliables et aux appareils ChromeOS, ainsi qu'aux orientations portrait et paysage, et aux configurations redimensionnables comme le mode multifenêtre.
Classes de taille de fenêtre
Les classes de taille de fenêtre sont un ensemble de points d'arrêt de fenêtre d'affichage définis qui permettent de concevoir, de développer et de tester des mises en page d'applications responsives et adaptatives. Les points d'arrêt ont été choisis spécifiquement pour équilibrer la simplicité de la mise en page et la flexibilité qui permet d'optimiser votre application dans des cas spécifiques.
Les classes de taille de fenêtre distinguent la zone d'affichage disponible sur votre application en trois catégories : Compacte, Moyenne ou Étendue. La largeur et la hauteur disponibles sont évaluées séparément. Votre application peut donc être associée à deux classes de taille de fenêtre : une pour la largeur et une pour la hauteur. La largeur disponible est généralement plus importante que la hauteur disponible en raison de l'omniprésence du défilement vertical. La classe de largeur de fenêtre sera donc probablement plus adaptée à l'interface utilisateur de votre application.
Comme illustré ci-dessus, les points d'arrêt vous permettent de continuer à réfléchir aux mises en page selon les appareils et les configurations. Chaque point d'arrêt de classe de taille représente un cas majoritaire pour des scénarios courants d'appareil. Il peut être un cadre de référence utile pour réfléchir à la conception de vos mises en page basées sur des points d'arrêt.
| Classe de taille | Point d'arrêt | Représentation de l'appareil |
|---|---|---|
| Largeur compacte | largeur < 600 dp | 99,96 % des téléphones en mode portrait |
| Largeur moyenne | 600 dp ≤ largeur < 840 dp | 93,73 % des tablettes en mode portrait
Grands écrans internes dépliés en mode portrait |
| Largeur étendue | largeur ≥ 840 dp | 97,22 % des tablettes en mode paysage
Grands écrans internes dépliés en mode paysage |
| Hauteur compacte | hauteur < 480 dp | 99,78 % des téléphones en mode paysage |
| Hauteur moyenne | 480 dp ≤ hauteur < 900 dp | 96,56 % des tablettes en mode paysage
97,59 % des téléphones en mode portrait |
| Hauteur étendue | hauteur ≥ 900 dp | 94,25 % des tablettes en mode portrait |
Bien qu'il puisse être utile de visualiser les classes de taille en tant qu'appareils physiques, les classes de taille de fenêtre ne sont pas déterminées explicitement par la taille de l'écran de l'appareil. Les classes de taille de fenêtre ne sont pas conçues dans une logique de type isTablet. Les classes de taille de fenêtre sont déterminées par la taille de la fenêtre disponible pour votre application, quel que soit le type d'appareil sur lequel elle s'exécute, ce qui a deux conséquences importantes :
Les appareils physiques ne garantissent pas l'utilisation d'une classe de taille de fenêtre spécifique. L'espace disponible sur votre application peut différer de la taille d'écran de l'appareil pour de nombreuses raisons. Sur les appareils mobiles, le mode Écran partagé peut diviser l'écran entre deux applications. Sous ChromeOS, les applications Android peuvent être présentées dans des fenêtres de format libre qui sont arbitrairement redimensionnables. Les appareils pliables sont équipés de deux écrans de différentes tailles auxquels il est possible d'accéder individuellement en pliant ou en dépliant l'appareil.
La classe de taille de fenêtre peut changer tout au long de la durée de vie de votre application. Lorsqu'elle est en cours d'exécution, les changements d'orientation de l'appareil, le mode multitâche et le pliage/dépliage peuvent modifier la quantité d'espace disponible sur l'écran. La classe de taille de fenêtre est donc dynamique, et l'interface utilisateur de votre application doit s'adapter en conséquence.
Les classes de taille de fenêtre sont mappées aux points d'arrêt de mise en page dans la grille de mise en page responsive de Material Design. Utilisez les classes de taille de fenêtre pour prendre des décisions concernant la mise en page des applications de haut niveau, par exemple pour décider d'utiliser une mise en page standard spécifique afin de disposer de plus d'espace à l'écran.
Les applications basées sur les vues doivent calculer la classe de taille de fenêtre en fonction des métriques de fenêtre actuelles fournies par la bibliothèque WindowManager de Jetpack. L'exemple de code ci-dessous dans Vues Kotlin et Vues Java illustre comment calculer la classe de taille de fenêtre en fonction des points d'arrêt et recevoir des mises à jour chaque fois qu'elle change.
Les applications basées sur Compose doivent utiliser la bibliothèque material3-window-size-class pour calculer un WindowSizeClass en fonction des métriques de fenêtre actuelles avec calculateWindowSizeClass().
Vues
enum class WindowSizeClass { COMPACT, MEDIUM, EXPANDED }
class MainActivity : Activity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// ...
// Replace with a known container that you can safely add a
// view to where the view won't affect the layout and the view
// won't be replaced.
val container: ViewGroup = binding.container
// Add a utility view to the container to hook into
// View.onConfigurationChanged. This is required for all
// activities, even those that don't handle configuration
// changes. You can't use Activity.onConfigurationChanged,
// since there are situations where that won't be called when
// the configuration changes. View.onConfigurationChanged is
// called in those scenarios.
container.addView(object : View(this) {
override fun onConfigurationChanged(newConfig: Configuration?) {
super.onConfigurationChanged(newConfig)
computeWindowSizeClasses()
}
})
computeWindowSizeClasses()
}
private fun computeWindowSizeClasses() {
val metrics = WindowMetricsCalculator.getOrCreate()
.computeCurrentWindowMetrics(this)
val widthDp = metrics.bounds.width() /
resources.displayMetrics.density
val widthWindowSizeClass = when {
widthDp < 600f -> WindowSizeClass.COMPACT
widthDp < 840f -> WindowSizeClass.MEDIUM
else -> WindowSizeClass.EXPANDED
}
val heightDp = metrics.bounds.height() /
resources.displayMetrics.density
val heightWindowSizeClass = when {
heightDp < 480f -> WindowSizeClass.COMPACT
heightDp < 900f -> WindowSizeClass.MEDIUM
else -> WindowSizeClass.EXPANDED
}
// Use widthWindowSizeClass and heightWindowSizeClass.
}
}
Vues
public enum WindowSizeClass { COMPACT, MEDIUM, EXPANDED }
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// ...
// Replace with a known container that you can safely add a
// view to where the view won't affect the layout and the view
// won't be replaced.
ViewGroup container = binding.container;
// Add a utility view to the container to hook into
// View.onConfigurationChanged. This is required for all
// activities, even those that don't handle configuration
// changes. You can't use Activity.onConfigurationChanged,
// since there are situations where that won't be called when
// the configuration changes. View.onConfigurationChanged is
// called in those scenarios.
container.addView(new View(this) {
@Override
protected void onConfigurationChanged(Configuration newConfig) {
super.onConfigurationChanged(newConfig);
computeWindowSizeClasses();
}
});
computeWindowSizeClasses();
}
private void computeWindowSizeClasses() {
WindowMetrics metrics = WindowMetricsCalculator.getOrCreate()
.computeCurrentWindowMetrics(this);
float widthDp = metrics.getBounds().width() /
getResources().getDisplayMetrics().density;
WindowSizeClass widthWindowSizeClass;
if (widthDp < 600f) {
widthWindowSizeClass = WindowSizeClass.COMPACT;
} else if (widthDp < 840f) {
widthWindowSizeClass = WindowSizeClass.MEDIUM;
} else {
widthWindowSizeClass = WindowSizeClass.EXPANDED;
}
float heightDp = metrics.getBounds().height() /
getResources().getDisplayMetrics().density;
WindowSizeClass heightWindowSizeClass;
if (heightDp < 480f) {
heightWindowSizeClass = WindowSizeClass.COMPACT;
} else if (heightDp < 900f) {
heightWindowSizeClass = WindowSizeClass.MEDIUM;
} else {
heightWindowSizeClass = WindowSizeClass.EXPANDED;
}
// Use widthWindowSizeClass and heightWindowSizeClass.
}
}
Compose
class MainActivity : ComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContent {
val windowSizeClass = calculateWindowSizeClass(this)
MyApp(windowSizeClass)
}
}
}
Une fois que vous avez observé les classes de taille de fenêtre dans votre application, vous pouvez commencer à modifier la mise en page en fonction de la classe de taille de fenêtre actuelle.
Pour savoir comment utiliser les classes de taille de fenêtre pour rendre les mises en page responsives, consultez les sections suivantes :
- Pour les mises en page basées sur les vues, migrez votre UI vers les mises en page responsives.
- Pour les mises en page basées sur Compose, créez des mises en page responsives.
Checklist pour la compatibilité avec différentes classes de taille de fenêtre
Lorsque vous modifiez la mise en page, testez le comportement de mise en page sur toutes les plages de tailles de fenêtre, en particulier avec les points d'arrêt basés sur la largeur compacte, moyenne et étendue.
Si vous disposez déjà d'une mise en page pour les écrans compacts, commencez par l'optimiser pour la classe de largeur étendue, afin de disposer de plus d'espace pour modifier le contenu et l'interface utilisateur. Ensuite, choisissez la mise en page qui convient pour la classe de largeur moyenne. Pensez à ajouter une mise en page spécialisée pour la largeur d'écran moyenne.
Proposez une expérience utilisateur améliorée en ajoutant des fonctionnalités qui s'appliquent spécifiquement à votre application, comme la compatibilité avec les positions pliables ou l'optimisation de la saisie avec le clavier, la souris et le stylet.
Pour en savoir plus sur ce qui fait la qualité d'une application quel que soit l'appareil ou la taille d'écran, consultez Qualité des applications sur grand écran.
Responsive design
La première étape pour accepter divers facteurs de forme d'appareil consiste à créer une mise en page qui s'adapte aux différentes tailles d'écran.
ConstraintLayout
Le meilleur moyen de créer une mise en page responsive est d'utiliser ConstraintLayout comme mise en page de base dans votre interface utilisateur. ConstraintLayout vous permet de préciser la position et la taille de chaque vue en fonction des relations spatiales avec les autres vues de la mise en page. Toutes les vues peuvent alors être déplacées et redimensionnées ensemble suivant les modifications de la taille de l'écran.
Le moyen le plus simple de créer une mise en page avec ConstraintLayout est d'utiliser l'éditeur de mise en page dans Android Studio. L'éditeur de mise en page vous permet de faire glisser de nouvelles vues vers la mise en page, d'appliquer des contraintes relatives aux vues parentes et frères et de définir des propriétés de vue, le tout sans avoir à modifier manuellement le XML.
ConstraintLayout.
Pour en savoir plus, consultez la section Créer une interface utilisateur responsive avec ConstraintLayout.
Largeur et hauteur responsives
Pour vous assurer que votre mise en page s'adapte à différentes tailles d'écran, utilisez wrap_content, match_parent ou 0dp (match constraint) pour la largeur et la hauteur de la plupart des composants d'affichage plutôt que des valeurs codées en dur :
wrap_content: permet à l'affichage de prendre tout ce qui est nécessaire en compte pour adapter sa taille au contenu affiché.match_parent: permet à l'affichage de se développer autant que possible dans la vue parent.0dp (match constraint): enConstraintLayout, semblable àmatch_parent. Permet à l'affichage d'occuper tout l'espace disponible selon les contraintes de vue.
Par exemple :
<TextView
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text="@string/lorem_ipsum" />
L'image 4 montre comment la largeur et la hauteur de TextView s'ajustent à la largeur de l'écran en fonction de l'orientation de l'appareil.
TextView responsif.
Le TextView définit sa largeur pour occuper tout l'espace disponible (match_parent) et sa hauteur pour qu'elle corresponde exactement à l'espace requis pour le texte contenu (wrap_content), ce qui permet à l'affichage de s'adapter à différentes tailles d'écran et différentes quantités de texte.
Si vous utilisez un LinearLayout, vous pouvez également développer les vues enfants en fonction de la pondération de la mise en page afin qu'elles occupent proportionnellement l'espace disponible. Toutefois, l'utilisation des pondérations dans un LinearLayout imbriqué nécessite que le système effectue plusieurs contrôles de mise en page pour déterminer la taille de chaque vue, ce qui ralentit les performances de l'interface utilisateur.
ConstraintLayout peut créer presque toutes les mises en page possibles avec LinearLayout sans impact sur les performances. Tâchez donc de convertir votre LinearLayout imbriqué en ConstraintLayout. Vous pouvez ensuite définir des mises en page pondérées avec des chaînes de contraintes.
Design adaptatif
La mise en page de votre application doit toujours s'adapter à différentes tailles d'écran. Toutefois, même une mise en page responsive ne permet pas d'offrir la meilleure expérience utilisateur possible sur tous les appareils. Par exemple, l'interface utilisateur conçue pour un téléphone n'offre probablement pas une expérience optimale sur une tablette. Le design adaptatif permet d'autres mises en page optimisées pour différentes dimensions d'affichage.
SlidingPaneLayout pour les interfaces utilisateur détaillées en liste
Une interface utilisateur détaillée en liste offre généralement une expérience utilisateur différente sur des écrans de différentes tailles. Sur les grands écrans, les volets de liste et de vue détaillée se trouvent généralement côte à côte. Lorsqu'un élément de la liste est sélectionné, les informations s'affichent dans le volet de vue détaillée sans modifier l'interface utilisateur. Les deux volets restent côte à côte. En revanche, sur les petits écrans, les deux volets s'affichent individuellement, chacun occupant la totalité de la zone d'affichage. Lorsqu'un élément est sélectionné dans le volet de liste, le volet de vue détaillée (contenant les informations de l'élément sélectionné) remplace le volet de liste. Le bouton "Retour" remplace le volet de vue détaillée par le volet de liste.
SlidingPaneLayout gère la logique permettant de déterminer laquelle des deux expériences utilisateur est la mieux adaptée à la taille de la fenêtre actuelle :
<?xml version="1.0" encoding="utf-8"?>
<androidx.slidingpanelayout.widget.SlidingPaneLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".MainActivity">
<androidx.recyclerview.widget.RecyclerView
android:id="@+id/recycler_view"
android:layout_width="280dp"
android:layout_height="match_parent"
android:layout_gravity="start" />
<androidx.fragment.app.FragmentContainerView
android:id="@+id/nav_host_fragment"
android:name="androidx.navigation.fragment.NavHostFragment"
android:layout_width="300dp"
android:layout_height="match_parent"
android:layout_weight="1"
app:defaultNavHost="true"
app:navGraph="@navigation/item_navigation" />
</androidx.slidingpanelayout.widget.SlidingPaneLayout>
Les attributs layout_width et layout_weight des deux vues contenues dans SlidingPaneLayout déterminent le comportement de SlidingPaneLayout. Dans l'exemple, si la fenêtre est assez grande pour permettre l'affichage des deux vues (au moins 580 dp), les volets s'affichent côte à côte. Toutefois, si la largeur de la fenêtre est inférieure à 580 dp, les volets se glissent les uns sur les autres pour occuper individuellement toute la fenêtre de l'application.
Si la largeur de la fenêtre est supérieure à la largeur minimale totale spécifiée (580 dp), vous pouvez utiliser les valeurs layout_weight pour redimensionner proportionnellement les deux volets. Dans cet exemple, la largeur du volet de liste est toujours de 280 dp, car elle n'est pas pondérée. Toutefois, le volet de vue détaillée remplit toujours tout espace horizontal au-delà de 580 dp en raison du layout_weight défini pour la vue.
Autres ressources de mise en page
Pour adapter la conception de l'interface utilisateur à des tailles d'écran très variées, utilisez des mises en page alternatives identifiées par des qualificateurs de ressources.
Vous pouvez fournir des mises en page adaptatives spécifiques à l'écran en créant des répertoires res/layout/ supplémentaires dans le code source de votre application. Créez un répertoire pour chaque configuration d'écran nécessitant une mise en page différente. Ajoutez ensuite un qualificatif de configuration d'écran au nom de répertoire du layout (par exemple, layout-w600dp pour les écrans d'une largeur disponible de 600 dp).
Les qualificatifs de configuration représentent l'espace d'écran visible disponible pour l'interface utilisateur de votre application. Le système prend en compte toutes les décorations de système (telles que la barre de navigation) et les modifications de configuration des fenêtres (comme le mode multifenêtre) lorsqu'il sélectionne la mise en page de votre application.
Pour créer une autre mise en page dans Android Studio (version 3.0 ou ultérieure), procédez comme suit :
- Ouvrez la mise en page par défaut, puis cliquez sur Orientation pour aperçu
dans la barre d'outils. - Dans la liste déroulante, cliquez pour créer une variante suggérée, comme Créer une variante paysage, ou cliquez sur Créer une autre.
- Si vous avez sélectionné Créer une autre, l'option Sélectionner un répertoire de ressources s'affiche. Sélectionnez un qualificatif d'écran sur la gauche et ajoutez-le à la liste des qualificatifs sélectionnés. Lorsque vous avez terminé d'ajouter des qualificatifs, cliquez sur OK. (Consultez les sections suivantes pour en savoir plus sur les qualificatifs de taille d'écran.)
Un double de votre fichier de mise en page par défaut est créé dans le nouveau répertoire de mise en page pour que vous puissiez commencer à personnaliser la mise en page de cette variante d'écran.
Qualificatif de plus petite largeur
Le qualificatif de plus petite largeur d'écran vous permet de proposer d'autres dispositions pour les écrans dont la largeur minimale est mesurée en pixels indépendants de la densité (dp ou dip).
En définissant la taille de l'écran comme une mesure de densité de pixels, Android vous permet de créer des mises en page conçues pour des dimensions spécifiques sans avoir à vous soucier des différentes densités de pixels.
Par exemple, vous pouvez créer une mise en page nommée main_activity et optimisée pour les téléphones et les tablettes en créant différentes versions du fichier dans différents répertoires :
res/layout/main_activity.xml # For phones (smaller than 600dp smallest width) res/layout-sw600dp/main_activity.xml # For 7” tablets (600dp wide or wider)
Le qualificatif de plus petite largeur spécifie le plus petit des deux côtés de l'écran, quelle que soit l'orientation actuelle de l'appareil. Il s'agit donc d'un moyen simple de préciser la taille totale de l'écran disponible pour votre mise en page.
Voici comment les autres valeurs de largeur minimale correspondent aux tailles d'écran classiques :
- 320 dp : écran de téléphone standard (240 x 320 pixels, 320 x 480 mdpi, 480 x 800 hdpi, etc.)
- 480 dp : grand écran de téléphone d'environ 5 pouces (480 x 800 mdpi)
- 600 dp : tablette de 7 pouces (600 x 1 024 mdpi)
- 720 dp : tablette de 10 pouces (720 x 1 280 mdpi, 800 x 1 280 mdpi, etc.)
L'image 6 détaille la façon dont les différentes largeurs d'écran en dp correspondent généralement à différentes tailles et orientations d'écran.
Le qualificatif de plus petite largeur est défini en dp, car c'est l'espace disponible à l'écran une fois que le système a pris en compte la densité en pixels qui importe (plutôt que la résolution en pixels brute).
Les tailles que vous spécifiez à l'aide de qualificateurs de ressources tels que plus petite largeur ne correspondent pas aux tailles réelles de l'écran. En effet, les tailles indiquent la largeur ou la hauteur en dp disponibles dans la fenêtre de votre application. Le système Android peut utiliser une partie de l'écran pour l'interface utilisateur du système (par exemple, la barre système en bas de l'écran ou la barre d'état en haut). Il est donc possible qu'une partie de l'écran ne soit pas disponible pour votre mise en page. Si votre application est utilisée en mode multifenêtre, elle n'a accès qu'à la taille de la fenêtre dans laquelle elle est installée. Lorsque la fenêtre est redimensionnée, une modification de configuration est déclenchée avec la nouvelle taille de la fenêtre, ce qui permet au système de sélectionner un fichier de mise en page approprié. Ainsi, les tailles des qualificateurs de ressources que vous indiquez ne doivent spécifier que l'espace nécessaire à votre application. Le système prend en compte l'espace utilisé par l'interface utilisateur du système lorsqu'il y en a pour votre mise en page.
Qualificatif de largeur disponible
Au lieu de modifier la mise en page en fonction de la plus petite largeur de l'écran, vous pouvez modifier la mise en page en fonction de la largeur ou de la hauteur actuellement disponible. Par exemple, vous pouvez utiliser une mise en page à deux volets chaque fois que l'écran fournit une largeur minimale de 600 dp, qui peut varier selon que l'appareil est en mode paysage ou portrait. Dans ce cas, vous devez utiliser le qualificatif largeur disponible comme suit :
res/layout/main_activity.xml # For phones (smaller than 600dp available width)
res/layout-w600dp/main_activity.xml # For 7” tablets or any screen with 600dp available width
# (possibly landscape phones)
Si la hauteur disponible est problématique pour votre application, vous pouvez utiliser le qualificatif hauteur disponible. Par exemple, layout-h600dp pour les écrans disposant d'une hauteur minimale de 600 dp.
Qualificatifs d'orientation
Même si vous pouvez accepter toutes les variantes de taille en combinant uniquement des qualificatifs plus petite largeur et largeur disponible, vous pouvez également modifier l'expérience utilisateur lorsque l'utilisateur change l'orientation entre portrait et paysage.
Pour cela, vous pouvez ajouter les qualificatifs port ou land aux noms de répertoire de mise en page. Assurez-vous simplement que les qualificatifs d'orientation sont placés après les qualificatifs de taille. Par exemple :
res/layout/main_activity.xml # For phones res/layout-land/main_activity.xml # For phones in landscape res/layout-sw600dp/main_activity.xml # For 7” tablets res/layout-sw600dp-land/main_activity.xml # For 7” tablets in landscape
Pour en savoir plus sur l'ensemble des qualificatifs de configuration d'écran, consultez Présentation des ressources d'application.
Composants d'interface utilisateur modulaires à l'aide de fragments
Lorsque vous concevez votre application pour plusieurs tailles d'écran, utilisez des fragments pour extraire la logique de votre interface utilisateur dans des composants distincts. Vous éviterez ainsi de dupliquer inutilement le comportement de l'interface utilisateur pour plusieurs activités. Vous pouvez ensuite combiner des fragments pour créer des mises en page à plusieurs volets sur de grands écrans ou placer des fragments dans des activités distinctes sur de petits écrans.
Par exemple, le schéma détaillé en liste (voir la section SlidingPaneLayout ci-dessus) peut être implémenté avec un fragment contenant la liste et un autre contenant les détails des éléments listés. Sur les grands écrans, les fragments peuvent s'afficher côte à côte. Sur les petits écrans, chaque fragment remplit individuellement l'écran.
Pour en savoir plus, consultez la présentation des fragments.
Intégration d'activités
Si votre application se compose de plusieurs activités, l'intégration d'activités vous permet de créer facilement une interface utilisateur adaptative.
L'intégration d'activités affiche plusieurs activités ou plusieurs instances de la même activité simultanément dans la fenêtre de tâche d'une application. Sur les grands écrans, les activités peuvent s'afficher côte à côte. Sur les petits écrans, elles s'empilent les unes sur les autres.
Vous déterminez la manière dont votre application affiche ses activités en créant un fichier de configuration XML qui permet au système de déterminer la présentation adéquate selon la taille de l'écran. Vous pouvez également effectuer des appels d'API WindowManager de Jetpack.
L'intégration d'activités est compatible avec les changements d'orientation des appareils et avec les appareils pliables, qui empilent et libèrent les activités lorsque l'appareil pivote ou se plie et se déplie.
Pour en savoir plus, consultez Intégration d'activités.
Tailles d'écran et formats
Testez votre application sur différentes tailles et formats d'écran pour vous assurer que l'interface utilisateur s'adapte correctement.
Android version 10 (niveau d'API 29) ou ultérieure est compatible avec de nombreux formats. Les facteurs de forme pliables peuvent passer de grands écrans étroits lorsqu'ils sont pliés (par exemple, 21:9) à un format carré 1:1 lorsqu'ils sont dépliés.
Pour assurer la compatibilité avec autant d'appareils que possible, testez vos applications sur autant des formats d'écran suivants que possible.
Si vous ne pouvez pas utiliser certains formats, utilisez maxAspectRatio et minAspectRatio pour indiquer les formats les plus grands et les plus petits compatibles avec votre application. Si les écrans dépassent ces limites, votre application peut passer en mode de compatibilité.
Si vous n'avez pas accès aux appareils pour toutes les tailles d'écran que vous souhaitez tester, vous pouvez utiliser Android Emulator pour émuler presque toutes les tailles d'écran.
Si vous préférez effectuer le test sur un appareil réel dont vous ne disposez pas, vous pouvez utiliser Firebase Test Lab pour accéder aux appareils d'un centre de données Google.
Compatibilité des tailles d'écran spécifiques
Si vous ne voulez pas que votre application s'exécute sur certaines tailles d'écran, vous pouvez définir les limites de redimensionnement de l'application ou limiter les appareils autorisés à l'installer en fonction de la configuration de l'écran. Pour en savoir plus, consultez Déclarer une compatibilité d'écran limitée.
Ressources supplémentaires
- Material Design – Comprendre la mise en page