Android's reach is growing and the experience is getting better, with more than 250 million large-screen devices now on Android, including tablets, foldables, and Chrome OS devices. How to adapt to different screen sizes and ensure a good experience has always been a major problem for developers. Especially with the emergence of new products such as foldable devices, adaptation work has become more and more urgent.
Google's official article will highlight the updated content in the Material Design guide and provide some suggestions to help developers build applications according to the principles of adaptive interfaces to solve the adaptation problem on tablets and foldable devices.
If you prefer to learn more about this article via video, please click below:
△ Apply design specifications on the folding screen
Compose
https://developer.android.google.cn/jetpack/compose/nav-adaptive
Design guidelines
In early 2021, we published a guidance document for large-screen devices on the Material Design website. During the Android Developer Summit we've updated some content to help developers prepare for more types of devices like foldable devices.
https://m3.material.io/foundations/adaptive-design/overview
Gain an in-depth understanding of layout
The In-Depth Understanding Layout Guide introduces the concept of layout containers and provides a holistic framework to help developers think about how to arrange interface elements such as navigation bars, toolbars, and content on the screen.
https://material.io/design/layout/understanding-layout.html#principles
△ Three main areas of layout
The combo section of the guide takes you through how to make the most of screen space for readability and to properly arrange important content and action options in different scenarios in a way that respects the user's mental model. Include appropriate scaling to show more content, such as subtitles and dates in the example, and smaller combinatorial techniques such as visually grouping content in a compact layout and maintaining its relevance.
https://material.io/design/layout/understanding-layout.html#composition
△ Some of the layout methods covered in the combination guide
In the case of the Fortnightly sample app, its interface layout on tablets is well balanced, thanks to the fact that it follows the guidelines for containers. And as you can see, Fortnightly uses Visual Divider to separate the latest news, and on the other side of the screen, uses blank space and typography to group different categories of news stories.
△ Fortnightly follows the guidelines to separate and group content
Grid system
Many apps now treat the screen as a large canvas or single column, drawing elements horizontally and vertically in relation to each other, and some also leave margins on one side as a whole. This may work on small screens, where problems arise when the screen size is larger. The grid system divides your layout into columns to help you design a more expressive layout in the canonical grid. Using a column grid in the layout (as shown below) can make the experience of large-screen devices more intimate and organized, making the device and content more naturally integrated.
△ Column grid
These columns allow you to improve the hierarchy of information by dividing the screen into different areas that hold related information and actions. As shown in the following figure, there are three areas here, which will draw the user's attention to these areas corresponding to the main piece of information or information group on the screen in the order in which the designer expects the user to read. Most importantly, the column grid provides a reasonable way to think about how to rearrange content as the screen size gets larger or smaller, helping you respond consistently to different screen sizes.
△ Use a column grid to divide the screen into three main areas
In this example, the three main areas are rearranged to maintain the same hierarchy of information, but are displayed on a small screen in a more user-friendly way.
△ Use a column grid to rearrange content in different screen sizes
Remembering that the grid system helps you choose component behavior, deciding in different layouts to replace or change components in the way that makes most sense for device size and scene. For example, on large-screen devices, you can use Navigation rail (the left sidebar navigation bar) instead of bottom navigation, both of which are the same function and visual representation similar, but Navigation rail can arrange pages more humanely. Full-screen dialogs on mobile phones can be replaced by simple dialogs on large screens to maintain the context of the user's current actions.
△ Use a simple dialog box (right) on a large screen instead of a full-screen dialog box (left)
Navigation rail
https://m3.material.io/components/navigation-rail/overview
Bottom navigation
https://m3.material.io/components/bottom-navigation
Size category
Remember that when replacing components, the first step is to meet the functionality and user-friendliness of the user. Finding the correct threshold for adjusting the interface is an important step in implementing a responsive interface. So we've defined new breakpoint values that help to divide devices into preset categories of sizes that represent the size of the actual devices on the market. They help you convert the original dimensions of your app layout into discrete, standardized groups that you can use to make higher-level interface decisions. For example, almost all standard phones use a combination of small Compact width and medium height in portrait mode, and since vertical scrolling is common, it is sufficient for most apps to adapt to the size category of the width.
△ Size categories based on width
△ Size class based on height
These dimension classes will appear as new APIs in the Jetpack Window Manager library in version 1.1. Starting with Android Studio Bumblebee, we've also incorporated size categories into the tool in the form of Reference devices, on the basis of which the interface is consistent and easier to operate. And developers don't need to check the actual physical size or screen orientation, or other error-prone signs. As you design and build different size categories, think about how people will hold and touch the devices that those categories represent. Focusing on the shape and size of your device can help you create a more user-friendly experience. For example, on a tablet or large-screen phone, it can be difficult for people to reach the top area of the screen without fully adjusting the grip posture, so keep important actions and content in the easily accessible area.
Size class
https://developer.android.google.cn/guide/topics/large-screens/support-different-screen-sizes#window_size_classes
Window Manager
https://developer.android.google.cn/jetpack/androidx/releases/window
Android Studio Bumblebee
https://developer.android.google.cn/studio
Standardize the layout
Canonical layouts provide a range of common layout schemes that are very helpful for designing large-screen apps. The first is a simple combination of list/detail, or list grid views, while setting/not setting the navigation container on the starting side of the screen that starts to display content.
△ List / detail layout
Support panels can be used in experiences where people need to focus, such as documents. Add a panel at the end or bottom of the screen to make it easier to use tools or contextual controls.
△ Support panel
Feeds are a common pattern in news or social apps, and templates take the form of tiles to entice users to discover more. This interaction is the same as on a mobile phone — opening an item opens a new page, but the experience is more immersive and designed for large screen sizes.
△ Information flow
The home page banner prioritizes the content at the top of the screen and designs support elements around and below the content, which is a great experience for media-centric apps.
△ Home page banner
Standardize layout practices
Adopting a responsive interface is not just about providing parallel structures for different screen sizes, but also about being flexible enough to resize to suit a variety of needs, such as rotating devices, multi-window modes, and folding and non-folding gestures. So while running, the app can transition from one size category to another and back in time. It is important not to think of the size categories as completely separate buckets, and the app also needs to maintain continuity (i.e., not interrupt the user experience), so that app state or data cannot be lost.
△ Responsive interface can adjust the content layout according to the change of screen size
Imagine that when you resize your browser window, it's a strange experience if the browser falls back from one page, or redirects to another, or modifies the history. Therefore, each page should be flexible enough and should be able to remain intact during the size transition, at which point the canonical layout can play an important role. For each page, you can think about what you can add when the screen size gets bigger. What can be deleted when the screen size becomes smaller. Then choose the appropriate strategy. This may mean that you need to revisit the navigation chart, especially if your current design is primarily mobile.
To build a responsive interface, we should prioritize the placement of long-standing elements in the interface, such as navigation elements. Following the Material guidelines, we can provide alternative layouts based on the size category of the width, adjusting the navigation to the most convenient location. For example, small screens have a bottom navigation view, medium screens have Navigation rail, and large screens have a full navigation view. Note that these layouts use the width qualifier "-w" instead of the minimum width qualifier "-sw". The remaining space is used to arrange the content, and we can apply the canonical layout in this space.
List / Details
For list/details, there is a special control in AndroidX called SlidingPaneLayout, which needs to specify layout_width for its two child elements before use, and during the run, SlidingPaneLayout will determine if there is enough space to display two panes at the same time:
△ SlidingPaneLayout layout example
When there is enough screen space, both panes must reach at least the specified width, and the remaining space can be allocated by layout_weight, as shown in the figure on the left; if there is not enough space, as shown in the image on the right, each pane uses the full width of the parent view, and the detail pane is slid to the side, or directly overwrites the first pane.
△ SlidingPaneLayout space allocation result
viewModel.selectedItemFlow.collect { item ->// Update the contents of the detail panedetailPane.showItem(item)// Slide the detail pane into view // If two panes are placed side by side // does not produce practical resultssslidingPaneLayout.openPane()}
As shown in the code above, you can control the slide pane through the code, and when the user selects an item from the list, we receive the item from the Kotlin stream in the ViewModel, then update the contents of the details pane and slide it into view by calling openPane. The effect in the Trackr app is shown in the following figure:
For information about how to implement a two-pane layout using SlidingPaneLayout, see Android Developer Site: Creating a Two-Pane Layout, which also covers other things like integrating the system back button to implement a slideback pane.
Trackr app
https://github.com/android/trackr
Create a two-pane layout
https://developer.android.google.cn/guide/topics/ui/layout/twopane
Flow
We can immersively present a dataset through a stream of information, so RecyclerView is a great choice, and we can change the presentation by changing the LayoutManager used by RecyclerView. LinearLayoutManager is suitable for smaller widths, but in medium-width and expanded-width scenarios, where page content is overstretched and distorted, it may be more appropriate to use GridLayoutManager, or StaggeredGridLayoutManager, or even FlexBoxLayoutManager.
Change the presentation of RecyclerView's LayoutManager
Home page banner
We can also change the layout of individual items to make some items taller or wider than others to highlight their importance and create more interesting visuals. In the home page banner layout, we emphasize a particular element, rearranging other supporting elements around it. Of course we have many ways to achieve this, but ConstraintLayout is the most flexible because it provides many ways to constrain the size of child elements, as well as their position relative to other child elements. In the following media class example application, its header is limited to a 16:9 aspect ratio, with the description pane occupying 60% of the width and leaving room for other elements. Constraints can be changed and even animated with MotionLayout, which is a special ConstraintLayout.
△ Example of a homepage banner
For support panels, any layout control, from LinearLayout to ConstraintLayout, can be used as a container to position the panel. As shown in the image below, we consider one thing, where the content on the panel should be placed when transitioning to a small screen size. We have a number of options, such as using the side drawer navigation bar on the tail side of the screen, or using the slide-up bottom action bar, or using the options menu, or even hiding the content completely.
Adapts to foldable devices
Foldable devices are not only equipped with larger screens, they can also adjust the orientation/posture of the device according to how the device is folded and how the user uses it.
There are currently three common device forms: folded, undiscovered, and desktop mode (hover). In addition, we will see other theoretically existing states later, such as the book pattern.
△ Three common postures of folding equipment
As with other large-screen devices, we need to think more about how users will hold an undisciplined device. For example, for tablet computers, some screen areas are difficult to reach with the thumb, and it is difficult for users to free up their entire hands to freely control the screen. The bottom corner of the screen can be easily reached by the user, but may not be able to reach the top of the screen, especially in portrait mode. This means that if you use components like Navigation rail, centering or pinning the navigation buttons to the bottom of the screen makes it easier for the user to operate.
△ User operation hot zone in large-screen devices
At the same time, we also need to consider the impact of hinge position on interaction. Hinges can bring obvious tactile differences, and even there will be physical separation between the two screens. Therefore, please avoid placing buttons and other important action items directly in the hinged area. The hinged area on most devices is about 48 dp wide, and avoid placing interface elements in the hinged area in desktop mode, where users can hardly use any of the features of the area.
△ Hinged area
When a device transitions from folded mode to non-folded mode, there are two main technical scenarios available for designing layouts. The first is to enlarge the screen, which uses a simple, responsive layout in which the app expands the content and populates the screen. Typically, we expand the column grid according to the material guidelines mentioned earlier:
https://m3.material.io/foundations/adaptive-design/foldables/compositions
The second is to add another page, depending on the app you're building, with the same functionality as the list/details or another panel supplementing the main panel.
△ Scenario 1: Enlarge the screen (Figure left) Scenario 2: Add a page (Figure right)
In both cases, according to material.io's guidance, you'll create an eight-column grid evenly distributed on both sides of the hinged area, and when you add navigation containers such as Navigation rail, the starting side of the screen is compressed to accommodate the navigation containers.
△ Eight-column grid evenly distributed on both sides of the hinge (blue background)
Adaptation example
Now let's see how to take advantage of the collapsed state during operation. The Jetpack Window Manager library provides APIs to detect whether an app window is collapsed. Any activity can get an instance of windowInfoRepository. Then, between the two lifecycle states of Started and Stopped, we can safely gather information from the window layout traffic. Whenever a stream emits a value, we can examine the displayFeature and then look for foldingFeature in a targeted manner.
override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) val windowInfoRepo = windowInfoRepository() // Securely collect data from windowInfoRepo between STARTED and STOPPED lifecycleScope.launch(Dispatchers.Main) { lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) { windowInfoRepo.windowLayoutInfo.collect { info -> for (feature in info.displayFeatures) { val fold = feature as? FoldingFeature ?: continue // 使用 FoldingFeature } } } } }
△ Recognize the folding posture
Once we have information about the folding posture, there are a few ways to see if the device is in one of the previously mentioned postures. In book mode, the device has a status of HALF_OPENED and its orientation is VERTICAL, and in desktop mode, the status is HALF_OPENED with horizontal orientation.
Book mode is half open vertical folding mode fun FoldingFeature.isBookMode() = state == FoldingFeature.State.HALF_OPENED && orientation == FoldingFeature.Orientation.VERTICAL// Desktop mode is a half-open horizontal folding mode fun FoldingFeature.isTableTopMode() = state == FoldingFeature.State.HALF_OPENED && orientation == FoldingFeature.Orientation.HORIZONTAL
△ The judgment condition of book mode in desktop mode
FoldingFeature also contains the folding position in the window, and when the folding causes the content view to be split, we should update the layout parameters in a timely manner. You can make adjustments, such as putting the support panel to the side or displaying the home page banner in the top half of the fold. First, we need to know where the content view is in the window, and we can get the location information by gettingLocationInWindow. We'll use these coordinates along with the width and height to create a Rect object so that we get the view boundaries in the window coordinate space.
FoldingFeature gives the collapsed boundary in the coordinate space of the window, so we can directly check if the two regions intersect, and if they do, we can convert the boundary of the featureRect into the coordinate space of the view and return it. By the way, if you use SlidingPaneLayout to implement a list/detail layout, you automatically get support for book mode. As long as both panes fit in, SlidingPaneLayout places the panes on the other side of the collapsed stance.
fun getFoldBoundsInView( foldingFeature: FoldingFeature, view: View): Rect? { // Get the boundary of the view in the window coordinate space val viewLocation = IntArray(2) view.getLocationInWindow(viewLocation) val (viewX, viewY) = viewLocation val viewRect = Rect( left = viewX, top = viewY right = viewX + view.width, bottom = view + view.height ) ... // The boundary of the display function is already in the coordinate space of the window // Check whether the boundary of the view and the boundary of the display function intersect val featureRect = Rect(foldingFeature.bounds) val intersects = featureRect. intersect (viewRect) if (featureRect.isEmpty ||! intersects) return null } // Converts the bounding coordinates of a function to a view of the coordinate space featureRect.offset(-viewX, -viewY) return featureRect}
△ Get the position information of the fold
Test
If your app has special behavior related to collapsed state, you need to write unit tests for it. Jetpack Window Manager has a test rule that supports simulating FoldingFeature during a stake test. Since the test requires views, we added WindowLayoutInfoPublisherRule and ActivityScenarioRule, which together form a test rule chain. In this test method, we get the activity through the activityRule, then create window attributes to simulate the desktop pattern, build the WindowLayoutInfo object and publish the object using publisherRule. After that, we can use Espresso and JUnit assertions to check that the activity works correctly in desktop mode.
private val publisherRule = WindowLayoutInfoPublisherRule()private val activityRule = ActivityScenarioRule (MyActivity: :class.java)@get :Ruleval testRule = RuleChain.outerRule ( publisherRule) .around(activityRule)@Testfun testDeviceOpen_TableTop(): Unit = testScope.runBlockingTest { activityRule.scenario.onActivity { activity -> val feature = FoldingFeature (activity, HALF_OPENED, HORIZONTAL) val testWindowInfo = WindowLayoutInfo.Builder( ) .setDisplayFeatures (listOf (feature)) .build() publisherRule. overrideWindowLayoutInfo(testWindowInfo) } // Write assertions based on desktop pattern}
△ Test the folding state
Interface testing is difficult because some tests must be performed on specific devices. To that end, Android Studio is adding support for Gradle-hosted virtual devices. You can use the Android Gradle plugin version 7.1 and above to experience the feature.
Under the testOptions module in the application-level build.gradle file, specify the virtual device configuration file as you normally would manage and run the virtual device in Android Studio. For example, here's a Pixel C tablet image, where Gradle creates a target that can perform tests on a given device, and even download a device image if needed.
android { testoptions { devices { pixelCapi30 (ManagedVirtualDevice) { device = "Pixel C" // tablet apilevel = 30 systemImageSource = "aosp" // For GooglePlay services, use "google" abi = "x86" } } }}#Gradle target = {device name} + {build variant} + "AndroidTest"./gradlew pixelCapi30debug AndroidTest
△ Virtual device configuration
To make it easier to distinguish which tests are for which devices, we will create a custom annotation, LargeScreenTest, and mark the test function with that annotation. When we run the previous Gradle command, we add a parameter for AndroidTestRunner to ensure that only tests with this comment run. If you do not use comments, you can also use TestRunner's other filtering options, such as running tests in a specific class. By combining these features, we can set up a consistent running configuration for our tests.
annotation class LargeScreenTest@RunWith(AndroidJUnit4: :class)class MyActivityTest { @Test @LargeScreenTest fun largeScreenDeviceTest() { // Test interface on tablet devices }}# Only run tests with the specified annotations. /gradlew pixelCapi30debugAndroidTest \ -Pandroid.testInstrumentationRunnerArguments.annotation=com.mypkg.LargeScreenTest
△ Use custom annotations to write tests for a specified device
More information
In addition to making the content on the screen look bigger, the big screen brings a few other opportunities to help your app shine. In multi-window mode, your app can be used side-by-side with other apps, and in addition to responsive adjustments, you can also consider how to make your app work more in this mode, such as supporting drag and drop. This small feature increases user productivity and makes users more willing to use your app.
△ Multi-window mode effect
Multi-window mode
https://developer.android.google.cn/guide/topics/ui/multi-window
In addition to interacting through touch, large-screen devices support other forms of interaction. The larger the screen size of the device, the more likely the user is to use a keyboard, stylus, mouse, gamepad, or other external device. If you want to improve the ease of use of your app in these situations, you can plan to support some of these input methods, and for more details, see the article "It's Time to Adapt Perfect Input Support for All Devices.".
In such a diverse hardware ecosystem, it can be difficult to have devices of all shapes and sizes, and today the Android SDK provides emulator images for foldable devices that allow you to change the folded state to the hinged angle at any time. The upcoming Android Studio Chipmunk will also come with a resizable emulator that allows you to freely change the size of your app window, and every developer can try out their app on almost any type of device.
Adjustable emulator in Android Studio Chipmunk
Android Studio Chipmunk
https://developer.android.google.cn/studio/preview
We've also been working on new tools in Android Studio to support everyone developing large-screen apps. The new Layout Validation tool previews the layout on reference devices that cover a variety of size categories, suggests problem areas (e.g., long lines of text use), and recommends different interface components for different breakpoints.
Layout Validation in Android Studio
Finally, we've listed app quality guidelines for large screens on the Android developer website, with the first sections of the guide describing basic compatibility expectations, such as whether the app supports both landscape and portrait modes, and the following sections focusing on supporting various screen types and states, and using specific screen types or states to create different experiences.
Guidelines for app quality on large screens
https://developer.android.google.cn/docs/quality-guidelines/large-screens-app-quality
We hope that everyone will be able to take advantage of what is shared today and refer to the new quality guidelines to build apps that will delight users on a variety of screen sizes.