Tip:
Highlight text to annotate it
X
>>Daniel Sandler: Hi, everybody. My name is Dan Sandler. I'm here to talk a little bit
about Daydream. Oh, I recovered that slide so we're ahead of time. Good.
I'm on the system UI team, which is part of the Android platform team, which is what exactly
is -- it's typically made up of two pieces underneath the hood -- and if you haven't
built your own RAM because you don't live in a cabin in the woods, you may not be familiar
with these. One of them is the launcher -- you've probably seen that -- and the other one is
everything else. So system UI covers basically the launcher
plus all the other pixels on the display that don't belong to the app, notifications, navigation,
gestures. I see we have an obsolete screen shot here.
I'll put that away. And in Android 4.2 we brought in something
called Daydream as part of the system UI. It's a screen saver essentially. So why did
we bring this in Android? To understand where this future comes from you have to go back
-- set the way-back machine to 2009 and the Motorola Droid or Milestone depending on your
locale. A great little device, built like a tank. I remember when I thought this was
a huge phone. And this was -- we're really excited to launch
this with a number of really cool accessories. It was the first time we had done this with
a Google-involved Android phone. We had the desk dock or the multimedia station.
We had the car dock. We did not ship that one.
[ Laughter ] >>Daniel Sandler: But what all these have
in common is that they invoked a dock mode in the platform which is new to Eclair. And
what happens in dock mode is you launch dock apps. What is dock apps? Well, in case you
haven't seen it, here is a screen shot of the beautiful Eclair dock experience which
was built into the desktop application in Android 2. And it's got all kinds of great
features. Look at all this stuff. It's got your next alarm. It shows the date. You can
see your wallpaper through it. It shows the battery right underneath the real battery.
You can switch it to night mode so it doesn't blind you or the person next to you while
you're sleeping. It shows the weather and then it has all this other stuff, these crazy
little buttons at the bottom. So you can go to the alarm because you need to change your
alarm. There was a slide show button that did something
weird in gallery. There was a music button that did something else. And what is this
doing here? Why do we have another home key again not so far from the main home key?
Well, we decided that if your phone was in a dock that the most important button on the
device should take you back to that dock app experience so it's really convenient too,
but then you needed a way to actually get home so we added this whole rigmarole. What
a mess. And I should mention we discovered when we
were building this that if you show this great glanceable information on a dock for hours
at a time, say while you're sleeping or while you're at work, it can actually burn into
the LCD or the OTA screen. How very 1990s, right? So we had to implement a screen saver
into the dock application, and every other dock application would have to do the same
thing. We toned it down a little bit in Honeycomb
and ICS, but dock apps has basically been the same since then. Most of the code inside
it is not dedicated to showing the time. It's not all that hard. Most of the code in there
is to give you a way to get back to the launcher, to handle the screen saver timeout, to track
the power status of the device. There's a whole bunch of fussy way clock things you
have to do to be a well-behaved dock application, but the basic idea was kind of interesting.
Dock apps are like bow ties. They're cool. You have this customized user experience for
a particular situation. I've set my device in this little box that is going to make it
do something different. It's very easy for me to just drop it into that dock and get
a cool experience, full of this glanceable, sort of ambient information that is otherwise
not appropriate to show on your device because you want to save power and it's not plugged
in, so you turn the screen off. But dock apps were pretty annoying, too. We
had to do this whole home key capture thing. We got a bunch of feedback from users that
it was confusing, that they couldn't go home when the device was in a dock or that they
had to figure out and learn whether to actually support that. And it required you to shell
out 50 bucks for a special piece of hardware just to have the privilege of being able to
use this dock application. Or like my friend Jeff in the Cambridge office, you can build
your own. This would be back to the cabin in the woods department. It had some nice
features. He put in an NFC button so it would launch his favorite application when he put
his Nexus S in there. It sunk into the charger at the bottom, went with any decor. It was
very nice. But the developer experience for this was
awful, too. Not just confusing for users, but as a developer now you have decide, okay,
am I going to take over the home key or not? And if I do -- if you don't take over the
home key there's no way for the user to get back to your application so you've got to
do an ongoing notification, which is gross for other reasons.
By the way, I'm also the notifications guy, so I don't like those ongoings.
And then if you do decide to take over the home key then now you need to allocate space
in the UI for a launcher button, which if you're trying to create a delightful experience,
it is not the first thing you want to do. So as a developer you have to deal with the
whole issue of way clocks. If you put your device in the dock, it goes on the charger
and if you want a nice dock app it's got to keep the screen on. So you've got to hold
a way clock, but now you have to watch and see if the device is removed from the dock
and remove the way clock and all this kind of stuff. And then you have to deal with the
whole screen saver thing so you have to implement your own idle timer, which means you have
to duplicate the idle time and functionality in the system. It's a mess.
We wanted to do something better for developers. We wanted to do something better for users.
That's where Daydream comes from. We kind of introduced it quietly along with Android
4.2 last fall. There was a blog post about it later -- late in the winter to sort of
describe it. We haven't really talked a lot about it, but that's what I'm here to do today.
Features of the Daydream -- the Daydream API is they should be really easy for developers
to write. It should be a fun afternoon project for you to sit down, take existing pieces
of your apps UI or build something completely from scratch and have something running quickly.
They need to be launched automatically for the user just like dock apps did so it's easy
to get into this feature. We want to offer the full API available to
Android applications. Any way you want to draw, any way you want to interact with the
users, Daydreams should allow you to do it. And we wanted to give you a whole bunch of
other stuff from the platform to make writing this whole thing a lot simpler.
So Daydream is a feature that the user will encounter when? Well, while docked. If the
user drops the device into one of these things, Daydream will start automatically if this
little button is ticked. The second option allows you to Daydream more like a screen
saver, so any time it's plugged into something that will charge it, your device will idle
out. Instead of into a screen that is off, it will idle out into Daydream. So Daydream
basically replaces the screen off when the device is charging if you have that second
button ticked. And the third radio button will allow you
to cover both cases. The default for Android 4.2 is just while
docked so that people aren't surprised by this new behavior, but this is where you would
go to inside settings and display to change the way that Daydream starts up.
Daydream will not, however, automatically start if something is holding a wake lock.
So if something else, some other app is keeping the screen on, Daydream isn't going to automatically
turn on after an idle timeout, which I told you Daydream is supposed to replace screen
off so this sort of works. This follows those rules.
It also works really well because apps that hold the screen on like that are sending us
a really strong signal. They do not want to be obscured. The user is looking at this.
Even though the user is not touching it, the user is not tickling that idle timeout, the
app should continue to be visible by the user. So video playback is the canonical example.
Other dock or kiosk apps sort of bespoke experiences where the user might not be interacting with
it for awhile, but it needs to keep that screen on and not obscured. Again, they hold a way
clock, Daydream won't trigger. Finally games. Most games are interacting
with, so it's not a problem, but if there were some kind of game where you were going
to stare at it for a very long time -- maybe it's an eye-tracking game, I don't know -- if
you hold a way clock, Daydream isn't going to start on top of it.
So I said that Daydream should be easy to write. This is essentially the core of the
implementation here. Step 1, extend DreamService and Step 2, go nuts. Do whatever you want.
We'll get back to lots more code examples in a little bit, but right now I want to draw
your attention to we've got a method on dreaming started and we want to override and set a
content view just like we were in activity and then whatever you want to do, you're free
to do that until the Daydream ends. So you might ask okay, if this is so much
like an activity why not make an activity? Why make it a service?
We tried it internally or we thought internally to build the whole Daydream infrastructure
just based on plain old activities. It didn't work so well in practice. There
was a bunch of bookkeeping that you had to do just like a dock app. So we weren't saving
the developer a whole lot of work. Card manager had a hard time keeping track of this so it
could be automatically started and stopped when you docked and undocked the device, things
like that. And the most important thing is that you were
running in the wrong window layer. If you imagine Android, there's the wallpaper and
there's a bunch of applications and a bunch of systems stuff like the status bar and dialogue
boxes. Those activities are running in the middle. So if a dialogue box comes up it's
just going to sit there on top of an activity indefinitely.
So if you have a great screen safer and an OTA dialogue comes up, that's going to be
burned into the device by the next morning, so that's not going to work.
Getting back to the features of Daydream, I said that once you had set up your content
view and triggered on dreaming started you can basically do whatever you want, and that
includes this entire suite of layouts, widgets, however you want to interact with the user.
Like I said, it's basically the entire Android UI toolkit is available to you in a Daydream.
And I want you to take a look at the way this contrasts with the other things that we've
allowed you to do as sort of these kind of customization tools.
So app widgets, for example. If you implement a widget for the launcher it's the same kind
of glanceable information, right? It's there kind of when the user happens to be looking
at the device, maybe is about to do something else. You can show the weather, time, what
have you, but you really only get those top two bullet points and even then it's a little
weak. You get some of the standard layouts, you get some of the widgets, only those that
have specially been marked to be viewed as remote views. You don't get the full UI toolkit
and you really don't get the full suite of touch interaction either. You get clicks,
that's about it, because everything else is reserved for the app widget host, the launcher,
the thing that needs to be able to move widgets around. So that's not all that rich and exciting.
We also have live wallpapers. We have live wallpapers that let you do kind of whatever
kind of drawing you want to the canvas of the surface that you're handed, but you don't
have access to the rest of the UI toolkit. You can't use views to lay things out. You
can't interact with the user. You sort of get touches, but if you've written a lot of
wallpaper you know it's not all that satisfying. And you certainly can't do this other stuff
like view animation or video playback. So Daydream lets you do all this. Daydream has
access to the complete UI toolkit so you can build really kind of whatever you want.
There are some other freebies. I told you you get free stuff from the platform when
you implement a Daydream. You are automatically started and stopped. You don't have to worry
about that. You don't have to worry about tracking user's idle time. You don't have
to worry about dock events. That's all handled for you. You just look for the dreaming started
and stopped life cycle events. I mentioned you have access to the user's
touch and interaction and so forth and the keyboard, too. If you choose to be non-interactive,
if you just want to make flying kitchen appliances, if that's your thing and you want it to dismiss
as soon as you touch the screen, that's really easy. You say set interactive false and again
Daydream takes care of the rest for you. And finally, you get that crucial special
window on top of the device. I know, I know, there's that other way to get windows on top
of the device. That's gross. Don't do that, do this instead, please.
But I still haven't gotten to the why. Why do you actually want to go and implement this
in your app? Okay, it's fun and easy, but why should I take the time? I'm busy. I'm
an Android developer. I read Reddit. I don't have time for this kind of thing.
So I argue that this is a chance for your app to be free, to finally be free of all
of its features, all of its use cases, all of its menus and its settings, free to be
experimental, free to be weird, free to delight the user.
In a Daydream you don't need action bars, you don't need settings, you don't need fragments.
You don't need all that serious business stuff in your application. This is an opportunity
for you to make the art exhibit version of your app. It's fun.
So okay. This is a developer conference. Where is the code? Here it comes. Get ready.
The first one we're going to do, we're going to build a very simple Daydream. And let me
show this to you on the Nexus 7 over here. I'm going to switch and see if I can do this.
Apparently the answer is no. There we go. So this is not the one I wanted
to show you. So this is the first Daydream that we're going
to build here. It's really, really simple. It moves something around the screen.
I know we talked about this as being very 1990s. This is very 1980s, but it's an important
building block. Any time you build something even more sophisticated, you probably are
going to have some arrow state or some message that you need to move around the screen. You
can just pull this code directly in. So back over here on the slides, the implementation
starts like this: This jumper class, I'm going to extend frame layout. You could do some
other view group or whatever. I like frame layout. It's easy, it's pretty simple, and
allows you to put other stuff inside of it. So jumper is going to be a class, it's a subclass
of frame layout that moves itself around inside of its parent, and whatever you want to put
inside of it, like a picture of Dianne's cat or an error message or fortune cookie or whatever,
it doesn't care. Here is a runnable. Basically what's happening
here is it's looking at the bounds of its parents, looking at its own bounds, picking
a new random spot and then doing it again in two seconds. This is very simple view kind
of stuff. And then when it's attached to window it's
going to fire off that runnable for the first time. So as soon as you put this view into
a window it will start bouncing around. It's important to note -- on the next slide.
On this slide I'll show you the XML for this is really simple. The frame layout for the
whole screen is on the outside and the jumper is in the middle and it will move itself around.
So what is important to note is that there is really nothing Daydream specific so far.
This is like straight up view programming. If you went to implementing your own custom
views earlier today you saw even more sophisticated examples than this. This is pretty straight
ahead. Where is the Daydream aspect of this? Here's DreamService again. I showed you a
little snippet of code earlier that looked like this. Ondreaming started. I'm going to
set content view to that layout that I just described and that's it.
And in fact, I mentioned the very simple activity like life cycle of a Daydream before. This
is how it goes: Attached to window, dreaming started, dreaming stopped, detached from window.
So you can override these things. Most of the time all you need to do is override ondreaming
started, set up a layout and run with it. It's very, very easy.
The last thing you need to do is declare that this is a Daydream, so you can see it in settings.
You do that through the Android manifest like everything else. Inside your application you
have a service mentioning your Daydream, and the important bit here is the action, the
intent filter. Android service dreams DreamService. That's how settings knows how to find you.
That's how the DreamService knows how to start you.
Okay. All right. So this is boring. Let's get a little fancier. So remember I told you
that Daydreams could do anything, including view style animations, right?
So we're going to go ahead and go in here, and this is our old code. You see it does
set X, set Y. We'll replace those with the fluent interface. Now it's animate X, animate
Y. And hey, let's just throw in rotation just for fun. So let's see what that looks like,
and I have that running over here as well. There we go. All right. Now, this feels high
octane. I'm excited about that. I'm not sure Dianne's cat likes that so much. We'll have
to see. Should we keep going and make this more interesting?
Let's see here. I'm going to show you this third jumper example here. So this is the
same kind of thing, just moving itself around with a slightly different kind of rotation
pattern. But remember that I told you that the way
we implemented this is that you drop a jumper view into anything and it will move itself
around in its parent. What that means is we can go and throw more of these in. Like you
want this to be more sophisticated, let's see if we can tempt the demo gods here. Maybe
they've had their fill. And oh, you're not seeing this on the other
monitor. All right. Move. Move our code over there. You can't see that. I can't see that
either. What we're going to do here is I'm going to
add some extra stuff here. So let's see. Wow, I really need a larger font to do this on
the monitors down there. We're going to add some extra views here.
I'm going to copy this one, make another one, add a whole bunch. Doesn't matter.
Let's see here. And then I'm going to get some more of these, too.
So again, the nice thing about implementing this all as basic view stuff is that anything
that works in an activity will work in a Daydream. So we're going to go ahead and see if we can
run this. Did I get any compilers? No, believe it or not.
I shouldn't have tempted them. Let's go back to the Wolf.
All right. Let's go back to the Wolf. There we go. Oh, there we go. Much better.
So just adding more and more views to the parent. Again, daydream doesn't care. Daydream
will let you do whatever you want. We could ship this. This is pretty good.
All right. Let's go back, go back to the slides here.
Okay. So, again, you can pull this source code and maybe with less spinning and use
it as the error message in your own implementation. So that's, you know, a couple of canned animations
in a row. Now let's move on to continuous animations. So often instead of doing something
periodically, you often want something moving all the time in your daydream. There's lots
of ways to do this. I'm going to show you one such.
And this story starts over winter break. This is a little art project I did with my son.
There he is dressed as a pirate. There he is. Awesome. I had him sit down and draw some
snow flakes and a snowman for me because we were vacationing in Texas where there is no
snow. We took a picture of it. We pulled it into a bunch of sprites and then dropped it
into something very similar to the code you've already seen. So I'm going to go ahead and
switch back over here and show you what that looked like. Here was his snow storm that
we can enjoy anytime. So this was nice; right? It turned out really
well and it was really easy to do, again, with daydream and the view animation stuff.
I'll show you who this work right now. So rather than implementing a view that moved
itself around in its parent, now we're going to implement this as a layout that animates
all its children. You can throw whatever you want into this container and it's going to
start falling like snow flakes. And the way we're going to do is using this
class called item animator. Again, there are lots of other ways to do continuous animation.
Time animator is one of my favorites because, again, it feels like the rest of the view
animation API. It's very easy to use. You start it and stop it whenever you want and
then you implement this time listener interface, and you're good to go. So snowy day, attach
to windows starts the animator, detach from window stops the animator. Pretty straightforward
stuff. So what happens in the animator. But first I have to show you what happens
when you add a view. So I told you anything you throw in here gets
turned into a snow flake. Now, if you were doing this for real, you
might have a very sophisticated physics engine going on here. I didn't have that, so instead,
I created a little struct that holds some basic velocity information and I stuffed it
into the view tags. You see right that there, the v.set tag. This saves me the trouble of
having to create a separate model of all the objects.
As soon as the view comes in, stick some stuff in the view tag and we can animate it later.
Here it is. On-time update. This is the thing that gets called back from time animator every
time choreographer wants an animation frame. So basically a v-synced, buttery smooth animation
call-back loop. So here essentially I'm going through every
single of the children, pulling the tag back out, getting the velocities out, incrementing
the view, nudging it along in its simulation, and then putting it back where it belongs.
There's a little bit of code here that is taken out in the slide that allows the snow
flakes to wrap around from the bottom to the top and the sides.
And then finally, there's always that daydream part at the end because everything else that
we've seen before, you can put in any application. Here's the dream service bit. Load a bunch
of snow flakes. Set the content view. Again, this is what you do to set up a daydream.
And then there's one last trick I'm going to show you here, kind of unrelated to daydream
but it's a great little trick. Remember we had all those sprites drawn as white snow
flakes on a black background. I don't actually want those black rectangles floating on top
of each other. I want to be able to see the snow flakes through one another.
Are we going to work out the HDMI switcher here? Here we go.
How are we going to do that? We're going to do that with an extra mode on the paint assigned
to a hardware layer. Here's how it works. We create the ported up extra mode screen
which will create that exact compositing appearance that we want, and then for each one of these
views, as we add it, we give it a hardware layer, use that paint and then put it into
the parent. Voila, you get snow flakes. Okay. So what else can you do with daydream?
So the first thing is we talked a little bit earlier about whether it's interactive or
not. So if you decide you want the user actually to be able to interact with the daydream,
because the default is you touch it, it goes away. Again, flying kitchen appliances. If
you want it to be interactive, you run this one method call and suddenly you have again
full touch input to your daydream. This allows you to do all kinds of great things like the
default daydream photo table that's part of Android 4.2. Hopefully you've seen this. This
is a great way to show off, you know, a bunch of vacation photos, your recent Google+ photos,
and so forth. It throws them all out as if they were photographs scattered on a table
but there's this great ability that if you see one that you want to look at, you don't
have to suffer with it being obscured by other things. You can move them out of the way and
pull them forward. This is a great thing to have on a screen savior. It's something that
can do a great thing when you're not paying attention. But if you're interested, you want
to drill in and pay attention to what's going on there, you can touch and, in fact, more
than one person can be interacting with it at a time; right? You get the full multi-touch
API of Android. So this is a great thing to have in the API.
Something else you want to do is give that daydream a setting. Daydreams love settings.
This is what binds an activity to this little settings button inside the daydream portion
of the settings app. And the way you do that is, in your manifest again, you add this little
bit of metadata. It's very much like metadata for live wallpaper if you've done that, that
points to an XML file where you can point to that activity. Not every daydream will
need it, some are just art projects, but if you have configurable settings, if you want
to make the hours bold or not bold, if you're into that kind of thing, this might be a great
opportunity to do that. Another pro tip for developing daydreams is
to actually use activity. Since the API is so similar, since the life cycle is so similar,
it's very easy to share code between a daydream and an activity that allows you to hook it
up to your IDE for testing. So again, we'll look at the same block of
code we've seen over and over in this talk. You should be able to write it by heart now.
There is the activity version. So these are pretty close; right? Dreaming started on start.
Dream service, activity. And again, you can wire that up to run in
your favorite IDE so that it's very easy to go straight to testing, and then debugging
and so forth. If you factor out your code, you can keep your activity and dream service
subclasses short and then all of the stuff related to your animation, your experience
just goes in one place. Another thing to do is port your live wallpaper,
if you have one. There's no reason not to go and apply it to the daydream API, especially
if you're just drawing into a canvas. If you're doing fancy OpenGL stuff, it's a little more
complicated and we'll come to that in a second. I can quickly show you right now -- well,
that's an early implementation. Thank you, Baron. This is the actual implementation.
By now we have an old screen saver from BOS, if you remember that. It's very simple and
the first implementation was live wallpaper, because that's all we had, but implementing
it as a daydream was really trivial. Again, on dreaming started. We set up everything.
And, in fact, this view you notice I just say new view. The view doesn't do anything.
It's not even a very special view, but all of the logic was built into a drawable. So
the by now drawable is the background drawable of the view, and then we have a call back
to make sure the background drawable is invalidated every now and again. It's really easy.
I mentioned a little bit about OpenGL. If you want to use Open GL in a daydream, you
want to move to technical view. If you are using GL surface view, you may have noticed
it it's pretty janky getting that set up, particularly with window transitions.
Technically, Romain has told me the tech review is the way to go. Please do not argue with
Romain on this. You have to assume he's right on it.
If you go to AFP you can get the source code to the colors daydream, which is a great example
of tech review but OpenGLES2 in a daydream. The last thing I want to share with you is
you can prevent your daydream -- prevent daydreams from running on top of your apps. So I mentioned
at the top of the talk video players, games, kiosks things might not want daydreams to
run on top of them, and the way you do that is you keep the screen on. And there are lots
of ways to keep the screen on, all the way up to managing your own wake lock which I
only recommend -- for no one. So last I want to show you a little magic
trick. I want to give you a clock daydream in zero
lines of code. Almost zero lines of code. For very large
values of zero. But the only code we're going to need is the same block of code again that
we've seen over and over in this talk. I added a couple extra bits here. Set full
screen, set screen bright. Those are just wrappers around basic calls on view. Those
are put on the dream service for your convenience. You don't need to use them. And then in this
implementation I'm going to set content view to my full screen clock, and that's it. I'm
done. So what is this clock XML, this magic clock?
Are you ready for it? Here it is. I'm just going to use the widget that already exists.
So it's part of the Android widget toolkit. It shows a clock. It updates on its own. I
don't have to do anything. Zero lines of code, and it works. It looks just like that.
Hang on. The colon needs to blink. I know it's scope creep. This is what happens. I'm
sure you all know. And I said no code, so how are we going to do it? Any guesses?
No? What is that?
I showed this to Romain and he face-palmed. He said, "You're going to show those guys
that?" So there's this little undocumented task available in the system called blink,
which makes anything inside of it blink on and off once a second. And it works. No code.
So.... [ Applause ]
>>Daniel Sandler: He's going to love that that's what got applause.
[ Laughter ] >>Daniel Sandler: Okay. All right. The code
is done, but I did want to show you some more examples of other daydreams in the wild.
First, there's Google currents, which was -- we worked with the currents team to build
this out based on their UI, and we're really happy with how this came out. It was very
currency, very rich, lots of great stuff to look at. A few things I want to draw your
attention to. One, it's interesting and not distracting.
So it's always moving but it's always moving slowly so there's constantly something new
to be interested in and to look at if you happen to be looking but it's never going
to, like, draw your eye out of the corner of the room.
It's coming direct from Currents, their fresh database of new content so it's never stale,
and it's always interactive. So if you tap on the story and would like to bring up a
full screen view -- again, it's still within the daydream -- a full screen view of that
story where you can read a little more about it, and from there you can either go back
to the river of news or you can drill in all the way, exit daydream, and go straight into
currents. We'll see another example of that in a minute. It's super powerful.
(Saying name) sent me some screen shots from some information about beautiful widgets.
I actually have been using this for a while as my personal charging daydream on my phone.
So I go to bed, I set the phone on the wireless charger and this comes up, which is perfect
because it tells me everything I need to know first thing in the morning, or, you know,
at 3:00 in the morning, including the time, the weather, things like that. It's all live
data coming directly from beautiful widgets. They've got these great visual effects that
would not be possible in widgets, like launcher widgets for the weather, cloud moving past,
twinkling stars at night. It's very future beautiful. In fact the UI is one that wouldn't
really work with as a front door for an app. It's much more artistic, much more free form.
It's perfect for daydream. It feels just right in this context.
They also give you some system status information in the bottom. I will point out if you are
interested in that, you can also show the system you want in what we call lights-out
mode or view.systemui flag low profile which is a way of causing the navigation icons to
dim out and your notification stuff to dim out showing only the battery and the clock
in a lower profile way in the corner. So the user still has access to that battery information
and you don't have to do it yourself, but you can if you want to.
Finally, Flipboard was kind enough to send along a screen shot. Flipboard always looks
great, gently moving full color photographs and stories. And they sent this statistic
that I really wanted to share with you and they were kind enough to let me share with
you. Nearly 50% of daydream sessions, almost half the time that people are running Flipboard
in a daydream, ended with a launch of Flipboard the app. People see the daydream, see a story
they're interested in and go and read more about it. This is a massive, massive way to
drive engagement with your app. If you have a great daydream it is going to drive people
into your full app experience. This is outstanding, outstanding news. I get chills on the back
of my neck thinking about it. It's awesome. So let's wrap this up because I do want to
take some questions. Daydream is supposed to be really easy for
you to write. Very simple, similar to activity, very simple to get off the ground. You get
lots of great stuff for free so you don't have to think about all that stuff, and you
can use any drawing API, any UI toolkit on Android that you like.
It's supposed to provide this delightful glanceable information to draw the user into your app
or just to sort of look great on a bedside table or on a coffee table or on your desk
at work. And it's a chance for your app to have fun. It's a chance for you to break out
of the serious business of all of your action bars and your ListViews and more ListViews,
ListViews and more ListViews. And finally, daydream is there for any user, whether you
have a fancy dock or a fancy charger or just one of these, every user with Android 4.2
can use daydream. I want to briefly thank a ton of people who
have been involved in this feature, and particularly helping out with daydream. In particular,
Jeff, Rachel, Tom, John, and Chris who did the implementation and the design for this
feature. Thanks to those guys. Flipboard and Levelup, thank you so much for
all of your feedback and thank you for your screen shots. Reto, the Android developer
people and the whole Google I/O team for putting on a great show. Thank you to those guys.
And people who had cameos, you can invoice me later. Dianne Matias and Baron, thank you
for your likenesses. Questions can be asked at the microphone right
up here at the front. If you have them, now is the time. If you don't have questions now,
immediately after this talk I will be over in the Android Office Hours pen elsewhere
on the third floor here. You can ask me about daydream or anything else related to system
UI, notifications, navigation, full screen stuff, launcher, floating windows, things
like that. [ Applause ]
>>Daniel Sandler: Go ahead. >>> Hi. Is there any support for loaders for
fragments in daydream? >>Daniel Sandler: Thank you for asking fragments
up front. No, we haven't worked out a really good way to integrate fragments yet because
the life cycle of fragments is so peculiar. It was really opposed to the simplicity for
a daydream. So a daydream had to be, like, one method override it and you're ready to
go. Putting fragments into that hasn't worked for us so far. Quality patches accepted to
the AOSP crowd. >>> And loaders? Cursive loaders?
>>Daniel Sandler: I don't know, if you have specific problems. We don't have any of the
stuff that's in activity to help you manage that stuff automatically so you'll have to
do it yourself. If there are specific things you'd like to see, again, that feedback is
welcome. >>> Thank you.
>>Daniel Sandler: Thank you. >>> Hi. A question about the placer. There
is a section for widgets and for wallpaper. Is it planned to have a section for daydream?
>>Daniel Sandler: I can't comment on plans but that's a nice idea.
>>> Okay. Thank you. >>> I missed the beginning so maybe you already
answered this but basically I'm wondering, like, let's say there are more apps that have
daydream, like how do they get chosen? The user picks which one is the dreamer or --
>>Daniel Sandler: Let's go back over to the tablet.
So this is actually in system settings. So go up here, quick settings. Oh, that's so
convenient. Go into display. Underneath daydream, you get a choice here of all the daydreams
available on the system, and you can select one. You can either run it there to test it
out, or you can set it up, choose when you daydream and things like that and then just
let it turn on automatically. Currently there's no other way for anything
else to change which daydream you have right now. That's a secure setting. That choice
belongs to the user, not to the app, but you can always direct users to this activity.
>>> Thank you. >>> Will daydreams running in the daydream
service, the apps running in the daydream service have access to some of the voice recognition
and voice commands that we saw earlier today so you can talk to your device while its in
daydream? >>Daniel Sandler: I have no idea. That's a
great idea. I don't know. I'd have to check on that.
>>> Okay. Thanks. >>> I think I just had a follow-up on the
discovery questions that have been asked. Do you have guidance on how developers should
encourage or make users aware that there's a daydream feature for their app?
>>Daniel Sandler: I don't right now. So we're still kind of working on that. Having a different
organization in Play Store would certainly help but it's not necessary.
I think right now daydream is definitely being driven by people who already know about the
feature and want to find apps that support it. In terms of somebody who already likes
your app and you want to encourage them to try out daydream, our current sort of guidance
on this is if you already have settings, to have a row there where you say set up daydream
and it will actually take you to this screen right out in settings. And there's an activity
-- there's an intent named for this particular activity that I can dig up. I don't have it
memorized, and so you can direct people that way.
>>> Okay. Thanks. >>> Hi.
>>Daniel Sandler: Yes. >>> One question. So can you use the external
monitor in daydream, like can you connect to an HDMI monitor or --
>>Daniel Sandler: Right. So the secondary monitor API. Yes, you can do that and then
you can draw something different there, or you can draw the same thing.
If you don't do anything in particular, if you're just mirroring the device you will
see the daydream in both places. But again, you can do whatever you want.
So, yes, you should be able to run the display API and draw something different on the HDMI
monitor if that were important. >>> Okay. Thank you.
>>Daniel Sandler: Mm-hmm. >>> Hi. I was wondering, can you take voice
input from daydream state? >>Daniel Sandler: I mean, yes. Well, it was
asked earlier if some of the specific new voice recognition stuff would be enabled,
and I see no reason why not. I honestly haven't tried a lot of those APIs with daydream yet.
I'll check into it. Maybe we'll have a blog post about it.
One more. >>> I was just curious on performance issues.
Like related to battery charging, if the screen is always on or something like that.
>>Daniel Sandler: Absolutely, yes. >>> You leave your phone overnight charging,
so how long does it take to actually charge? >>Daniel Sandler: It dilates the charge time.
It doesn't make it so that you can't charge your phone overnight, and it varies based
on what's going on. This is like dock apps; right? So not only are you keeping the screen
on, you're keeping the CPU on. You may be doing more or less depending on the complexity
of your animation. That's going to be something a developer -- each developer has to sit down
and work our with their implementation. Somebody doing a blinking colon clock animation is
probably not going to have to worry about it, but basically just keeping the screen
on. That's the lion's share of the computation. But if you have a full 3D live wallpaper,
it might be a little different. Now daydream has some additional safeguards
in there to make sure you don't crater your device overnight. So if the battery gets too
low daydream will shut off and the screen will go dark and the device will be allowed
to charge fully. And daydream won't automatically start if you put the device into a dock if
the charge is too low. So in that way we won't ever -- daydream won't
cause your device to wake up with zero charge but it will cause charging to take longer
and that's -- just like any performance issue, each developer is going to have to sit down
and look at that. >>>Is there any consideration to make -- to
sort of link daydream with your alarm set time? So say as you're close to waking up,
the app that you're using to daydream could change its actions when it knows you're about
to wake up. >>Daniel Sandler: That's a great idea. Go
monetize that. Thank you all very much. I'll see you all outside.
[ Applause ]