google

CHRIS MCKILLOP: All right. Hello, everyone. [CHEERING AND APPLAUSE] My name’s Chris McKillop. I’m the engineering
manager for Android TV. I’ve got behind me
here Leo Baghdassarian. He’s the head UX designer
for the Android TV stuff. And Andrew Jeon,
who runs the team responsible for the live TV
integration in the platform. We’re going to talk to
you guys a little bit today about exactly
why we bothered doing Android TV to begin
with and get into a little bit more detail than the demo
we did during the keynote. And we’ll have some more
fun surprises at the end. So some facts and figures. Average American watches
30 hours of TV a week. That is a lot of eyeball time. 120 million smart TVs
are shipped every year, and more than five billion
hours are watched daily worldwide in front of their TV. This is a lot of time
for people to be engaged in content from
Google Applications, from your applications. And these are
computing devices now. These aren’t just dumb panels
picking up over-the-air signal. So but there’s no
standard platform today. This is a huge problem for
Google’s app developers, for app developers
around the world. You either need
to do custom work for every single TV
that ships or fall back to just doing HTML. In-app purchasing
and monetization? Nonexistent on a standard
platform across TV, unlike in mobile. TV looks a lot like
the mobile space did in 2006, where you have
all these manufacturers, all building their own platform,
and all asking app developers to support them with
no unified story. So Android to the rescue. Yay! Established eco-system,
thanks to you guys and thanks to the device
manufacturers out there. A billion-plus
30-day active users, a million-plus
apps on Play Store, 50 billion app downloads. It’s incredible
what you guys have helped us accomplish
over the last few years. We have a huge support
from the industry, both for SOCs and for networking
and across APIs and protocols. And more importantly, Play
Store brings everything together so that you can
do multi-device installs, in-app purchasing, and billing. So everyone can actually make
money off this eco-system. So what is an Android TV? It is just a new form
factor for Android. We’ve announced
several today at I/O, and so I wanted to welcome TV
to the family with you guys. And so going forward, starting
with L and going forward, TV is going to be
supported right alongside phones,
tablets, and wearables. My goal internally at Google
is actually that no one talks about Android TV in a year,
that it’s just assumed. Like no one talks, really, about
Android tablets and phones. Like, it’s just Android. And that’s what I’m
trying to accomplish inside and hopefully
with you guys, too. You know, we’ve added a lot of
great features for developers in L to make it
really easy for you to bring your applications
to the television. So I’m going to really quickly
go through some of these, and then Leo’s going
to jump into UX. We’ve set really
aggressive hardware specs for Android TV devices. We want to make sure
that there’s enough CPU and GPU in the devices
that claim to be Android TVs to have really great
performance for apps and games. Minimum of 1 gig of RAM
and 8 gigs of Flash, so there’s lots of
storage for apps. Wi-Fi and ethernet
for connectivity, so there’ll always
be fast pipes in. Bluetooth 4 and Bluetooth
LE, which I think is going to be really
important going forward, for both accessories and
for things like co-presence and things that could happen. Also wanted to ensure that there
was a very high level of DRM. These are primarily media
consumption devices. Android’s always required
Widevine Level 2, which is fine for SD,
which is OK on a phone. But we require Widevine
Level 1 on all TV devices. That’s already studio
approved in most of the world for HD content. You know, we’re not just
targeting TV panels. I’ve been watching the press
after the keynote today, and a lot of people are asking,
hey, this is just for TVs. We don’t understand. It’s not. It’s also for media streamers. I’m not going to mention brand
names, but media streamers, set-top boxes. And when we say
set-top boxes, we’re talking about cable
set-top boxes– so carriers like
Comcast or BWIG or SFR, who are bringing premium
content over their lines into your house. And also microconsoles,
you’re going to see a lot of boxes that
come with a game controller over the course of the next
year running Android TV. And we differentiate those
from media streamers, both from the point of view
that a microconsole tends to have a higher CPU performance
as well as a higher price, and also not as approachable
because of the game controller. We’re standardizing
input devices across all of Android
TV, so there’s a minimum set of controls. We have a Virtual
Remote control app that you’ll be able to get
off the Play Store to interact with your developer devices
if you request them online. We’re also standardizing on
Game Controller button mapping. We think one of the
biggest problems we’ve had with adoption of game
controllers on Android is the lack of a
standard button mapping. It means that app developers
had to worry about whether it was this
controller or that game controller in their game. No more. So we’re mapping all the popular
ones to the standard for you in L, and we’re publishing a
spec for both game controller manufacturers and
game developers, so everyone can work together. So this will be across not just
TV, but phones and tablets, as well, so it’ll be
really, really powerful. We’re also really pushing
hard on all the hardware OEMs to have microphones
in all their devices. We think that in
the living room, no one wants to
type on a keyboard. We have a keyboard. You notice we didn’t
show it during the demo? No one wants to type on
a keyboard on their sofa. So being able to use your
voice to really quickly get to the details of what you
want is super powerful. We’ve done multimedia
improvements. We’ve added New
Media components. We’ve build a TV
input framework, and Andrew’s going to go into
great detail on that for you in a bit. We’ve switched to
Chrome Webview, and it actually supports
HTML5 video with DRM. So for folks that have
an investment there, you’ll be able to
keep your playback. It’s completely
Google Cast-supported. So all Android TV devices will
also be Google Cast receivers. That means all existing Cast
applications will just work. This is actually supported
by the Cast team. This isn’t a strange
thing the Android team’s doing on the side. The Cat team supports this. And in L, which isn’t in the
preview, but at L release, we’re going to be adding APIs
to allow your APKs to talk to each other through Cast. We’ll call it Cast-to-Native
or Cast-to-Apps. And that means
that you’d actually be able to have first-screen
and second-screen experiences at equal levels. Probably the meat of what we’ve
added for TV in the L release is a new Leanback
framework and launcher. And when we say Leanback,
we’re talking about, you know, you’re on your
sofa and you’re leaning back. And YouTube coined
the phrase as a way to think about how
people want to interact with TVs in the living room. And you’re going to get a
lot of details and background on that from Leo here in a sec. But we’ve added a new optimized
Home screen and System UI. We sort of merged them together. Sort of think of the
notification shade, all apps, and your Home screen all
being in one place on TV. And we’re requiring that
all hardware manufacturers use our launcher. So there will be a consistency
across these devices for developers,
and developers can be guaranteed that certain
behaviors are there. And we’ll get into that
with how the content recommendations work. We’ve also build a
new set of Fragments that you can use to really
quickly take your existing APK and bring it to the television. I think this is the
first time we’ve offered a standard element
in the framework library that operates at such a high level. You can really just
treat it almost like it’s a data-level
API, if you want to. It’s going to be completely
open source with the L Developer Preview. You can go in and change it
around any way you want to. But you’ll be able to really,
really quickly get your app up and running. And for a bonus, for all
you Google TV developers out there– I don’t know if
there are any in the house. But if you want to support
your Google TV v4 devices, our framework actually
works on that. So there’s millions
of Google TV version 4 devices out there,
already installed, and this will give
you a path forward. We’ve also been optimizing for
TV Google’s own internal APIs that you guys get
through Play Services, so things like in-app purchase
flow, Play Games Services, G+ Sign-in. And we’re going to be
going through and updating all of them. So you can use the same APIs
you use on phone and tablets and, basically for
free from Google, get a TV-optimized experience
for your customers. Our studious head of
design, Matias Duarte, who did a great job this
morning in our keynote, always likes to say this when
we start talking about TV. “When your butt hits the
sofa you lose 20 IQ points.” You don’t want to
think about it. You don’t want to use
a computer, right? You don’t want your
TV to be a computer. You want it to entertain you. And so on that, I’m
going to bring up Leo to talk a little bit about
designing for Android TV. [APPLAUSE] LEO BAGHDASSARIAN:
Thanks, Chris. Thanks, Chris. So people love TV. Not the demo yet, guys. When we began
designing Android TV, we looked at the
qualities that made TV so easy and approachable. We notice a few qualities that
made the content unique to TV. Like when you turn it on, you’re
instantly watching something. You’re already in content. And how when it’s
playing, even when you’re looking at a guide or
a menu, it continues along. It continues the experience. And how, at its core,
it really is simple. Browsing’s effortless. It’s just Channel
Up and Channel Down. And on top of that, movies
and TV can be so emotional. They’re so immersive
and engaging. So when we really thought
about bringing Android to TV, we wanted to do just
that, bring Android to TV and keep those content-centric,
immersive qualities that make TV so great. So how are we going to do that? Well, we needed to design
components optimized for browsing and
watching content. One of the most critical
aspects of design is how and where people
interact with it. So with TV, that could
be from 10 feet away, with food or drink in
your hand, or with a baby, and even sometimes half-asleep. For Android TV, we
standardized the minimum button set to the five-way directional
pad, plus Home and Back. There’s no Menu button
and there’s no pointer. So how does this
affect app design? Well, of course,
there’s no touch screen. So you don’t have that
random quick access to different elements
in your interface. So for most layouts, like
on tablets and phone, you’re going to have to kind of
rethink how that kind of gets adapted to TV. With the D-pad, you have
focus-based navigation. You move around by moving focus
from one element to the other. So when you design
your apps, you want to take advantage of
those two axes of direction. Align your objects
in rows and grids, so it’s really intuitive to
navigate inside your app. In the past, Android
had basic support for focus-based
navigation, but today we’re announcing the Leanback
Support Library. This is a collection
of framework components that are optimized to build
fast, fluid apps for TV. They’re focused on
content browsing, with smooth animations and
center-pinned scrolling. So your focus is always
right there, center in view. But we went one step further. We built full application
structure fragments which can be used to
create end-to-end apps. Let’s take a look at the
structure for a typical Android TV-based app. Most successful apps on TV are
content consumption-centric, so they offer media like
movies, music, TV, and pictures. Typically, a user
enters, looks around, and finds something of
interest, either by search or just browsing the hierarchy. Then they get more detail,
like a description or price, and ultimately finally play it. Included in Leanback are these
full app structure fragments, as Chris mentioned, something
that Android hasn’t really done before. These can be used
as-is or customized to suit your app’s needs. They’re optimized for
TV, overscan safe, with fast, fluid animations and
support for immersive imagery. So bringing it all together. Using this navigation model and
the new components of Leanback, we wanted to create
an interface that was focused for entertainment. Thanks to all of
you guys, there’s a ton of great content
in the Play Store that’s just begging to
be on the big screen. But we wanted to go beyond
just the grid of apps. The TV in living room is
about fun and entertainment. As you’ve seen from the keynote,
there is a theme across Android to bring these contextually
relevant notifications to different form factors. And that applies to TV, as well. But these notifications,
they’re not the same notifications
you’re used to. They come as content
recommendations. We wanted a Home screen
that gave you quick access to a blend of content
from the sources you use most, one that
encourages the simple Leanback browsing and
serendipitous discovery. And one that got to know
you and made it easier to access your most-used
apps and games. And ultimately one that
felt immersive and engaging. And with that, let’s
go to the demos. [VIDEO PLAYBACK] -And your job is to
tackle, dismantle– [END VIDEO PLAYBACK] CHRIS MCKILLOP: When
you turn on your TV, you want to see content. So we bring live TV and
movies right to the forefront. If you’re watching your
content and you hit home, like you would do on
any Android device, we overlay that on top
of the live content. These are new APIs
that are coming in L to allow you to
indicate that your app is– we call it gregarious. And so if your app is
gregarious and willing to share its content with the launcher,
it will show through. Otherwise, it’s
going to be hidden. So when you first land in the
Home screen of an Android TV device, you’re going to see
these really rich content recommendations. So these are coming
from apps on the system and are being ranked
and sorted based on the user’s usage
of the device. So we rely on each of you to
provide the right content, based on how you know your
user’s using your application. That’s stuff we don’t know. But we know, based
off the aggregate, how people are
using their device. And so we will sort and rank. I was showing pictures. I was showing Tommy Emmanuel to
Dave Burke after the keynote, and so YouTube’s now
recommending more Tommy Emmanuel for me. And I use YouTube
a lot, so you’ll see there’s actually two
of them on the screen here. Because we know that
I use YouTube a lot. This is my account. This is my personal device,
so if you see something weird, it’s just because
I’m kind of weird. So the goal is that you come
this content recommendation stream, you see exactly
what you want to watch, and you start watching
it, and you’re done. One click to play. But what if you don’t find
something that you want? We decided to make sure
that both search and all your applications are available. So there’s a common pattern
throughout the platform. You go up to search. So if you move up to the Search
affordance on the Home screen, or you’ll see when we
go into the applications that Search is also
in the up position. So you can do Search. So I’m going to use
this, see if this works. It’s always very dangerous
to demo things with Wi-Fi, so forgive me. Let me see. Movie starring Tom Cruise. [DING] Thank you. So pretend this is
my remote control, and I’ve got my virtual remote
that has the microphone button. Hopefully when you’re
using this on your TV, you’re just using the remote
control that’s in your hand and picking it up and searching. So that search exists at
the top of your Home screen. You can go look for content that
you’re specifically interested in. Or you can look for
actors or actresses. And of course, as Dave
showed during the keynote, there’s a ton of ways in
which you can then pivot on both those actors and actresses,
using Google’s Knowledge Graph to find things. I’m not going to
spend a lot of time on Search, because Search
is more of a Google feature and not necessarily
a developer feature. I think it’s much more
interesting to start looking at what happens. How do you actually make
content recommendations? How do you get
into the Apps row? ‘Cause you’ll notice these apps
look a little bit different than you’re used to seeing Apps
on a launcher on an Android phone. We’ve standardized
on a 16×9 poster for doing your
application launchers. You’ll see that we’ve worked
with these first app developers and game developers
to show and set the standard for how
the app should work. Have the text of your name of
your application in your icon. Have it big and bright and
bold and on-brand coloring. And make sure that it has
some movement and contrast. And that’s true in both the
Games row and the Apps row. So you want to know how
you get in the Apps row? So we’re making a pretty
strong statement with TV. We don’t believe
that TV should just be tablet apps on television. And so we actually are
going to require developers to make a few changes
to their application in order to show up in this
new launching experience. So you have to add
to your manifest the statement that
“I support Leanback.” You don’t have to
use our framework, but you do you have to declare
that you support Leanback. And that way the
Leanback Launcher knows that this
application’s going to work for the user that has
a D-pad or a game controller. We don’t want to offer up
applications that immediately say, “Please touch here
to continue,” on a TV where you can’t touch anything. The same goes for games. If you want to be a game, you
can declare yourself a game, and that’s how we sort and
separate the Games and Apps section. You might ask, why
are we doing that? I use a lot of YouTube, a
lot of Play Movies and TV. I’ve been watching
Ted and Showtime. And you’ll see those are all
in the left-hand position. They’re the easiest
for me to get to. I don’t have to think so much. Again 20 IQ points lost
when you hit the sofa. So we make sure that the
apps you use the most are at the left. Games and media
consumption applications have very different
access patterns. They have very
different use models. When you play a game,
you tend to play it a lot for a period of
time, and then maybe you don’t ever play it again. And that’s not true with media
consumption applications, where you’re going in and out
of them based on what shows or what things you want to do. So we didn’t want the games
to get pushed away just because you’re very rapidly
and frequently entering a series of applications. So we promoted them to be
their own top-level entity. So that’s how you do that. So the recommendations come in
through the standard Android notification system. We’ve added some
new tags so that we can tell the difference
between a notification that would show up in
the notification shade on your phone and tablet,
and these notifications. We thought it was powerful
to use the existing APIs and not try to
invent something new, when this would work just fine. Everyone is free to post this. This is a totally
democratic system. And we watch how the user
uses the device and sort and rank appropriately. We’re recommending, I think,
five to ten notifications and content recommendations
from different apps. Leo hates it when
I do this, but I’m going to launch the
E24 app for a second. They’ve done a really great job. And if it’ll load the
content from their app here, I should start seeing
food recommendations, like “order a pizza” in my
content recommendation row. Which is pretty great. You’re sitting on the
sofa, watching a movie, you want to order a pizza. But it doesn’t just
need to be movies. The key to this,
though, is we want these to be one-click access. We don’t want people clicking
on things on the content recommendation row and having
to go through a big flow. So for example, if
I’m sitting here and I want to see
“Now You See Me,” I can click on “Now You See Me.” I’ve been watching
it previously, so it’s going to
resume, and it’s going to kick right
back into that movie. Our networking seems to
be pretty slow in here. [VIDEO PLAYBACK] -And count from one to ten– CHRIS MCKILLOP: There we go. -One two, three, four, five– -Stop. [END VIDEO PLAYBACK] CHRIS MCKILLOP: All right. So I’m going to now dive in. That actually, that
movie’s playing from Play Movies, as you
can see from the the content recommendation. I’m going to go into the top
level of Play Movies now. Play Movies from
Google is probably sort of a canonical
example of a Leanback app, using those Leanback components
that Leo was talking about. This is the
BrowseFragment, which we have set fullscreen
for Play Movies, because we’re happy to
use our own APIs directly. You can see that you can very
quickly move through what we call the fast lane on the
side, which will move you through all the different
content on the right-hand side. You can move over to the left. You notice very smooth
animation, transitions, fade-ins. These all come for free when use
the Leanback framework library. And then you can scroll
through this same content again, but now
with a little more details, with ratings and the
title of the show showing up on the cards, which
didn’t show up in this more compressed form. So if you go into one of
these TV shows or movies– so let’s go into “Silver
Linings Playbook”– this is what we call
the DetailsFragment. It has a background. It has the ability to put
some text and some artwork. Lets you play the trailer
or buy it, and also then have additional browse
rows built right in there. So reusing the same
components that we had from the previous
screen in the Details view, so that users have
a grounding point where they can understand
where they’re coming from. Besides these sort of
two, Browsing and Details, if you have something like
genres, like action/adventure, you might want to throw up
a whole bunch of content. So we actually have a grid
view where you can just put tons and tons
and tons of content. So if you try out
PBS Kids, you’ll see they use that
as their only UI. Perfect for kids. Just all the cover shots
for all the shows for kids, really brightly colored. They don’t need lots
of text on the screen. They know what show
they want to watch. When they want to
watch “Caillou,” they want to go there. And so that works
out really well. Let’s see here. Now in addition, not
in the L Preview, but coming with
the full L release, we’re going to have content
playback controls for you in the framework
library, as well. So Play Movies is using
an early version of this. So if I hit the A button or
the center click on the thing, I bring up the
transport controls. I can fast-forward, I
can rewind, I can play, I can pause. And you also get, just like
everywhere else in the system, you get Browse rows. Let me see if I can actually
get Woody Harrelson’s face on the screen here. Oh, come on. All right, well, I can’t get
his face, screen on face. Play Movies does some neat
things when you do that. But additionally, you’ll
get additional browse rows below the transport controls,
where you can get info cards, you can put up additional
information, reviews. There’s info cards on
the actors in Play Movies that I’m trying
to show you here. It’s not being
terribly cooperative. Oh well. So those transport
controls are going to be coming with the L release. So I want to go through
some different examples now. So that’s the canonical form
of all the different screens that we give you for
free in Leanback. What I’d like to show
you now is YouTube. So I don’t know if any of
you have used YouTube on a TV before. YouTube has a pretty
standard application that they put on smart TVs. And they worked
with us to bring you the YouTube experience using
the Leanback framework. Now they really like
having the fast lane down the side for going through
all the different playlists I subscribe to, and all
the different content. But they didn’t want it
to just be Browse rows. They wanted it to be a grid. So they made that modification
using standard framework components, so that they
could have a grid of content. Because they have so
much content in YouTube, simple rows wasn’t
enough for them. So you can very quickly
move through the content. It still feels like
a Leanback app. It still feels like an
Android TV experience. But they are using
slightly modified versions of the framework. So the TuneIn Radio guys have
supported Google TV for years. And so we reached
out to them when we were getting ready
to do this launch. And they said, well, yeah, we’ll
bring our Google TVA app over, and it’ll be fine. And then they saw all the
apps we were building. They said, well, we want
our app to look like that. And so a week before
I/O, they said, we’re gonna rewrite it all. And so they did. And so they wrote this app
that uses the framework components in one week. It looks just like Play Movies,
which is what you’d expect, because they haven’t had
a chance to go in and make big changes to the app. But it just shows
you that they were able to bring a fluid,
fast-operating application to Android TV, one developer,
I think, in like about a week. It’ll be on Play Store in
the Preview Play Store. Pretty impressive, that they
were able to pull that off. Now the TED guys have sort of
a very distinct set of design guidelines that they want to
use for their applications. So although they’re using
the same Leanback framework that everyone else
is using, they have a totally and radically
different look and feel. So but this is still using
the same Browse-based rows, but they’ve changed
the cards, and they’ve changed the card-to-card
animation, which is all possible. They’ve clipped where the
rows are on the screen so that they can have the
full-bleed art that you see as you go through
the different movies. So it’s completely compliant
with the design guidelines. It’s using the framework. But it looks like
a TED experience. This is one of the big
goals we had for this, was to have that kind of
flexibility for app developers, to both quickly
get on the platform and get [INAUDIBLE] TV,
while also have the ability to make those sort of
customized brand-on changes. And the last one I’m going
to show you is Showtime. Now the folks at Showtime
have a very strong design for their application on TV. This is completely
custom widgetry. So they don’t use any
piece of Leanback. But the Showtime guys
understand living room. And so it’s OK. They’ve written an
Android application that uses low-level Android
framework components to do focus management, but they’re
not using Leanback. But that’s OK,
because they’re fully compliant with the
left-to-right navigation, the up-down browse paradigms,
and everything’s usable with a D-pad. So this just sort of
shows you just sort of the levels and the degrees
to which you can make changes. So on that note, I’m going
to end my part of the demo and switch back over to slides,
and let Andrew come and talk a little bit about the Live
TV integration on the Android framework. Thank you, everyone. [APPLAUSE] ANDREW JEON: Thanks, Chris. So with the framework, we expect
you guys can build as quickly. And then these apps will mostly
serve audio/video content. And then we believe
it could fulfill all the user’s [INAUDIBLE]. But if you think about
it, actually, there are some things bit missing. So if you think about
TV device for TV set, and set-top boxes from
operators, and even streamer boxes, a lot of
people recently believed that the TV experience– video
content, watching experience in the living room– will
move from broadcast TV to online streaming. However the data
shows that still, in many parts of the world,
majority of the time user spends on watching video
content is live TV. So we wanted to
build a framework to support proper
live TV integration, to build a device like this. And as we mentioned in a
previous slide, earlier, there are still hundreds
of billions of TVs and tens of billions
of set-top boxes being produced in
the world every year. And if we want to claim Android
to be an operating system to do the TV and
set-top box, we need to have a framework to
support these kind of devices. So when it comes to making
a TV or set-top box, first problem every
device maker faces is that are a lot of
different TV standards. Like it’s not [INAUDIBLE]
fragmented, but this the one layer of it. It’s only the
broadcasting standard. But if you to look
into more substandard, there are many more. It’s very complicated. And then each device maker
chooses their own solution to fulfill the requirements
for each market, and it only works for
that device types. So we thought that in order to
make Android as an operating system to support
these device makers, we thought we had to have
some kind of good framework. And then in addition
to TV standard, if you look at the
TV device especially, there are a lot of different
physical input ports– HDMI, Component, AV
port, and built-in tuner. So what does that
mean, is people usually hook up lot
of device to TV. And of course, still,
for example, in the US, more than 80% of
the people living in US watches TV from paid
TV operator’s set-top box. What does that mean? It’s that if you look at
your living room today, there are a lot of remote
controls lying around. And whenever you play
game, or play Blu-ray disk, or watch TV– depends
on your activity– you have to pick up the
right remote control. And a lot of devices
are competing against your time
for each HDMI input. So this is quite frustrating. So we’ve been thinking about a
solution, how we can fix this. But we cannot fix
it ourselves alone, so we need some support
from the developers. So let’s take a look
at what we’ve built, so that we can give you
an idea of what we expect as a whole eco-system, including
ourselves and developers, can do to solve this problem. So during the keynote today–
should I press something? It’s stuck. CHRIS MCKILLOP: Tell
them to switch to demo. ANDREW JEON: Oh. So that was not demo. So that was a
screenshot somehow. [LAUGHTER] Sorry, it come [INAUDIBLE],
so I was confused. So you can see the
icon called TV. And if you click it,
you can watch TV. In the Sandbox, if you
visit the Sandbox today, you can actually watch real
live TV over the air upstairs. But here for keynote and demo,
we are using a mock-up demo. Basically we are
using some local Fire to demonstrate
multiple channels. So as we can see, you have
a standard channel banner shows off title of the
program and timing and things like that. And then if you bring
up a menu, these are channels a user has
been watching recently. And it’s been
automatically ordered by the frequency,
and then ranking. We thought user may want
to go back to the channel. Then these are the menus. This is a preview version. We just spent a few weeks
to put together this UI. So it’s going to be much
better in the future. But for now, we have
some essential options. And the one thing I want to
show you is the TV Input menu. So the concept of TV input
is very important to us. We wanted to come up
with a single application to watch every
single live channel. But there are multiple ways
to get live TV sources. So we defined a concept
called TV Input. TV Input represents a method
to provide list of channels. So in this case, we actually
called out Unified TV Input. But in the future, there
will be no Unified Input. TV app itself will run
in a Unified Input mode all the time. But just for now, to separate. And we have three
different TV Input sources. If you go to each one of
them, each one of them will have their own
channels, fake channels. So the first one
has two channels. And then let’s go back. And then the second one,
if I choose the second one, this is to demonstrate
HLS-based stream. This is very common test video. Most streaming content
developer knows about. And then here we just have
three different fake channels. So this shows you each input
can have a different channel. If I go back to
our demo TV input, you can see four
channels, which look nice, because we fake them. It should be nice. So concept is when you
switch different TV input, you can see different channels. But in ideal world,
users shouldn’t have to change input from
HDMI1 to HDMI2 or something. It shouldn’t happen. Or built-in tuner. So the idea is we wanted
to unify all of that. So this mode, Unified
Input, demonstrates how we merge all the channels. So if I go back to
a channel listing, you can see every single
channel from every single input. That’s the concept we’ve built. And this should be the basis
to anything on top of it, around live TV. That’s why I wanted to show. Let’s go back to slides to
talk about it a little more. Slide, please? OK. So this is the UI you saw. I thought it was
alive, but it’s not. So basically, there
are multiple ways that live TV source can
be delivered to user. First of all, many parts
of the world still, over-the-air broadcast
is very popular. You have antenna or
cable to get the antenna feed to your living room
and hook-up, and the scan. Second is paying some
money to a pay TV operator, and they deliver
you a set-top box. And set-top box actually
gets you a live TV feed. Up until recently, cable
operator or satellite was popular, but these
days, IPTV operators are getting more popular. So this second type. Third type is just
purely from IP. And in this case, there
could be a pay TV operator which uses IP, IP TV operator,
or some online sources. But we wanted to be able
to unify all of this, if user has multiple access. Let’s say in some countries like
Luxembourg, this crazy country where you have access to
four different countries’ TV feed, and then three
different types of TV standard, and online service. And people in Europe move
a lot, so Germany people live in France, and they want
to watch a Germany channel. And English people
live in Sweden and want to watch
the English channel. So it’s all mixed. So especially in
Europe, and even in some other part
of the world, people has a demand to watch live TV
channels from different worlds. How we can serve that? So let’s say we unify, we build
a frame so some application, as a plug-in to a live TV app,
can support a live TV feed. Then we just unify
into a single lineup. And then we can filter
them by category or quality or by users’ preference
on top of it. So the reason why I’m talking
to you today is we cannot build this unified channel
ourselves alone. So there are a few use cases. We can get some help
from developers. First use case is let’s say
you’re just getting the TV signal from pay TV
operator set-top box, like most
people in America. Then how can we unify that? How can we use a single remote
control to watch live TV and, at the same time, enjoy
a bunch of online streaming content and play games? So in this case, we expect some
developers to write a module, and we just categorize
it as a virtual TV input. It is a sub-APK which
includes TV Input service. You’ll learn the
details about it tomorrow, once the
SDK is published. So Virtual Input can
talk to set-top box if they understand
how to talk to. I mean, recently,
many pay TV operators are publishing the protocol
to talk to set-top box, or cloud API to check the
lineup of the subscriber and fetch data. And then it will send
a command to tune. So this Virtual Input module
can translate the command from the single system,
like TVF, to tune. And then get that
command, translate to proprietary command
the set-top box understands, and actual A/V
data can come from set-top box through HDMI port to TV device. So then from user’s
point of view, user is using TV
app you just saw to watch TV from
set-top box, and change the channel to Android TV. But actually, changing
channel action will happen on the set-top box. That’s what we call two-way
parity, two-way connection. So that is actually possible
today with many pay TV operator set-top box, and we do
have a close partner, some third-party
developer partners, who are working on a
few versions of this. And we hope some
people in the room or in the world to build
these kind of things, to bring [INAUDIBLE] experience. Second case is as you
can see in the sandbox today, the device we have
here doesn’t have any tuner, but it can actually
watch live TV. How can it be possible? Because there’s an external
device which converts broadcast feed from antenna or
cable provider into IP feed. So in this case, IP input
device can get the A/V data from the device, which we call
as a place-shifting device. Shifting place means
that– let’s say you have an antenna coming
down the corner of the house, that you placed it there. And then once you
convert to IP, anywhere in your house where your Wi-Fi
connection can be reached, you can get that signal. So that’s why we call
it place-shifting. So there are many types
of device like this. But today, in the
Sandbox, we were using a device called HDHomeRun,
made by a company neamed SiliconDust, in Livermore. So it was very small
and easy-to-use device we are using. So that device has its
own command set for us to fetch AP data and also
send a command to tune. And then we can
publish the AP data to the common database
in the Android TV device. Then Live TV app can render
channels and watch TV. Lastly, in case where live TV
signal is delivered via IP, one can write a TV input module
that gets the feed via IP, push they A/V data to the IP,
and send a command over IP. So there are two
cases of IP inputs. One is multicast IP input
on the managed network. For example, IP TV operator
has their own managed high-quality network,
so this input connection is joining broadcast
network and streamed TV. The other case is that if any
content provider or broadcaster has a sub somewhere in internet,
provides adaptive streaming base to live TV, then this
input can go fetch it. Basically it’s streaming,
but from user’s perspective, it’s live TV. So that is actually quite
common by many operators. Let’s say you are a Time
Warner customer, or a pay TV operator’s customer in
some part of the world. Then as a subscriber, you
get access to their IP feed, so that you can watch TV
on your tablet or phone. The same type of
sources can be used to power live TV on Android TV. So as a visual, we
imagine one day, no matter where you’re
getting live TV sources, we hope the user to
enjoy all the content, including live TV
and streaming content and games using single remote
control and game controller. That’s our hope. But there’s more. So there are many people
who’ve seen me multiple times. I’ve been pushing
the Android framework to enhance the A/V
pipeline for many years. And now we are really
getting close with L release. We are asking developers
to build their apps to deliver content,
especially video and audio. The problem is, if
Android platform itself is not capable of
supporting your streaming protocol, or closed caption,
or high-quality video playback, even if we’ve been
building the framework, it’s actually not
easy to write apps. So what we’ve been working on is
enhancing the video framework. So first of all, in terms of
supporting streaming protocol, we have a separate session going
on, either today or tomorrow, about ExoPlayer. ExoPlayer will be
open-sourced media player, uses low-level primitives,
such as VideoCrypt, Video DRM, and Video Codec. And it’s a Java
implementational video player. And it gives you MPEG-DASH
and Smooth Streaming protocol implementation by default. And since it’s open-sourced,
you can take the source code and then implement your own
custom streaming protocol, if you have. So that we will not
be the blocking factor for you to support your
content in your backend, so that you can write an app
that streams your content. And on top of that,
there has been a lot of requests
to support more various types of subtitles. So in L release, we are
adding TTML and CEA-608. Especially CEA-608 was
high demand request from many content providers,
because especially TV shows being captured from
broadcast and then delivered as a streaming media, their
closed-captions source is encoded in CEA-608 format. So unless we support that, those
content cannot be supported. And now we already support
WebVTT since KitKat. So we have three formats. Maybe there are some
other formats, too, but these are what
we can support by L. And when users play content on
phone versus on the TV device, TVs couldn’t speak. So if there’s any glitch in
terms of audio/video sync or video rendering,
user can notice easily. So the bar for video playback
quality is very high on TV. So we spent a lot of energy
on making audio/video playback quality to be TV quality
by using TV Associates feature to turn audio and video. And we started VP9 and HEVC
codec to support 4K content. And AC3, obviously, to
support AC3 content. And as Chris mentioned,
we support Widevine Level 1 and Playready. Thanks. [APPLAUSE] CHRIS MCKILLOP:
Thank you, Andrew. So during the
keynote this morning, and also in the Sandbox,
if you’ve seen it, and up here, right here,
we’ve been doing all this on real hardware. And we call that hardware ADT-1. So some old guy
once said, “Which came first, the
chicken or the egg?” This is an important
statement when you’re building a new platform
or adding a new device type to an existing platform. App developers don’t
want to support you if you don’t have
a piece of hardware for them to develop
their apps against. And hardware
manufacturers don’t want to support your new platform
unless you show them running it on another piece of hardware. And so we were the only
ones that could fix this. So what we did was build ADT-1. This is a media
streaming microconsole. Choose your acronym
that you want to have. But we built it for developers. We built it originally
for inside of Google. This chicken-and-egg problem
exists with everybody. Everyone has too-busy schedules
and doesn’t have time, and doesn’t necessarily believe
that what you’re building is real, unless you give
them something to play with. So what we’ve
decided to do is take that box, which is a
Tegra4 CPU, 2 gigs of RAM, 16 gigs of Flash,
2×2 MIMO Wi-Fi, HDMI. It’s running L
Developer Preview, and it’s fully unlocked,
comes with a developer cable so that you can reflash it
and do whatever you want. It’s essentially the same level
of openness as a Nexus device. And so everyone here
at the session today is going to get one of them. [CHEERING AND APPLAUSE] So everyone watching the live
stream, starting tomorrow, you’re going to be able to
go online and request one. We have a small
number that we’re going to give to existing
Android developers. Please go online to
the URL there– it won’t be live till tomorrow–
and request your device, and we’ll get those out to you. So this should let everyone
here in the room experience what we’ve been showing you. Start bringing your apps over
to Android TV, and really sort of see what’s
next for Android. There’s going to be vouchers. You’ll get the device tomorrow
with all the other hardware. There’s vouchers
that’ll be at the doors. Make sure you get your
voucher on the way out. And don’t rush. There’s lots for everybody. [LAUGHTER] So just get your voucher. You’ll be able to pick it
up tomorrow, downstairs at Registration. It won’t be a problem at all. So I want to thank everyone
for coming to the presentation today. We’ll have all the
documentation– screenshots, example code, GitHub
projects– up online tomorrow for you to get moving. So enjoy, and thank you. [APPLAUSE]