What’s new in Android Things (Google I/O ’18)
Articles Blog

What’s new in Android Things (Google I/O ’18)

August 12, 2019

morning, and welcome to the second day of Google
I/O. Thank you all, who made it here bright and early. And a big warm hello to
folks on the Livestream. This session is about Android
Things, the version of Android that was specifically designed
for IoT products embedded devices. My name is Vince, and I
lead product management for Android Things. Yesterday, you heard about the
incredible momentum on Android. Over the years, we’ve
extended Android to many different
types of devices beyond phones and tablets– wearables, TVs, auto. And last year we announced
a new version of Android called Android Things,
specifically designed for embedded devices
and IoT products. I know many of you have been
tracking our regular developer previews and are already
building great things. I love reading
about the projects. It’s so awesome. For some of you,
this is entirely new. You’re just getting
started and want to know what Android
Things can do for you. So let me just get started with
some of the obvious questions. What is Android Things for? What problems does it solve? People have been making
connected devices for many years. What’s different now is
the profound revolution in machine learning. Powerful models and tools are
available to all developers, and there’s ever-increasing
demand for smarter devices. Traditionally, your only option
when building smarter devices was to delegate some of
the serious processing to the cloud. Now, it’s possible
to run much of it on device, which is useful
if you need low latency or if you’re handling
sensitive content and so on. And this growing
area is exactly where Android Things is targeted. It is for devices that
need powerful on-device intelligence. When we look around at devices
that populate our homes and businesses, IoT is, of
course, very broad and diverse. So in a sense, the product
categories are all familiar. We all know these. It’s just the user
expectations have gone up– way up. Let me just pick
on two use cases. At home, we increasingly
expect to be able to talk to our devices
and they’ll know who we are. Another one is smart
building devices, such as cameras, that can detect
how many people are in a room and do something useful
with that, for example, talk to their HVAC system. We know users want
these kinds of devices. And we know we could build them. But of course,
building these devices is actually very hard,
especially maintaining them over time. It’s actually very
expensive to do this. We know this at Google,
because we’ve been shipping these kinds of products. Well, what’s so hard? Well, first off, we’re talking
about an entire device, so a whole physical product. So we’re responsible
for the entire software stack, from the bottom all
the way up to the product experience. Now, of course, the
product experience is where you’d
ideally be wanting to spend most of your
time because that’s where users are interacting with. Below the product
experience, IoT devices are currently built using
many different flavors of roll-your-own
Linux or Android. Every device is different. So it’s hard to expect
consistent and reliable APIs. When you go from
project to project, you want to reuse
what you’ve built. You want to get support
from a large community. At the same time, we’re talking
about richer experiences with these devices. So obviously you need
to get your app working. Chances are you need
to get third-party apps and services working. Each time you need to figure
out basic building blocks, like a reliable [? setup ?]
flow from a smartphone, for instance. You could do all
yourself, but it just feels like extra
time and effort. Second, you need to get
down to the hardware. Building prototypes
with microprocessor SoCs have certainly gotten
easier over time. People use all sorts
of prototyping tools to get that done. But those don’t get you through
to production, let alone commercial launch. We’re talking about PCB
design and layout involving high-speed, highly
integrated components, SoC vendor relationships for
general support and bring up, component supply chain,
access to parts in low volume, and so on. These are all very
different skill sets you need to hire for your team. Again, prototyping solutions
get you off the ground, but that’s it. Finally, while it’s amazing
how much these devices can do on our behalf these days,
the flip side, of course, is that they have the keys
to our homes, our businesses, are back-end systems. Clearly there’s more and more
to gain from attacking IoT devices. Perhaps less obvious is why it’s
hard to provide the security. Well, it turns out it’s
incredibly expensive to harden products
out of the gate and to keep them
updated over time. It involves a lot of back-end
infrastructure to do this. We know this at Google
because we’ve been doing this for many products. Meanwhile, there’s immense cost
pressure from end consumers, of course. And it’s hard to amortize
costs without large volume. So those are the issues
that our engineering teams and our business
teams focused on when we built Android Things. The thinking was we could take
care of all the challenges that make development expensive. We provide Android
Things free of charge. You have less to worry about. Our goal is to reduce
the barrier to building powerful, intelligent
edge devices and make it more
accessible to everyone. Now, let’s take a look deeper. About building on reliable
and consistent APIs, Android Things is Android. As you’d expect, you can
rely on the same Android APIs and Google services as
when you build for phones. Familiar tools, such as
Android Studio and Android SDK, are available. You can build on Google
Play Services, Google Cloud Platform, Firebase, including
the most recently announced ML kit that you heard about
yesterday, and more. Of course, you are
building hardware. So it’s also about component
providers, SoC vendors and so on. As a device maker,
usually you’ll be spending a lot of your
time interacting directly to get to a working image. With Android Things,
we’ve already done the hard work for you. That means you have access to
hardware reference designs. It means the build support
package comes from Google. And you get a working
image right away. You can scale to production
because we’ve signed agreements with the SoC vendors
to guarantee support over the long term. Literally, our goal is if you
know how to build an Android app, you can now
prototype IoT products and take them all the
way to production. You don’t have to be a hardware
engineer or a firmware engineer to do this. Finally on security,
our strategy is to have security features
built into the platform. OS hardening is on
by default, and you don’t have to spend time
figuring it out yourself. Well, what about
fixes over time? Regular security patches
come regularly from Google. Google provides all the
back-end infrastructure for you to be in control. And you can decide
when those go out. Now let’s go a bit deeper. How do all the pieces that I
just talked about fit together? Developers often ask me,
how is Android Things different from Android? How is it different from AOSP? I found that the
best way to describe Android Things is that it’s
a fully managed solution beyond the AOSP model. At the lowest level, we
define turnkey hardware in partnership with
the silicon providers. This is in the form of a
system-on-module architecture. I’ll talk a bit more
about that in a bit. But the way the
model works, though, is that we work
closely with the SoCs to land code into Google tree. Google’s the one
hosting the BSPs. In fact, we have a
system-on-modules in our test labs hooked up
for continuous integration. Moving up to Android and
the framework layers, Android Things is Android. What we’ve done is we
took Android and we shrunk it down to around 50% of
the footprint of AOSP. Meaning it can run with
lower compute and storage requirements. Security features are built in. Meaning they’re done for you,
and they’re on by default. Up at the top is the app layer. We formalized the boundaries so
all the product-specific code lives there. We make sure the
Google services you might want to work with
work well out of the box. So your apps can rely on Google
Play Services, Firebase, Cloud Platform, Assistant, and more. Finally, what’s pictured
on the left side is the management console. It’s shown cutting across
everything from bottom to top because it’s
where you control what exactly goes into your devices. It’s where you get
access to the BSP that Google and the SoC
vendors are supporting. It’s where you create
full product builds, with all of your apps
and services included. It’s where you manage releases
and update channels over time. As you can see, that’s what
I’ve described Android things as a fully managed solution. It gives you a portfolio
of reference hardware to choose from. It gives you Android with
security and key services working on top. It gives you a console
to configure what exactly goes into your devices. It’s all of the ingredients
necessary to prototype and scale to production. On behalf of the entire
Android Things team, I’m super excited to share that
we are now generally available. Version 1.0 is the first
long-term, supported release. It came out just two days ago
on Monday, fresh off the press. Many of you have helped
us along the way. We’ve seen more than 100,000
downloads of our Android Things SDK. We’ve received feedback from
more than 10,000 developers. This is all critical to
get us to this point. Thank you so much. Now, what does version
1.0 mean for you? Most importantly, it
means Android Things is a stable base for you to
build commercial products. In fact, we’ve worked
with a few partners to put Android Things
through its paces and vet whether we could power
real shipping products. Let me show you a few. What you see here is our
first shipping product. And it really put our
program to the test. This is a smart speaker by
LG, and it landed on shelves last month. So story is LG wanted
to build a smart speaker with high-end audio and
go to market quickly. And they felt we’d
be a good fit. One of the first things was
to determine a good hardware reference design. The system-on-module
architecture that we talked about before is
in all the shipping products. From your point of
view, it’s all done, so you can just pick it up. It will be an officially
support a platform, and you’re good to go. Well, LG was also concerned
about ongoing security fixes and infrastructure to
send over-the-air updates. Bottom line is that
these guys want to be working on
amazing audio, not worrying about staffing up
a team to do security and do OS bring-up. This is a smart
speaker, so there’s non-trivial audio processing
for audio casting and a Google Assistant. We make sure these
work well and are part of the full solution as well. There’s more OEMs working
on smart speakers. And they’ll be coming
out in retail soon. Soon after, partners
chose us for a new product category called smart displays. The idea is a visual
Google Assistant. There’s deep
integration with photos, maps, video calling,
YouTube, and so on. What you see here are devices
from Lenovo, JBL, and LG. All these guys wanted
to move quickly, and we felt that we
could help them do that. At the time, we were already
working with SoC vendors on expanding our portfolio. And we were locked in on
a common system-on-module for all these products. In other words, if you look
under the hood, all of them are using the same
system-on-module, which is quite cool. Again, when you work
on your project, you can just skip all
of that upfront SoC work and just pick up the
supported design. The OEMs were also concerned
about ongoing updates, especially because this
is a new product category. They’re expecting
frequent updates. And during development,
they wanted to partition folks
into different groups and A/B test the
user experience. This is where our console
was put to the test to manage all the
builds, release channels, and frequent updates. Now, of course, IoT
is broad and diverse. What’s the most
exciting for me is seeing what everyone has been
building based on our developer previews. Here are two examples. The product on the right
is made by a company called Byteflies, a
wearable health startup based in Belgium. The hand is holding a sensor
that measures vital signs, and a docking station sends
data back to the cloud. Byteflies let us know
that Android Things helped turned their docking
station into a secure hub. They don’t have to worry
about ongoing security fixes and how to update the device. The product on a left is made
by a company called Morigo based in Montreal. They build a network
of large photo displays running Android Things
and are connected to public photo booths
in downtown Montreal, which sounds really fun. Morigo wanted a solution that
could help them move quickly, and Android could
help them do that. If you’re building a new product
powered by Android Things, we want to work with you too. We introduce a special
limited program to partner with
the Android Things team for technical
guidance and support. If your company is interested
in learning more, please let us know at the link. So now that I’ve shown
you some real products, let’s switch gears
and go back to how all the pieces fit together,
starting from the bottom. We talked about the
hardware reference designs. We talked about the
system-on-modules. You might be wondering, what
do they actually look like? So on the right here
is a System-on-Module, SoM for short. This one is based
on a NXP IMX 7D. All the high-speed and
complicated-to-design electronics are in the
SoM, the key components, such as the SoC, memory,
flash, Wi-Fi, Bluetooth, The baseboard is what
you see on the left. This one shown here
is actually one of our development baseboards. Well, you can imagine designing
product-specific baseboards with just the right
set of connectors and plugging the SoM on top. The SoM is complicated
and quite costly to design if you were
to do it yourself. And we’ve done the
hard work for you. It would also be very
expensive at low volume. But the SoMs are what
everyone will be using, and that helps drive
up volume for everyone. The baseboards are much less
expensive to produce, even at lower quantities. The electronics are much
lower speed and less dense. What I’ve shown here
is also referred to as a physical SoM, because
the SoM is on its own board. You could also imagine
designing it in, so it’s all on one single board. And we call that a virtual SoM. This would allow you to
save on costs at high volume or to better match x-y
dimensions for your product. Going back to the three smart
displays I showed earlier, they all use different tactics. Some used physical SoMs. And some design it in virtually. For each SoM, Google
proposed the Board Support Package, BSP for short. In other words, you
don’t have to interact with the SoC vendors. There’s a stable layer of
separation with the BSP that makes your code portable. You could imagine a starting
development on one SoM, then swapping over to another
at later stages of production if your design changes, without
having to change your code. Now, part of making the
SoM architecture viable is guaranteed support. Behind the scenes, we’ve
been working really hard with the SoC vendors to work out
the collaboration so you don’t have to talk directly to them. We are now seeing SoMs that
are certified for production. The list includes hardware from
Mediatek, NXP, and Qualcomm. More specifically,
SoMs on his list have guaranteed long-term
support and all security features built in, making
it possible to bring prototypes and go all
the way to production. Hardware and references
designs for these SoMs be available in the
coming months so stay tuned. SoMs supported for development
is already available now. They include hardware
from RaspberryPi and NXP. Development hardware have a
large community of support and are readily available
in retail, even at unit quantities, usually for cheap. So that gets everyone
started right away. The beauty of the
Android Things model is that you can easily
swap over to SoMs certified for production
once you’re ready. So everyone has been wondering
for the list of SoMs that are certified for production,
the ones on the left, how long is the support? How much does it cost? Each SoM certified
for production is supported by Google for
a minimum of three years from the time it was
first made available. What this means is you will
get regular security patches and stability fixes
from Google for you to push to your own devices. You can even set your
devices to auto update and not worry about it. In other words, you
get to fully harness the power of the
Android security team. Of course, you can push your
own updates to your devices anytime you want for the
entire product lifetime. Well, what about fees? There are no charges to
using Android Things. There are no license fees
for the OS or the management console. The API surface is stable. Meaning the length of
support is provided for each major version. This is why we refer to
1.0 as long-term support. We know moving to a new major
version can be disruptive, and it may not make sense
for many IoT products. So there’s no need to do that. Let me show you in
a bit more detail. Each line on this chart
represents a major version of Android Things and, of
course, 2.0, 3.0 in the future. As I said, every
major version will have long-term support,
the minimum three years we talked about. These major versions do map to
underlying Android desserts, and we’ll pick the right
points to intersect over time. The important point
is when 2.0 comes out, 1.0 and 2.0 are
supported in parallel. The security patches and
stability fixes come regularly. And that’s what each white
dot in the lines represent. We’ll also have
minor feature updates on the latest major version. This is so we continue to
address community feedback in a timely manner. So we won’t wait for
the next major version to push these out. In fact, in the
coming months, 1.1 will come out with
improvements for you. One last note on SoMs,
obviously the work we do behind the scenes with
the SoC vendors is never ending. It’s an ongoing process. We’ll continue to expand
the SoM portfolio. You saw the vendors
that already have something listed officially. And we’re deeply engaged with
others too, like Rockchip. The point is once we put a SoM
up as certified for production, it’s a commitment. The ones you saw
all support 1.0. And when we eventually
add 2.0, we’ll be explicit about
which SoMs support it. Now, we’ve been talking
about the next layer up already, since Google
hosts the board support package for every SoM. But what does it
actually look like? Let’s go into that in a
little bit more detail. What you see here is a
simplified software stack for a traditional
Android mobile device. Going from bottom to top, the
kernel up to the [? HAL ?] layers, it’s primarily focused
on enabling hardware support. The Android framework provides
a rich set of APIs and services for apps. And the applications on top
provide user-facing features, right? Now, in IoT devices, you can
imagine many of the included components not making sense. Or embedded devices are
usually single purpose. They may not have a screen. Users are not installing
apps and so on. So first, Android
Things removed most of the user-facing applications
and visual framework components that don’t make sense. For example, there’s no reason
for a text messaging app. This removes
unnecessary complexity and reduced the footprint
of the distribution. If you build a device with a
display, you have full control. There’s no system UI
to get in the way. Now, with or without a display,
the UI toolkit portions of the framework remain
available to your apps. Activities are still the primary
component of an Android app. The framework delivers
all input events to the foreground
activity which has focus. Next, we formalized the
boundary between the system and the product-specific code
necessary for the device. All the product-specific
code is above the line in the app layer. Everything below
the line is provided by Google and our SoC partners. This way you don’t have to
figure out how to put together a working image. Google can sign the
full image and guarantee automatic security updates
over the support time frame. You might be wondering how this
boundary can work in practice? Well, one crucial piece is the
Android Things support library. I’ll touch upon the
API surface briefly. For example, you
may be wondering how to control hardware. The peripheral I/O API allows
apps to interface directly with low-level peripherals using
industry standard protocols, like I-squared-C and GPIO. User-space drivers allows
apps to inject hardware events into the Android framework. You might be wondering how to
call APIs that usually involve a dialog or a view to the user? These don’t make sense
when displays are optional. So we’ve added APIs to control
settings, control device updates, and configure
local area connectivity, including Bluetooth and LoWPAN. Now I’d like to show you
the complete picture. We’ve already talked about
the portfolio of SoMs you can select from. And these come in at the bottom. There’s actually two
more building blocks. The first is device
configuration, and the second is security. Let’s start with
device configuration. It’s the other crucial piece,
along with the Android Things support library, that helps
maintain the formal boundary that we just talked about. You see, SoMs can support
a wide variety of hardware. So in many cases,
the OS needs to know which hardware is actually
connected in order to properly configure those interfaces,
for instance, which audio devices are
connected where and their formats, pin muxing. We provide a
configuration system so OEMs can [? divine ?]
their connected hardware in the console, which
will customize the image correspondingly at build time. Cool. Let’s talk a little
bit about security. Well, first off, the OS
hardening that we do on Android is enabled for Android Things. So these are things like
permissions, the application sandbox, mandatory access
control with SELinux, kernel Cisco
filtering, and so on. Images are signed. You don’t need to run any
signing infrastructure yourself. Google provides
the infrastructure to build the full image for you. These partitions are
signed for security. Verified boot, which is fully
implemented four SoMs certified for production, makes sure
you’re running a valid image at all times. Now, there’s lots of
interesting scenarios that are handled for you. And I always get a kick
out of thinking about them. For example, what
about running an older image with a vulnerability
that has since been fixed? Rollback protection makes
sure this doesn’t happen. Another one is for product keys. So images only run
where intended. You can insure only your product
images run on your devices. Finally, you don’t need to
run any update infrastructure. Google takes care of
building and serving all updates, the same
infrastructure we use for our own products. Now we’re moving
onto the app layer, where all of the
product-specific code lives. What does building an app
on Android Things look like? To get started, we want access
to the Android Things support library we just talked about. It’s built into the supported
devices as a shared library. We’re showing code snippets
from two files here. At the top is a snippet
of the build gradle file. You declare the SDK dependency
there, and it’ll get pulled in. The bottom part is a snippet
of the Android manifest file. You notice we use the
user’s library tag so our app can access the
device’s shared library. Below that is applying
the home category to one of your activities. What this does is
that the system will launch this activity
automatically on boot and relaunch it if
the app terminates. This is, of course,
exactly the behavior you’d expect for
embedded devices. Now that we have this set up,
let’s do something useful. The example here’s very simple. It detects a button press. But it’s a good
demonstration of how to interface directly
with peripherals using the peripheral I/O API. The code snippet at the top
is the Android manifest file. This is where we declare
the required permissions to use peripheral I/O. The code
snippet below is the activity. There we use the
peripheral I/O API to open a connection
to a GPIO pin, which is where the button is connected. We configured a GPIO pin as an
input and attach a callback. And that’s pretty much it. Good to go. A similar workflow is used
for all of the peripheral I/O interfaces. So you can imagine
adding a few lines, and you can light up an LED. Of course, it’s not
just about simple stuff. There’s a wide variety
of peripherals out there. Your app could interact with
all kinds of sensors, actuators, and so on this way. We’ve expanded our
community hub this week as part of the
1.0 announcements. The site is
androidthings.withgoogle.com. It brings together all of the
information in one place– samples, documents, forum. Also, as you probably
guessed, much of the code we showed before
about driving hardware peripherals isn’t
exactly product specific. You can get up and
running quickly with pre-built drivers from
our peripheral driver library. These drivers extract the
low-level communication details associated with many common
hardware peripherals. You can browse the driver
library at the community hub. And we’re also now accepting
community contributions as well. So let’s all make
this better together. Be sure to check it out. Well, where do you go from here? Well, you have full
access to the Android SDK and NDK when building apps. You can use Android Studio. Develop your apps in Kotlin. You can leverage
standard developer tools and third-party libraries. Many projects find Google
Play services, Firebase, Google Cloud Platform,
et cetera, very useful. In fact, you can create an
end-to-end demo very quickly. For instance, if you’re
collecting sensor data, you can use Cloud IoT Core to
help you ingest data and do something with it in the cloud. If you’re taking photos, the
Cloud Vision API, for example, can help you with
optic detection. Of course, there’s a lot more. We have many samples in
a community site for you to check out. Let’s say a bit more
about Google Play services because we’ve created an
optimized lighter-weight version of that
for Android Things. It’s optional, so it
doesn’t take up space if you don’t need it. Many developers do find
it very useful though. You can literally
tick a checkbox and add it to your
build from the console. You can find the Firebase
APIs in there, which were used in many of our samples. For example, the
real-time database is very useful when
you sync device data. You can also use the new ML kit
to integrate Google’s machine learning technology
into your app. There’s, of course, a lot
more in Play Services, fused location APIs, Nearby
for setup, maps, and more. The final piece
to Android Things is a console for managing
what’s running on your devices. It’s shown vertically cutting
across everything from bottom to top because that’s where
you manage all the builds and releases for
your entire device fleet at every stage of the
product development process. Let me explain. Here’s a very simplified view
of the product development flow. Every product goes through
the prototyping phase where you just want to get
something working, then a series of hardware
validation manufacturing stages, and finally
commercial launch. At the beginning, you can pick
up one of the development SoMs, because that’s the easiest
thing to do, and then later swap to one of the SoMs
certified for production. After you get the hardware,
you might be wondering, well, how do I assemble an image
and push it to the device? In the prototyping
phase, you probably just want quick access to a
generic image to get you going. You might only care
about one device. So you go to the
console and tell it which SoM you’ve chosen. And that’s pretty much it. You can then flash
the supported image and sign all apps
to your device. As your product evolves,
you’ll come back to the console to customize a lot more. For instance, you may want to
change the partition sizes. You may want to include
Google Play services because your apps need it. You may want to modify
the device configurations at build time based
on the peripherals that you’re connecting. You may start caring
about a lot more devices. For the smart displays and
the smart speaker devices that we showed earlier,
the OEMs used the console to split devices into groups. So developers, QA,
early beta testers, they’re on different groups. They all have different
builds and are on different update channels. All of this is configured
from the console. When you go to
production, you obviously need to assemble the– sorry, previous slide. When you go to
production, you obviously need to assemble the
entire factory image. That includes your
apps and services. You want to update your app
over the lifetime of the device. It’s important to have control
over rollout, for example, roll back, if
something goes wrong, gradual percentage roll
out so that you can go slow and check that things are
going well, access to metrics so you can see that things are
going in the right direction. All of this is why
the console exists. The underlying
back-end infrastructure is the same as what Google
uses for our own products. So just finished explaining
how Android Things is a fully managed solution. We have a lot more to
show you at I/O. Come and see us at our sandbox dome. It’s the giant
bright orange one. It’s hard to miss. The entire dome is filled
with Android Things demos. You can see how real commercial
products evolve from prototype to production, the
smart displays. You can see them all there. We talked about devices
getting increasingly smarter. We have demos showing
machine learning ingesting real-time video so it
can recognize emotions, faces, handwriting, and so on. By the way, you notice Android
Things powering devices outside of the dome as well. They’re powering
the survey boxes all around I/O for
instant feedback. There’s a five-foot tall robot
roaming around somewhere. It’s hard to miss that one– Android Things in there. If you like to code, come to
our code labs and get hands on. We have one showing how
to work with TensorFlow, Cloud IoT, how we made
the survey box, and more. There’s eight more
sessions coming up today and tomorrow that go
deeper into specific topics. For example, the
session at 11:30 today talks about how we
built the smart display product that journey all the way
from prototype to production. The last session we
have tomorrow talks about the console
in detail and how to manage your devices
at different stage of the development process. Finally, let’s all
have some fun at I/O. Join our scavenger hunt
at the link g.co/iosearch. You might have
seen this already. There’s very cool machine
learning enhanced flowers that you’ll notice. Solve the puzzles, and you’ll
get a free hardware developer kit. With that, let’s all
go build some hardware. If you know how to
build an Android app, you now have a new super power. You can prototype IoT products
and bring them all the way to production with
Android Things. You don’t have to be a hardware
engineer or firmware engineer to do this. Pick up a kit from
the scavenger hunt. Then head on to
androidthings.withgoogle.com to get started. This concludes our talk. My name’s Vince. Thank you and good luck.

Only registered users can comment.

  1. What about building a new interface to music app and with increasing its performance . That it would further feel like a lite app it would bee more supportive . Also introdusing lite simple interface and fixing the late in online mode and apparently make it more interactive

  2. 3 years is long term support? IoT devices are supposed to be set and forget pretty much.. I don't want to have to replace my smart garage door opener, or my smart irrigation controller every three years… I would be ok with minor features and bug fixes for 3 years, but security should be much longer.

Leave a Reply

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