Hi, my name is Andrii.
I'm a software engineer in the Android Framework team.
I work on foldable, multi-display, and large screen devices.
And this session is about different displays supported by Android
and how you can make your application work great
on the current and next generations of the hardware.
Let's dive in and see what's new.
We will take a look at different possible screen and window features,
explore design challenges with products in the market
and on the horizon,
and take a look at some of the new tools and APIs in Android 11.
When designing an Android application,
you would probably think about these three categories:
phones, tablets, and desktops.
They would roughly form three different categories of screen sizes
that you could focus on.
Users interact in different ways with each one of those
and often have different expectations.
For example, when using an application on a tablet,
the users would typically hold the device further away,
and they can naturally expect having larger UI elements
to make it easier to see and to touch.
Today, foldable devices erase the boundaries
between those categories and blend them into one--
a single device that will be used
in different configurations through the day.
The same screen can become bigger or smaller
and the user would like to see the application
working great in every state.
From one hand, the users would like an app to preserve its state
after folding or unfolding,
to continue their flow from the same place.
On the other hand, changing the state of a device
is a signal that the user wants more convenience
than the previous screen size would allow.
Also, foldable hardware introduces visible folding lines or hinges
that create a natural separation in the screen space.
Let's take a look in more details.
One of the nice features on foldable devices
is being able to magically make the screen larger
for a more laid-back or immersive experience,
or to allow more room when it is needed for productivity.
This gives a lot more screen real estate
than you would typically have on a regular phone,
and it creates a lot of opportunities for your application.
If you only think about phone interfaces,
you would normally try to declutter
and minimize the number of presented elements.
However, on the large screen,
something like this would not be the best use of space.
A resized phone interface
would have a lot of empty spaces between elements.
And since Android's resource management system
would automatically try to keep the UI element sizes
as close as possible to the original reference design,
individual buttons, boxes, or texts can look relatively small.
You can think of different ways
of how you could use the space.
For example, you could consider increasing the individual element sizes
for large screens
or give users easier ways of navigating between different screens
with the master-detail navigation pattern.
Or you can provide easier access to the features that users will love
by assigning the available space for shortcuts.
This can reduce the depths of the screen hierarchies
and avoid occluding the main content or area where the user was focused.
Sometimes, you will need to take the hardware properties into account.
In most foldable devices,
the hinge mechanisms or folds in the screen,
can create logical separations
for how the user perceives the screen space.
On some devices, a fold in the continuous display surface
may not be as noticeable,
so you can optionally use it as a separator,
depending on the angle of the hinge.
For example, if the device is flat and the screen is continuous,
there is no reason to treat it in any different way
than the regular non-foldable screen.
But on others, there may be two physical panels
connected with the hinge.
An application can be expanded across both panels,
and some content in the middle may be distorted or occluded.
While this may actually be a desired state for media content,
it also creates a challenge for things
like horizontally laid-out text or interactive elements.
In this case, it'll make sense to split the content into two containers.
In previous examples we've seen, how your application can take advantage
of the space and separate, based on your desired UX.
In this case, though, this separation will be dictated
by the hardware properties of the device itself.
At the same time, this challenge also creates
a lot of opportunities for creative solutions and experiences.
Once again, you can think of applying the traditional master-detail layout,
or choosing to separate
based on different types of your content or features.
Or you can place the visual content separately from the interactive elements
on different parts of the screen in your app.
This works well for media applications, and it's great for games
where the players will no longer need to block their view with their fingers
if the controls are separated.
The extra screen space gives you an opportunity
to have a constant game controller without impairing the core visuals.
Depending on the type of your application and your content,
the same principles of separations
can also be used on continuous folding screens
if the hinge is at an angle, creating a logical space for the user.
And remember that you can apply the same
on large screen devices--
just organize the content button.
Once again, when you are designing for foldables,
you are effectively designing for the whole ecosystem
that includes Android tablets and Chrome OS devices.
Now, how would you know about those folds, gaps, and hinge angles?
Great question.
I am pleased to introduce you
to the brand new Jetpack WindowManager library.
It is a place where we will be developing new APIs
for foldable devices,
and also providing you a consistent API surface
across different platform versions
for some of the new and existing windowing features.
The library will give you information
about the layout of different display features
within the bounds of your window, like folds and hinges,
and also about the current state of the hinge.
You can either request the current placement
and angle of the hinge
or subscribe to a listener to be notified when the user folds or unfolds the device.
The library is already publicly available
in the alpha channel in the Jetpack repository.
You can check the quick overview by following this link
and test it on a device, like Samsung Galaxy Z Flip.
Support for these features in Android Emulator
is also coming soon.
But in the meantime,
if you don't have access to the foldable hardware,
you can provide your own mock implementation
of the foldable configuration in the Jetpack library itself.
This way, you can emulate any foldable device
and use it for both manual and automatic testing.
All right, back to design patterns.
Another way to use more screen space is to multitask.
Our data shows that the larger the screen is,
the more people use multi-window,
and they would love to see your application adapting to the space
they dedicate on the screen.
At the very least, you can make sure that your application window
is resizable and handles multi-window.
In addition to that, you can implement features
like drag and drop and cursor support
which will help not only unfoldables,
but on desktop environments and when operating with a stylus.
Remember that the user can connect their phone to an external screen,
and they will likely expect the app to work just as good
in a freeform windowing environment,
and with keyboard and mouse.
Another way to use the larger screen real estate in multi-window
is to have multiple instances of your app running at the same time.
Think of working on two documents next to each other,
or having multiple email composition windows up,
or something totally different, like having two conversations
with different people open in your messaging app
to make contact switching much easier for users.
In this case, non-visual things like
will remain singletons and shared,
while visual entities, like activities,
will be created for each window of the app.
Visual instances could be in different positions,
sizes, and configurations.
They can even be on different displays.
So make sure you're using the right visual context
for [wording] resources and inflating your layouts.
This all may seem like a great variety of states to consider.
You need to know the bounds in which you design and develop.
Android Compatibility Definition Document
provides information about possible Android device configurations,
including screen sizes and window sizes in multi-window.
With regards to the smallest possible dimension,
an activity window can be made
as small as 320 dp when running full screen,
with at least two inches of physical width
to allow enough space for touch targets and bottom navigation room.
In multi-window, it can be made even smaller, down to 220 dp
of the smallest dimension in split-screen or floating windowing mode.
And the aspect ratio can vary from narrow and tall,
to square, to very wide and short.
The best practice is to respect the user's choice
and implement an adaptive layout
so that the user will be able to resize and place your application window
according to their preference.
However, it is not always possible to make your UI work
for every imaginable configuration.
You can set some reasonable restrictions on your window's aspect ratio and size
with existing Android manifest flags.
Consider using them instead of marking your activity as non-resizable
and locking the users in the single size.
And those manifest flags can be used for just the opposite,
to give Android a signal that your application
can support an even greater variety of configurations
than typically allowed by the system.
For example, on some devices, there can be a small additional screen
on the rear side.
And if it makes sense for your app,
you can declare support for very small window sizes
using the same aspect ratio and size flags.
For developers, the advice is the same as before,
code to expect runtime window size changes
and test and declare support for resizable windows.
This will not only make your app work well on foldables,
but also on hundreds of millions of existing large screen devices
running Android and Chrome OS.
We understand that the new foldable devices
are still rather expensive,
and getting all kinds of hardware is difficult.
So we continue investing
in the tooling and developer environment.
Support for multi-display in the Emulator is in the stable Android Studio channel,
which can help you with testing various screen size configurations
or changes at runtime.
Running your application on a secondary display
is also a good verification
on whether you are using the Context and Window Manager APIs correctly.
We are also adding a dedicated emulator target
with native freeform windowing environment.
The windows in this mode are freely resizable
and movable on the screen,
just like on a desktop.
This allows testing various window configurations
and runtime resizing.
It also means that you don't need a Chromebook to test your app
if you would like to deliver a great experience on Chrome OS device.
And a small sneak peek:
we are also working on extended support for foldables
in the emulator system,
which will allow closer representation of different hardware configurations.
We are integrating it with the hinge sensor API
and support for Jetpack Window Manager features.
And you will be able to control the hinge state,
receive updates in your application,
and see how it will look like and feel like
on the flexible screen at the same time.
To make your life easier in Android 11,
we deprecated some of the most confusing APIs
related to Displays and Windows.
Things like display size and metrics don't make much sense in the world
where you need to know about the size of your window,
both when it is fullscreen and floating around.
We are also getting rid of
which didn't scale well past single-screen devices
in the beginning of Android,
and it would return an adjusted value
that corresponds to the current context window size
for compatibility.
Instead, if you want to get the current display,
you can now get it directly from context.
Since context can be visual and non-visual,
calling this an activity will return a display
on which it is currently shown.
While calling it on a non-visual context, such as an application,
is not allowed and it will throw an exception.
For non-activity windows,
you can create the context for the window type you're interested in.
And, finally, to get the size of the window
we introduced a new dedicated class called
WindowMetrics
of the window on screen,
as well as currently applied insets from system windows,
decorations, or physical display properties, like cutouts.
Like many things,
So to get an instance, make sure that you use the right visual context,
such as the current activity.
There are two methods:
CurrentWindowMetrics
according to the window and system state at the moment.
MaximumWindowMetrics
of the largest potential area the window might occupy.
As an example, for activities in multi-window mode,
the maximum metrics returned are based on what the bounds would be
if the user has expanded the activities task
to cover the entire screen.
We realize that you will need more than just an API
in a new Android version,
so we are working on adding
to the Window Manager Jetpack library
and make them accessible on older Android SDK targets.
Behind the scenes, we are also adding a selection of new warnings
in Lint and StrictMode
about potential incorrect use of context
for some other Window Manager APIs.
For foldable devices, specifically,
we are also adding a new hinge angle sensor type in Android 11.
It can give you a reading of the current angle value in degrees.
For example, you could use it to provide custom animations
when the device is being opened or closed.
Do consider, though, that listening to sensor readings continuously
can be expensive for your battery
and that the accuracy of the sensor
may vary significantly on different devices.
Some may only report two values from the ends of their value ranges,
like fully opened and fully closed.
Also keep in mind that the value range itself
may be different depending on the type of the device.
Folding devices, like Samsung Galaxy Z Flip,
will determine values from 0 to 180 degrees,
while ranges on fold-down devices with screens on the outside
can start at 180 and go all the way to 360 degrees.
Therefore, we recommend using the hinge state API
from Jetpack Window Manager library
to learn about the state of the hinge in an easy and efficient way.
I am so excited about this!
We have looked at different possible screen and window configurations.
We have checked new challenges and opportunities
that the innovative hardware brings,
and we have taken a first look at Jetpack WindowManager,
new tools and APIs that Android 11 brings.
Thank you so much for watching this session.
Hope it was worth your time and you learned something useful,
or a little bit of my excitement about the future of mobile.
Can't wait to see what you build next.
'Til the next time.