Articles Blog

Is Your App Ready For Foldable Phones? (Android Dev Summit ’18)

Is Your App Ready For Foldable Phones? (Android Dev Summit ’18)


Good morning, everyone. Thanks for joining us today. My name is Adrian Roos. I’m a software engineer
on the Android framework ADRIAN ROOS: Team. ANDRII KULIAN: I’m Andrii. I’m also software engineer
on Android Frameworks, and I work on the multi display. JISUN PARK: Hi, I’m Jisun
from Samsung Mobile. I’m Engineering Director. ADRIAN ROOS: So by now,
I’m sure you’ve all seen the announcement
that we are partnering with Samsung to make
foldables a thing on Android. Today, we’re diving a bit
deeper into what that means and what we’re doing to support
new developers with targeting foldable devices and
similar form factors. Jisun is here to talk a bit
more about what Samsung is doing and share more information
about their device. So with that, I’m going
to hand it over to Jisun. JISUN PARK: OK, thanks. Thank you. So again, I’m Jisun
from Samsung Mobile. And I’m going to talk about the
new form factor device which we actually announce yesterday
at the Samsung Developer Conference in Moscone Center. OK. So I will cover more information
about the device itself. And also, we’ll talk
about the experience the new foldable device
will bring to the users. We all know that
the smartphone has been providing new experiences
for the last 10 years. And it actually changed
the way people think, act, and also, communicate. Additionally, It also opened
up a lot of new opportunities for the developers. Now we believe a
foldable phone is one of the next
game-changers, which will provide a very unique
experience to the users and also new opportunities
for the developers to drive innovations. So now let’s talk about the
first Samsung foldable phone. The first Samsung
foldable phone is designed to be a multi-display
with two screens, and also support multi-window
for better experienced user experience. So let’s take our
first to look at what the actual configuration of
the display on the device looks like. So this is the main display
when the device is unfolded. The main display is
large enough to provide a very unique experience. With just more
surface, the experience becomes richer and
more immersive. The experience was
hardly achievable, even from the existing
larger screen smartphones. In addition to the richer
and immersive experience from a single large
screen, true multitasking will become also available
to utilize this larger screen with up to three
multi-active windows. When the phone is
actually folded, we still have very useful and
portable cover display to use. In this mode, the
experience is very similar to your
daily smartphone use. But compared to
the main display, the experience is more
to be focused in handy and click interaction
to actually leverage the small screen. Having said that,
here are some numbers that you may be interested in. This is the specs
and the dimensions of the actual screens. So 4.58-inch cover display
provides 21 to 9 HD plus resolution with the
420 dpi screen density, and 320 dp smallest width. 7.3-inch main display support,
4:2:3 QXGA plus resolution with the same 428 dpi screen density
with 585 dp smallest width. These are the numbers
you may need to know. I will show you
some expected user experience with some examples. Comparing the user experience
between the existing smartphone and foldable main display,
this foldable phone can actually locate wider
and larger display access to the application, and it
actually enables the contents on the screen to be a
richer and more detailed, as you can see from this screen. On the cover screen
when device is folded, I said the experience
can be optimized to provide a quick and
easy access and interaction while the devices
are still fully functional like a
normal smartphone. Access to the kick panel
or notification or call or messages are good examples
to highlight the best use of the cover display. We know that you may not want
to just unfold your phone to take an incoming call. While the cover display
and main display, each one provides its own very
unique experience by itself, the experiences between them are
not separate nor disconnected. Rather, the user experience
between the displays is very continuous and
connected seamlessly. As an example, if
we want to search for the location of
Moscone Center from a map, you can do that with
your phone folded. However, if you
unfold your phone, the application still
continues to run. Even more, unfolding
the phone actually provide more information
with more visual clues like what are nearby,
and what’s the location to the other point of interest. Using the Gallery
app is similar. The app experience continues
between the folded mode and also unfolded mode. Multi-active windows
for multitasking is also one of the key features
of the Affordable iPhone. While watching a
YouTube video, if you want to browse a website,
you can just open a browser and browse the website while
your video keeps playing. Moreover, if your friend
actually sends a message, and the message notification
pops up, what you can do is just to grab the message
and drag it to a third window like this to continue
chatting and browsing while your video keeps playing. So we have discussed
the expected experience with the new affordable device. So now Adrian from Google will
talk about developer guide and also, some Android
platform [INAUDIBLE] support to make your
applications better fit for the foldables. ADRIAN ROOS: Thanks for
sharing that, Jisun. [APPLAUSE] So let’s talk a bit more about
how you can take advantage of foldables in your apps
and kind of the guidelines that we would commence to do so. So first up is
screen continuity. Screen continuity is what we
call the concept of continuing what you’re currently doing
after you fold or unfold the device. For example, you
have a map you’re looking at on a
folded device, and you would like to see maybe a bit
more about the surroundings of the place you’re looking at. So as a user, you
unfold the phone. And with a continuous
experience, you are still looking
at the same place, your state is
maintained, and the phone can take now a bit more
advantage of the form factor and show you more about what’s
going on around this place. And this is actually not really
a new thing in Android, right? We’ve had to deal with
similar situations before where things like screen
rotation or changing screen sizes– or sorry– changing window
size and multi-window. So why should you
care about continuity when you build your app? Well, users unfold their
devices for a reason. And usually, that’s
because they want to dive deeper into the task
they’re currently doing. So that really works
best when they are not interrupted in their
experience in doing so, and can continue where they
left off before unfolding. So for a satisfying
user experience, it’s really important
that this works well. That seems great. So now how do you
actually pull this off? Well, as I said, Android
is familiar with this, and we’ve built a
configuration change system to deal with that. Folding and unfolding
the device will be treated as a configuration
change in the screen size and screen layout categories. And to support you with that,
the Android system by default recreates your activities when
a configuration change happens. This has the advantage of taking
care of any layout changes you might want to make
when taking advantage of the new configuration. But it also means that you
are responsible for restoring the state the user was in after
the activities we created. To support you with that, we
have to on$aveInstanceState facility, and we’re also
introducing a new Jetpack library called ViewModel
to support you with that. Alternatively, you
could also decide to handle the configuration
change yourself by just applying it and
adjusting your layout. To do that, you can
declare that you can handle the configuration
change in your Android manifest. But that means that you’ll
have to manually adjust the layout, the new screen
size, and new configuration. And for the best
experience, make sure to correctly implement
multi-window and declare your activity as sizable. Now, next stop, we’re
making some changes to the lifecycle
in multi-window. You can see the current
behavior on the left. And that is that only the
activity that the user last touched is in the resumed
state, while all the others are in the past state. Now that’s a bit
confusing to users because it’s not immediately
obvious why one activity is a bit more interactive
and the other activities are in a less interactive state. And it’s also one
more thing you have to keep in mind as a developer
when you target multi-window. So to make things simpler, we’re
introducing multi-resume mode. And multi-resume mode,
it’s pretty simple, really. All the activities
in multi-window that are at the
top and are visible are all in the resume state. Now, Android Pie didn’t
ship this with this behavior originally, and so we’re
making this an opt-in behavior in the Android Pie. It will only be applied if
both the app developer opt in and the device
manufacturer actually implements this feature
according to our spec. But note that in future
versions of Android, we are expecting to make this
behavior the mandatory behavior across all apps and
devices that run on the next version of Android. So let’s say you have an app
and want to take advantage of the simplified lifecycle. How do you opt in? Well, again, it’s pretty simple. You add this one flag to
your Android manifest. There’s one caveat, though,
because there are now multiple activities that could
be resumed at the same time. It could also be that it’s
more than one activity from your apps process. And so be really
cautious around code that stores the one resumed
activity, because there might now be more than one of those. And also be cautious around
libraries and frameworks that might make the
same assumptions. And with that, I’m
going to hand it back over to Andrii, who’s going
to talk about multi-display. [APPLAUSE] ANDRII KULIAN:
Thank you, Adrian. So let’s talk a bit more
about multi-screen devices. So as you know,
starting with Android O, an activity can be launched
on a non-default display. Let’s see what it actually
means for your activity. First of all, when an activity
is on a non-default display, it means that the
activity context, which is a visible
entity, is different from non-visual application
context also available from broadcast receivers
and content providers. The context of a
visible entity will be always adjusted for the
display area where it is shown. For example, if you use the same
API to get the current display, and use different context
types to ask for it, you will get different results. The current display you can
get is from the activity. And the application
context will always give you the default display. Different contexts also
mean different resources and configurations. They will be automatically
updated for you. All you need to do is
just to request them from the correct context. Usually, when you want to
adjust your you UX for metrics of the currently
available screen area, you should be using an activity. Keep in mind that a user may
move your activity from one screen to another at any point. In most cases, you
can expect displays to have different sizes,
densities, and resolutions. This means that an
activity that was moved will probably get the
configuration change, as Adrian has covered before. And if declared to
handle the change, it will be notified
with the new config. If not, it will be relaunched. To deliver the best possible
experience, both for foldable and for multi-display
devices, we really encourage you to handle
configuration changes whenever it’s possible. And if your app
really needs to know what display it is
currently on, you can check in onCreate and
onConfigurationChanged. These are good
points to do that. So what if you want
to take advantage of these additional screens? How do you use them? So the first step
is to actually get the list of all displays that
are available in the system by checking with
display manager. The displays will have many
different characteristics. So you can check their
flags, metrics, and state to find the one that
suits your needs. For example, you can
look for a live screen to present your media content,
or filter out the displays that are currently off. One you have determined what
display you want to use, you can launch activity there
using the activity options API available in
Android O. Remember that all existing intent
resolution and launch mode rules still apply. So for example, if you want a
new instance of an activity, you may want to use
corresponding flags in Android manifest to allow
multiple instances and use new tasks
for this launch. Sometimes, the system may
restrict activity launches to some certain displays. For example, private displays. In this case, a call
to start an activity will throw a security exception. You can expect this and wrap
the start with [INAUDIBLE].. Remember that there are
several platforms that actually have multi-display devices. Phones with different
screen configurations is just one example that
we have covered today. Next, there is desktop mode,
when you connect your phone to a larger screen for improved
productivity or entertainment. Another example is Android
apps running on Chrome OS. In both of these cases,
the apps are usually running in free-form
windowing mode, and the user expects them to be
freely and smoothly realizable. Last but not least is
automotive Android. There may be many
screens in the car and multiple users
may be interacting with different displays
at the same time. For example, kids
in the backseat may be playing the
same or different games while the driver is
using navigation. For apps in general,
there shouldn’t be too many differences on
what platform it’s running on. To verify your app behavior,
on any Android device running O or above, you can
create a simulated display through developer options and
launch your activity there. Unfortunately, at this
moment, simulated display does not handle touch. We are working on improving
this experience in the upcoming releases. And we are going to be
adding new developer tools. With all these new and
existing platforms, you can choose to simply
optimize your app, or build some unique
multi-screen experience. You can decide whether you want
to support multiple activity instances, test your app, and
set corresponding launch modes. Don’t forget that in this
case, multiple activities may be focused and receive
user input at the same time. Also, consider using the
shared source of data with multiple view
models in your app, and take advantage of other
architecture components. [INAUDIBLE] ADRIAN ROOS: Thanks, Andrii. [APPLAUSE] So we’ve talked about
what’s available today. Let’s also look a
bit more about what we’re going to do in the
future to support you with targeting foldable
and multi-display devices. In the short term– this applies mostly
for Android Pie– we’re working on
developer guidelines, and we’re going to show you
how to best target foldables and multi-display devices. We’re also working
on a blog post that’s going to go live in the
following days which we’ll have more information
about everything we talked about. And we’re also
working with Samsung to release an emulator where
we can develop and test your apps against the
configuration change behaviors and the
multi-resume behaviors that their device
is going to have. Looking a bit more
into the future with future versions
of Android, we’re implementing support
in AOSP for foldables and mounted display devices. And as part of this,
we’re also going to improve the AOSP emulator
so it will have support for assimilating all those
foldable and multi display behaviors as Andrii
also mentioned. Finally, some pointers on where
you can find more information. In the following
days, as I mentioned, we’ll have this blog post up. There’s also a
Samsung developer site where you will find more
information about Samsung’s devices and their guidelines. And for testing your
apps, the Samsung emulator will also be available on
their website sometime in Q4. OK. At this point, I would
also like to thank you for all the amazing experiences
you developers are building for Android. And we’re really excited to
see what you will do next and what you will create
next on this new form factor of foldable devices. Thank you. [APPLAUSE]

12 thoughts on “Is Your App Ready For Foldable Phones? (Android Dev Summit ’18)”

  1. What I don't understand is, why is it not folded the other way, so that they used half of the big screen as normal phone form factor instead of putting a second screen to the other side of the device?

  2. What if I have a network request going on and user decides to fold or unfold the device, will it cause memory leak or do I need to take care of that situation on my own?

Leave a Reply

Your email address will not be published. Required fields are marked *