[MUSIC PLAYING] CLARA BAYARRI: Hi,
I'm Clara Bayarri, an engineering manager on
the Android Toolkit team, working on large screens
and Jetpack Compose. DANIEL JACOBSON: And I'm Daniel
Jacobson, a product manager on the Android developer
team for foldables, tablets, and large screens. CLARA BAYARRI: You may have
seen some big announcements in the keynote, including our
12.0 feature drop, upcoming updates to Play Store to assess
large screen app quality, and more. In this talk, we'll focus on the
developer tools and libraries that make it easier for you to
scale your app's UI to support a wide range of screen sizes. We'll walk you through a
collection of APIs and tools, which help you make the most of
your UI as screen sizes scale up. Before we jump into
all of that, though, why are we making such a
fuss about large screens? In the last 12 months, we've
seen nearly 100 million new tablet activations. And Chrome OS grew by 92%,
the fastest growing desktop platform. This means that there
are over a quarter billion large screen
devices running Android across tablets,
foldables, and Chrome OS devices. Speaking of foldables,
we've seen foldable devices on the rise, with year-on-year
growth of over 250%. Device manufacturers
are increasingly recognizing this form factor
as a device differentiation opportunity in the
premium phone segment. With the rapid growth of
tablets and foldables, it's time to stop thinking about
phones and tablets separately. Design and build your
app for the ecosystem to increase your app's
reach in the market. In the upcoming
months, Placer will be introducing new
incentives for developers to target large screens,
including per device type app ratings. It is now time to get
ready for these changes to ensure great app ratings
across all device types. Doing the work now will
also ensure your app avoids awkward user experiences,
such as having your app letterbox on large
screen devices, because your UI isn't
scaling properly. We've already observed
business success from apps who optimize for all
screen sizes around metrics, such as user engagement
and user retention. Let's look at another
success story, Candy Camera. After building optimized
layouts for foldables and large screens, including a
tabletop specific snap and view mode, they observed
users of Candy Camera on these devices spending 10%
more time in the app and a 14% increased seven
day user retention. And it's not just Candy
Camera, a variety of apps are building optimized layouts
for large screens and foldables to capitalize on this fast
growing device segment. Another example is
Microsoft Outlook. Recent updates to Outlook
take full advantage of larger displays,
with a two pane layout to see your
inbox and email contents at the same
time, and the ability to compose a new email
in a separate window with multiple displays. It's time to break out
of the phone-in design and develop responsibly now. But don't worry,
we're doing a lot to make it as easy as possible
for you across the development lifecycle. Let's jump right in. DANIEL JACOBSON:
We've heard from you that knowing what screen sizes
to design and develop for is difficult within our
diverse device ecosystem. We're working hard to
make it straightforward for you to build a
responsive UI that works well across phones,
tablets, and other form factors. For the future of
resizable Android apps, we've dug deep into Android
device market representation. We also took some inspiration
from responsive and adaptive web development best practices. The result is a new foundation
for building resizable Android UI. This new system is called
Window Size Classes. Window Size Classes are a set
of opinionated viewport break points for you to
design, develop, and test resizable application
layouts against. These break points will
help you understand the key sizes to optimize for to
ensure your app covers as much of the ecosystem as possible. The window size
class breakpoints have been broken into three
categories, compact, medium, and expanded. They have been
designed specifically to balance layout simplicity
with the flexibility to optimize your app for
most unique use cases. The recommended usage
of these break points is to make high level
application layout decisions. And they also map to the
material layout breakpoints for layout grid column changes. New window size class APIs,
coming in Jetpack WindowManager 1.1, will enable
you to break away from error prone isTablet
Boolean logic that has become especially
fragile with the introduction of foldables. These new APIs will also negate
the need for custom logic around landscape and portrait
configuration changes for most cases. You'll just be able to design
for the different window size class breakpoints,
and your app will adapt to the right layout
and various app states. One important thing to mention
is that Android applications can be arbitrarily resizable. And all applications
run in multi-window mode beginning with Android 12. In the keynote, we
mentioned that we've seen a 7x increase in split
screen usage on the Samsung Galaxy Fold series from the
larger screen real estate that the inner display provides. Split screen apps can be resized
to match user preferences, further emphasizing the
importance of building resizable UI. We also recognize
the familiarity with thinking about
layouts in terms of devices and configurations. To make things a bit easier,
each size class breakpoint represents a majority
case for typical devices and configurations as seen here. And this can be a helpful
frame of reference as you think about the design of
your breakpoint-based layouts. To be explicit, compact width
represents your typical phone in portrait mode,
medium width represents tablets and larger foldable
inner displays in portrait mode, and expanded
width represents tablet's larger
foldable inner displays and desktops in landscape mode. In addition to these three
width-based breakpoints, we are introducing
height-based breakpoints with the same category names to
provide additional flexibility for more advanced
layout scenarios, such as optimizing for
landscape phone UIs using the compact height breakpoint. We've heard this can get a bit
complicated, but don't worry. After speaking with
many Android developers we have evidence to
suggest that most of you will only need to adapt your
applications based on width. To summarize,
window size classes represent a big step in
adaptive and responsive layout development in Android across
updated and improved guidance, new APIs in Jetpack
WindowManager, and new tools in Android Studio. Speaking of Android Studio,
I'm excited to introduce a new category of tools coming
to Android studio Bumblebee called Reference Devices. Since Android apps should be
built to respond and adapt to all devices and
categories, we're introducing reference devices
across Android Studio, and many tools where
you design, develop, and test UI and layout. The four reference
devices represent phones, large foldable
inner displays, tablets, and desktops. These reference
devices have been designed after
analyzing market data to represent either
popular devices or rapidly growing segments. And they are also
designed to enable you to ensure your app works
across most windows size class combinations. If you just take one
thing away from this talk, remember this checklist. To make sure your application
scales well across devices optimize your layout for both
compact and expanded width size classes. Next, test your app on
all reference devices. Every app is different
so pick the layout that works better on
medium width size class screens for your app. And to make your app
really stand out, consider additional
improvements, such as custom layouts for
foldable hinge postures or a custom layout for the
medium width breakpoint or height breakpoints. Also, don't forget
about how users interact with larger screen devices. Often with additional input
tools like keyboard and mouse and stylus. You can find more
details about window size classes in our docks. And you'll see both window
size classes and reference devices appear throughout the
rest of this presentation. For an example of window
size classes in action, check out our JetNews
Compose Sample. CLARA BAYARRI: The
first step to supporting adaptive UI is designing
your app in a way that behaves nicely on both a
small and a larger screen. This may be quite
intimidating, like facing a blank piece of paper. It's important to consider
how your application will be used in different
contexts, and what you want to enable with the
additional screen space. We've been working on
new material design guidance that will help guide
you scale your app's UI. We've published guidance
on common UI structures prevalent in the ecosystem that
will help inspire and kickstart your efforts. Leverage these resources
to make it easy to get started with layout ideas
and enhanced designs across phones, tablets,
and folding displays. For a more detailed explanation
of the new guidance, check out the Designing
Beautiful Apps on Foldables and Tablets talk. Designing a beautiful
responsive UI is a first step, but knowing how to implement
and maintain that design can be a real challenge. Whether you have an existing
app with a set architecture or looking at
starting from scratch, we have some tools to
help you along the way. DANIEL JACOBSON: Let's see
how we can update an existing app to rapidly
optimize for all screen sizes with the help of new
Jetpack APIs and Android Studio features. We'll use Trackr, an open
source sample task management app that we've recently updated
to better support larger screen devices. Trackr was developed to showcase
accessibility best practices within Android, and
with the recent updates for large screens,
you can use this as a great example for your app. Let's take a look at what
we did to make Trackr work great on large screen devices. Before we made any changes,
this is how Trackr looked. Regardless of
device or screen, we had a single pane,
list of tasks, with a bottom app bar for
navigating to an archives or settings screen. The application has five main
views, a list of the tasks, each task's details, a screen
to create or edit tasks, and a settings
and archives view. The navigation graph before
we've done any large screen optimizations flowed
like this, with the list of tasks acting
as the home page, enabling navigation to the
settings or archive page. Now, let's optimize
this for large screens. If you're not sure where to
get started in your own app, the first thing
you can do is use New Tools to identify potential
issues impacting large screen devices. In Android Studio
Chipmunk, we're working on a new
visual linting tool to surface UI warnings
and suggestions in layout validation. In Trackr, we can use layout
validation on existing layouts to surface some potential
large screen related issues. I can start with the top
of my navigation tree to get a good high
level overview of how my app will behave. I'll start by opening
my main activity layout, and then I'll open the
Layout Validation tool. If you don't see a
Layout Validation, you can go to View, Tool
Windows, and select it there. The first thing you may notice
within Layout Validation is the new Reference
Device's validation category. This is one area where you will
see the new Reference Devices feature appear in
Android Studio. I see a Warnings icon in the
top right of Layout Validation. Clicking on this opens
the Warning pane. And clicking on each
Warning shows me which reference
devices are impacted. In this case, I see two
warnings specifically related to large screen layouts. Bottom app bars are
only recommended for compact screens,
and material text view has lines containing
more than 120 characters. I can expand each warning
to see that the warning also provides a suggestion. The suggestion for the warning
related to the bottom app bar is to use a NavigationRail,
NavigationDrawer, or top app bar instead. For Trackr, I think
it will make the most sense to use a NavigationRail. The suggestion for the
warning about the material text that you control
is to either decrease the width of the text view or
consider a multi-column layout instead. In this case, a
multi-column layout would work great for our app. Let's work to resolve
these warnings by implementing a
typical list details pane style app for
the tasks list. To recap, our desired end
state will have two new layout optimizations. For medium width device
classes and larger, we'll have a NavRail
instead of a bottom app bar. And for expanded
width device classes, we'll also present a
two pane layout to show tasks and associated details. Let's start by focusing
on the first optimization. Adding a NavRail instead
of a bottom app bar. The first thing we need to think
about is our NavigationModel. Fortunately, our navigation
graph is impacted minimally. We aren't changing the screens
we have to navigate to, but the NavRail will expose the
full nav graph on each display, because the NavRail
will always be present. With that in mind, our
updated navigation graph would look like this. The app start destination
is still the task screen, and selecting an individual task
will navigate to task details. However, from the NavRail, I
can navigate to any other view. To implement this pattern, I
can add a NavigationRail view to my main activity layout. Previously, main
activity consisted of just a FragmentContainerView
with the coordinator layout to host the other fragments
through the NavHostFragment. By placing the
NavigationRail view at the main activity
layout level, it will persist
across all views. That said, I only want
the NavigationRail for screen sizes with a
width of 600 DP or larger. One easy way to achieve this
is to add a resource qualified main activity layout, and
add the NavigationRailView at the same level as the
FragmentContainerView containing the NavHostFragment. We'll also want to
update our tasks fragment to remove the bottom
app bar from displays with a width of
600 DP or greater. Similar to how I
implemented the NavRail, I can add a resource qualified
layout for the tasks fragment. I can then remove
the bottom app bar and associated
floating action button. Everything else remains the
same so that my list of tasks hosted in a RecyclerView will
continue to work as expected. Last, I can set the ID
of my NavRail menu items to match the ID of my existing
navigation destinations, and then set up the
NavController for my NavRail in my main activity code. Now that that's done, let's
take a look at Android Studio to see if things look right. We're bringing reference
devices to the Layout Editor, so as I'm working
on these updates, I can quickly toggle between
the various reference devices to make sure I'm seeing
the expected layout. When looking at the
phone reference device, I still see the bottom
app bar, as expected. When looking at anything
larger, I see the NavRail. Perfect. Now that our application is
using a NavigationRailView, let's move on to display a two
pane view for expanded width devices. One easy way to support
a two pane layout is to use SlidingPaneLayout. What's great about
SlidingPaneLayout is that it allows me to easily
reuse existing layout code. Let's again consider the
updated navigation graph. As a quick refresher,
this is the current state of our application. The NavigationRailView allows
me to navigate to any top level layout within my app. And I can still navigate
from the tasks fragment to the details fragment by
selecting any individual task. When we implement
SlidingPaneLayout our navigation graph
will change a bit. We'll be adding a new
layout, two pane tasks, to include the
SlidingPaneLayout, and this will be the
new start destination for our application's
navigation graph. This layout will contain both
the tasks and details fragment. By updating our application's
navigation this way, we will have the same
navigation graph for the app regardless of screen size. This means resize events
won't confuse users with unexpected app navigation. Because both tasks
and details will be presented in the same new
fragment and SlidingPaneLayout, we'll add a new sub-navigation
hierarchy specifically for the navigation
interaction for this fragment. This will make sure that
when I select a task, and then my app goes from
two panes to one pane, that item will be on the
top of my navigation stack and will be visible. This could happen
if I was folding my foldable, for example. To be more succinct,
the navigation from tasks to individual
details will be broken out of the app's top level
navigation hierarchy, and will be managed separately
by the SlidingPaneLayout. To summarize, I will
add a new fragment using SlidingPaneLayout
and FragmentContainerView to host the Tasks and
the Details panes. This means I don't have
to do major refactoring within my existing layout
code, which is great. Then, I will update my top
level app navigation hierarchy to make the new two pane
fragment my app's starts destination, and
remove the details destination from the
app's navigation graph. Next, I'll add a new
navigation graph specifically for the SlidingPaneLayout. Finally, I'll handle the
SlidingPaneLayout NavController configuration logic in my tasks
two pane fragment Kotlin code. All right, with those two
changes to our application, I think it will look much better
across different device form factors. Let's find out. First, let's take one more
look at the layout validation for my main activity to see
if everything looks right. Great. I'm seeing the right
layout for each reference device in just one view. Now, to test things
at runtime, we can use the new
resizable emulator coming with Android Studio Chipmunk. The resizable emulator
lets me quickly toggle between the
same reference devices. This means you can rapidly go
from validating your layout at design time, using Layout
Validation with Reference Devices, to confirming
the behavior at runtime, using the Resizable Emulator
and the same Reference Devices. First, I can see I
have a single pane application with a NavRail on
foldable inner screen displays, this represents the
medium width size class. If I try it on
the phone display, I get the single pane view
with the bottom app bar, this represents my
compact width size class. Finally, when testing
on a tablet or desktop, I get the NavRail
with my two panes. One other great attribute
of SlidingPaneLayout is that it scales well
to not only large screen devices, but also devices
with multiple screens. Microsoft recently contributed
to SlidingPaneLayout to support hinge detection to
split the panes across displays in the presence of
a physical hinge, without any additional code. This means our application's
new list to detail layout will scale well to
all devices, including those with multiple displays. With those changes, we have
a much more adaptive Android application optimized for each
width-based window size class breakpoint. While this is a great way to
apply a large screen optimized layout to an existing
application with fragments, we know many of you
have applications based on multiple activities. For those apps, the new activity
embedding APIs released in 12L make it easy to support new UI
paradigms, such as a two pane view. One other thing we're working
on is updating SlidingPaneLayout to support using
multiple activities with the new activity
embedding APIs. Look for an update
in the coming months. CLARA BAYARRI: In
addition to making it easy to update your existing
apps with adaptive UI best practices in mind, we're
excited to introduce Jetpack Compose as
one of the key tools in your pocket to
make it easy to build large screens and
diverse UI layouts. If you're starting
to adopt Compose, this is a great time
to also consider optimizing for large
screens along the way. Compose reached 1.0 this
July, and since then we've seen tremendous reaction
from the Android developer community. Tens of thousands
of apps are already using Compose in
production, including the Play Store itself. Compose is a
declarative UI toolkit, meaning you describe how
your UI should look like based on state, and you
let Compose figure out any updates needed. All UI is described
in code, and it's easy to make
decisions at runtime on how your UI should look. Notice this is a big difference
with the view system, where we rely on resource qualifiers
to describe different screen configurations at compile time. This makes Compose especially
great for developing adaptive UI, as it's very
easy to handle UI changes across different screen sizes. No matter how many improvements
we make to the existing view toolkit, it will never
be as easy to adopt these sort of changes
as it is with Compose. In the last few
months, we've been updating our JetNews sample to
really shine on large screens. Let me show you some of
the steps we've taken and how Compose made it easy. The main screen in JetNews
is a long scrolling list of articles. Before any optimizations
for large screens, this is what the app looked like
when scaled to a larger screen. This is not a good use of
the additional screen space, and there was a lot of
room for improvement. Before we're able to make any
changes for large screens, we need to know when our
UI is being displayed in a larger setting or not. To do that, let's
start by looking at how to use the window
size classes from Compose. We've covered the
WindowManager APIs earlier, and we're working on
a Compose integration to make it even easier to access
this information from Compose. In the meantime, we can
create a composable function that handles the integration
with WindowManager. We can reach out for the window
metrics of the current backing activity, and remember them
correctly as Compose State, and then translate those to a
DP size available to the app. Once we have the
available size, we can easily translate it into
a window size class, compact, medium, or expanded. The WindowManager
library will soon expose APIs for the
classes directly, and Compose will have
APIs to do this for you as well, so stay
tuned for those. In the meantime, you can
borrow this integration code from JetNews. Now, that we know how
to gate decisions, let's start like we
did with Trackr earlier by looking at the UI
paradigm for navigation. JetNews doesn't use
a bottom navigation, like we saw earlier, but instead
has a NavigationDrawer that appears from the side of
the modal, when you click on the logo in the top app bar. However, when we run the
app on a large screen, we can see that this UI
just does not fit at all. The modal stretches to fill
the entire screen showing a huge amount of white space. The guidance, like
we saw earlier, is to use a NavigationRail
on large screen devices. Compose now supports
NavigationRail, and all we have to
do is set up and pass our content, the header icon and
the two navigation item icons, one for the home screen and
one for the enter screen, with their corresponding
navigation actions. To integrate the
NavigationRail into the app, we made some changes to the
top level app component. First, we reach out for
the current window size class and gate showing
the modal drawer on the size being compact. Then we ensure we set
up the modal drawer so it only enables
gestures in the size, and conditionally place the
NavigationRail side-by-side with the main navigation
graph, which contains all of the screens in the app. Now that we have a
NavigationRail in place, the next thing
that caught our eye was that the list of articles
doesn't stretch well, and we still end up with a
lot of wasted white space. So we decided to build a list
detail layout on large screens. List detail layout is one of
the recommended large screen canonical layouts
in material design. It will allow us to show
the list of articles side-by-side with
an open article. Building a list detail layout
is quite simple to begin with. JetNews has two
existing components that we will reuse,
PostList and PostContent. Ensuring we break down the
UI like this into components not only makes it
easier to test, but also enables us
to evolve the screen layout without having
to start from scratch. These components don't assume
they have the entire screen space available to
them, and therefore we can now place them in a
different configuration without rewriting them. In order to show the feed
and post side-by-side, JetNews simply uses row
with the two components. The first one has a fixed width,
leaving the second component to fill the rest of the screen. The detail component is wrapped
in a Crossfade animation, this allows users to
interact with the list and see nice transitions when
opening different articles. Beyond the actual layout, to
build a list detail structure properly, we need to solve
a couple more problems. One interesting bit
is thinking about how the app may transition between
different size layouts. For example, when you
have a foldable phone, the app may go from the larger
screen to a smaller one. To properly handle how the
List and Detail panes collapse into a single pane hierarchy
when on a smaller screen, we need to know what pain the
user last interacted with, as that's the one that we
will want to show on top. For that, we implemented
a simple custom modifier that records the
last interaction, and use that further
up the hierarchy when deciding what to
show in a collapsed state. A final big decision
left to make here is at what screen size do we
shift from showing only one of these panes at a time to
showing the list detail layout. In JetNews we quarry
the window size class, as we showed earlier, and
show a single pane for compact and medium, and a list
detail layout for expanded. Now that we have the
UI pieces in place, let's look at what
changes we had to do to get navigation
working correctly. JetNews was originally
built with the home screen and the
article screen having their own ViewModel each. The integration between
navigation and ViewModel implies that there can only be
one ViewModel per navigation route in a graph. But this was fine, as the
two screens were always shown on different navigation routes. However, to restructure the
UI into a list detail layout, we need to take
these two screens and be able to show
them side-by-side. There are two options
we can proceed here. We can either nest the
NavHost in the detail side, enabling a new navigation
hierarchy inside the Detail pane, or we can
unify the ViewModels. Note these options are
not specific to Compose. We would face the same
options with views and SlidingPaneLayout. If we decided to go
with the first option, we would insert a new
NavHost in the hierarchy that contains the Article
screen shown in the Detail pane. With this option,
we could continue to then expand the navigation
hierarchy inside the Detail pane to further
screens, enabling it to operate independently
from the List pane. However, in the case of
JetNews the Detail pane just doesn't navigate further. It will only ever
show one open article without further navigation. We, therefore, decided to
go with the second option, unify the two ViewModels into
one to simplify the structure, and enable both screens can be
shown at the same destination. Notice also how our screen
components structure changed. To enable showing either a
single pane or a list detail layout based on size, we
created three entry points to the home screen. HomeFeedScreen which
displays only the post list, ArticleScreen, which
displays the post content, and the new HomeFeedWithArti
cleDetailsScreen, which contains our list detail layout
showing both the post list and post content. Here's what JetNews looks
like now in an expanded size. Notice our use of
space is much better than before when we had
a stretch list of posts. But beyond the list
detail structure, we've also enhanced
JetNews in other ways. The Interest
screen, for example, shows a long list
of topics, but it didn't make good
use of the space when stretched to
large screen layout. To solve that, we grouped
interest into sections, and broke down the
UI into columns, where there is more
space available. Now's a good moment to
take a step back and look at the different
components that Compose provides to build adaptive UI. We've seen that when we want
to make decision at the screen level, for example,
changing from a single pane to a list detail layout, we
want to use window size classes. But what about decisions that
are not about the screen size? We may want to adapt the UI
in an individual component based on the size that
has available to itself. For example, we may
have a card that when shown with little
space inside a list, it displays only a
title and a subtitle. But when we have more space,
it grows to also show an image. For these sorts of
cases, we can reach out for Box With Constraints. Box With Constraints
behaves like a box layout, but provides an its scope
measurement information that can be used
to make decisions, such as when to show an
additional image or text. In this example, we
are using the max width exposed in the given scope. You should be aware, however,
that Box With Constrains comes with a cost. Unlike most composables, it
can't begin its composition work until the measure
phase of layout, when it can obtain the
size information we want. This may leave your app
with less total time to build and display
the UI inside of it. Use Box With
Constraints when you want to display completely
different content based on available size. If all you want is to
measure and position content differently, with no
difference in what elements are being composed, as
we saw with the shift to two columns in
the intro screen, you can use a custom layout
to achieve the same result with better performance. Check out the Deep Dive
into Jetpack Compose Layouts talk to learn more
about custom layouts. So to recap, for screen
layout decisions, use window size classes. For choices between
different content use Box With Constraints. And for laying out
content in different ways, use a custom layout. We mentioned earlier that
foldables in particular are seeing a huge market growth. Let's look at how to
target these devices with your experiences. Similar to how we reached out
for the WindowManager APIs to access window
size classes, we can easily integrate Compose
with the feature and posture APIs for foldable devices. These APIs tell us when there's
a feature on the device, such as a hinge or a fold,
and whether the device is in a posture, such as tabletop. Compose can easily
observe the state given by these APIs, which
enables great UI transitions across scenarios, such as
a foldable device going from being unfolded flat, to
being folded in tabletop mode. We started exploring this in
our Jetcaster sample, which implements a podcast player. Making use of the
feature and posture APIs, we can detect tabletop
mode, and adjust the UI to display a player
on the top half of the screen and controls on the bottom. To do that, we can detect
the current device posture by reaching out to WindowManager
for the window layout info, tying the flow to
our life cycle, and then mapping the layout
info to different postures we are interested in,
such as tabletop. We define tabletop as the case
when the device is half opened and in a horizontal orientation. Then we use this posture as
data for our composable function defining the player
screen, where we decide between two possible layouts. We take this decision at
the top level of our screen, as our design is significantly
different between normal and tabletop postures. Once again, APIs
in Compose, where this integration is super
simple, are coming soon, so look out for those. Beyond the APIs we've
shown until now, we've been hard at work on
the internals of Compose to enhance our input stack,
including keyboard and mouse support. This is especially helpful
for apps running on Chrome OS, as we're making sure your app
works great out of the box and enabling use cases
across a fast growing market. To know more about
specifics of Chrome OS and input, check out
the Input For All talk. Compose makes developing
adaptive UI from scratch easy, but that doesn't
mean it can only be used in greenfield apps. It's also possible to use it to
implement your larger layouts and reuse existing
UI via Interop. Check out our Interop
guides for more information on how to mix views and
Compose in your app. You can find the
samples we've showcased here and their complete
implementations in the Compose Samples Repo on GitHub. And you can easily import
them into Android Studio. We've also published new Compose
and large screen guidance, and we're keen to see how you
can think about adaptive UI as you start adopting Compose. DANIEL JACOBSON: Now
that we've shown you how to easily update
your apps or build new UI to be
resizable, let's talk about testing and maintenance. We know that maintaining
UI across all form factors can introduce test complexity. We're adding new testing and
automation tools and APIs to allow you to scale your
testing across more device profiles without
significantly increasing the burden of doing so. It's difficult to
own physical devices representative of all screen
sizes and form factors. We sought out to provide
a quick, seamless approach to run existing instrumentation
tests on a variety of screen sizes and API levels
through virtual devices. With Gradle Managed
Devices, you can simply describe the
configuration of devices you want to run your tests
on, and Gradle takes care of the rest, including
device provisioning and test execution to create
a consistent, reproducible testing environment. Simply define devices in your
build script, and add them to a device group, such as a
group of devices with medium and expanded with size classes. Then use the group of
Gradle Managed Devices to run your tests. Because Gradle manages both the
device provisioning and test execution, Gradle
Managed Devices also supports test
sharding, which allows you to split your
tests across a specified number of identical devices,
reducing your overall test execution time. Simply pass this flag
to specify the number of identical instances
of each device that you want to shard
your test across, and Gradle takes
care of the rest. But we know that running a
large number of virtual devices can be taxing on
your CPU and memory, potentially limiting the
usefulness of Gradle Managed Devices and test sharding. To help, Gradle Managed
Devices introduces a new type of virtual device
that is optimized for instrumentation tests,
called Automated Test Devices. These devices run in a headless
mode with disabled background processes and services
that you typically don't need for automated
testing, reducing your overall CPU and
memory usage per device. This will allow you to run
tests targeting multiple devices representing different
screen sizes simultaneously. Currently, ATDs are
available for Android 10. Higher API levels will
be supported over time. And to make sure that
your existing screenshot tests continue to work with
automated test devices, we've updated the
Android X Testing Library with screenshot APIs that
dynamically toggle hardware rendering only when required
to capture a screenshot, ensuring that automated
test devices run as efficiently as possible. While this is a lot of
great functionality for how you run your tests,
we're also thinking about how to help write better
tests, in particular testing your app through configuration
and device state changes in a synchronous way has
always been challenging. And it becomes even more
important to write these tests for large screens and foldables. To help, we're working
on a brand new set of AndroidX testing
APIs that allows you to put the device in
different states or postures. For example, you can
test how your app reacts when the device
goes from being folded flat to half opened, or is rotated
between portrait or landscape modes, all with
synchronization built in. We're still gearing up for a
preview release of this API to first work with
virtual devices, so look out for
announcements soon. CLARA BAYARRI: We've
covered a lot of ground today, from talking about new
design guidance and window size classes to specific APIs
for updating existing apps, such as SlidingPaneLayouts
to support navigation, new UI in Compose, and
overall testing tools to help you scale your UI
to larger screen sizes. Large screens and
foldables represents such a large and growing
segment of Android. To take advantage
of this momentum, now is the time to build
and design UI responsibly, so users on our
most premium devices have a great experience. We're excited to see
how apps can evolve, and what else we can do to help
you seize this opportunity. There's a lot of new
features coming out across material design, 12L,
the Play Store, and Jetpack to help you in your
large screen journey, and we've only
covered a few today. Check out the talks on large
screen updates for Android and Chrome OS, material design,
input, and Jetpack Compose layouts for more details
on specific topics, and our newly released
Large Screen Guide, where you will find everything
we've covered today and more. Thanks for watching. [MUSIC PLAYING]
