Your Apps at work – Google I/O 2016
Articles Blog

Your Apps at work – Google I/O 2016


JAMES KELLY: Good
afternoon, everybody. [WHISTLE FROM AUDIENCE] Thank you. Whether it’s corporate
email, collaboration tools for remote workers, barcode
scanners for logistics workers, or stock market tickers
for finance types, there’s a whole world of
apps for work out there. Now with Android
for Work you can focus on making great
apps for business. And with Google
Play for Work, you can make apps available
to the whole workforce. So with your apps at work,
we can all be productive while we’re mobile. My name is James Kelly,
and I’m a product manager on the Android team. Last year we launched
Android for Work as a way for IT admins to deploy devices
and apps to their employees, and keep corporate
data safe and secure. Now, today we’re
announcing we’re expanding Android
for Work, to cover new kinds of devices and apps. And make it simpler to grow
the audience for your apps to all kinds of businesses. MATT GOODRIDGE: And I’m Matt
Goodridge, a product manager on the Google Play team. At Google Play for
Work, our mission is to reduce the barriers for
developers such as yourselves, to get innovative apps
discovered and used by businesses while
keeping the business’s data safe and secure. RICHARD HYNDMAN: Hey. And I’m Richard Hyndman,
developer advocate on the Android team. Helping to make sure you
guys have all the materials you need to build
great applications, but also taking
feedback from you and taking it to the
guys making the products, like James and Matt. MATT GOODRIDGE: Did you know
that according to Gartner, businesses globally spent $143
billion on application software in 2015, across
desktop and mobile. Just to put that in
perspective, that is 25% bigger than the entire
global spend on video games across all platforms
in the same year. And apps targeted
at mobile devices are by far the fastest growing
business segment that there is. But compared to the
gaming industry, business apps are
much further behind in moving to mobile devices. In part, that is because of
the lack of developers taking advantage of this opportunity. In fact, Gartner says that
demand for business apps will outstrip development
reach by five to one. That’s going to be pretty
exciting news for you guys. It means we’re early in an
exciting revolution in business software, and
developers are already starting to see success. Let’s look at some examples. DocuSign launched its
e-signature business knowing it would need to appeal
to both consumers, who needed to sign and return
documents on the go, and businesses who saw
tremendous value in making every decision,
approval, workflow, and signature, 100% digital. They recently said that
99% of mobile revenue comes from businesses
sending documents to obtain approvals and
signatures to transact business faster. And consumers help expose
businesses to DocuSign because signing and returning
a document is always free. It’s an incredible viral network
that drives revenue growth. Dropbox started as a file
sync and share solution for consumers. But the number of Dropbox
business customers has grown globally 3 and 1/2
times in the past two years. There were 200 million
unique mobile devices connected to Dropbox last year. JAMES KELLY: Cool. Thanks, Matt. So it’s clear there’s a huge
opportunity in business app development. So why develop on Android? Let’s look at this from the
perspective of an IT admin. Now often businesses
require a range of both internally and
externally developed apps. And those apps have to work
across multiple platforms. So to manage all
of that complexity, IT will often partner with
a supplier of the Enterprise Mobility Management or an EMM. With Android for Work,
we work with some of the top EMM partners
like those you see here. And we’ve worked with other
developers, OEMs, and carriers, to make their products
great for business. Now businesses can choose the
solution that’s right for them. Because Android is
an open platform, these solutions cover a wide
range of business needs. So in addition to
this variety of apps, IT also need to offer
different kinds of devices for different use cases. Now since Android supports a
really diverse range of devices at all kinds of price
points, as a platform it’s a great tool to give IT the
choices they need to mobilize the entire workforce. So I know many of you will be
familiar with Android for Work. But for those of you that
aren’t, let’s describe a little bit about what we do. So first there’s BYOD, Android
for Work’s great option for Bringing Your Own Device. Now, organizations
allow employees to bring their favorite Android
device for work to work. With Android for Work, employees
can use the devices they want, but get the apps they need. This works by the business is
able to create a secure work profile on the device, where
work apps and data reside. And these are securely
managed by the IT department. Data in the work profile
is kept safe and separate, so the business can
protect against data loss. But at the same
time, the employee can be confident that
their company can’t access personal data or activity. Now next, Android for Work has
a model we call Device Owner. If a business prefers
to give employees fully managed
devices with access to the most secure
corporate systems, that’s what Device Owner is for. In DO, the company
owns the whole device and manages the data on it. IT has complete control over
the entire device, which may mean, for example,
that the user can only use apps that are approved by IT. And finally, there’s COSU,
Corporate Owned Single-Use Devices. This is a very diverse
range of business needs. You may want to manage
a fleet of devices that are used for a single purpose. For example, like a kiosk. COSU devices are
typically deployed where the device is locked to
a single, or a small number, of apps. And this mode gives the company
confidence the device cannot be used for anything else,
even if, for example, it’s a kiosk in a public place. MATT GOODRIDGE: We’ve built
comprehensive data policy controls into Android that
ensure company data is safe, while it’s on the mobile device. For example, blocking
screen capture, or stopping content
being copied from a work app into a personal app. You can find out more
about all of these controls at developer.android.com/work. We’re sending the link
to the event space now. Security is a critical
aspect of any mobile platform in the workplace. The Android security
team is raising the bar on Android security. You can see more details
in the year-end review that we published back in April. And if you missed
Adrian Ludwig’s talk on Android security
this morning, you can catch up
with it on YouTube. Android security is
pushing the boundaries with things like Android’s
monthly security patch updates and much, much more. We’re posting the link to
the video and the reports to the event space right now. And finally, at management,
Google Play for Work enables an administrator to
authorize employees to use apps on their work device
or work profile, or push install those apps
remotely, and configure them. These controls are exposed
to the administrator through the business’s EMM
Console, and to the user through the Play Store
app on the device. We’ll see examples
of these shortly, but let’s go back
to James to find out what’s new in Android N. JAMES KELLY: Cool. Thanks, Matt. So I think we’re all clear on
what Android for Work is now. And as you know,
we’re constantly making improvements and
investments in the platform. So last year, businesses told
us they wanted better security, and more controls for IT admins. And users told us they wanted
a better user experience, and a better work-life balance. So in the N Developer Preview,
we’ve expanded on those themes with a range of new
capabilities in Android. First off, if you were at
the What’s New in Android N talk yesterday, you’ll have seen
Chet talk about this feature. It’s a great feature to
enhance security and control over corporate data. We call it the work challenge. So work challenge is
a separate passcode that protects work apps
and data on a BYOD device. So this means that IT no longer
needs to set complex password requirements for the device lock
screen which get in the way. Instead they can set
a passcode requirement that only applies to work apps. And they have policies
around how often they can show that password
requirement, and so on and so forth. We also added
file-based encryption and fast secure wipe
on supported devices. So when an employee
switches devices, corporate data is
never compromised. Another long requested
feature is always-on VPN. So we’ve added always-on
VPN to the platform. Incidentally, this works for
both consumer and business apps. So now a business can route
all data traffic from work apps to their VPN from
boot-up to shutdown. Now because the system can
directly bind VPN services without interaction, VPN clients
need to handle some new entry points on the device. For example, at boot-up,
the system service will start the VPN. So if you build a VPN app,
you need to bear this in mind. You’ll also need
to ensure that you can support user configuration
of the always-on capability in your app’s UI. To help you with that, there are
some open source examples using OpenVPN available on GitHub. And we’re going to add a link
to that in the event space now. So alongside
always-on VPN, we’ve made some additional
improvements into work contacts to better integrate them into
the system dialer, messenger, and contacts app. So this lets you search across
work and personal contacts seamlessly from those apps. And for example, if
you’ve got a call from a colleague
in the call log, that will resolve and show
you the colleague’s name rather than just a number. We’ve also improved
transparency in the system UI so you always know when your
device might be affected by your IT department’s policy. We also allow, for example,
IT to set a support message directly in the
system UI to provide links to support resources. Now, users often
tell us they love having the option
of separate apps for work and personal tasks. But aren’t there times when you
would love to detach from work? So we’ve added a feature we
call Work Mode to Android. Now Work Mode lets you control
work apps from Quick Settings. You can shut them all down
at the tap of the briefcase icon in Quick Settings. When you’re in Work Mode,
work and personal apps run side by side. But outside of Work mode,
work apps don’t run, they don’t generate
interruptions, they don’t consume battery,
and they don’t consume data. So it’s like an
off-switch for work. How cool is that? And there’s a full list of
features in the N Developer Preview documentation. We have added over 20
features into the Android N Release for Business, and we’re
adding a link to those features into the event space now. If you need to evaluate the
full range of capabilities in Android, we encourage
you to download our EMM developer focused app
called Test DPC from Play. So Test Device Policy
Client functions as a profile owner
or device owner with local controls over policy. So this lets you set policy
and restrictions locally without needing like
an enterprise server up in the cloud to
configure the device. And if you’d like to test
your app for compatibility with Android for Work, it’s
a really great tool for that. So by listening to
feedback from IT and making these
improvements in Android N, we hope we’ve made Android
an even better solution for business. Be sure to install
the N Developer Preview if you haven’t
already, and check out features like Work Mode. So you can enjoy that
vacation on the beach free of interruptions
from the office. So how can you get started
with Android for Work? As a developer, you need to
know that your app will work for all kinds of businesses. So to do that, we’re
going to give you a sneak peek of a new way
to get set up with a fully functioning work profile. So you can test apps for
work on your own device, or you can use this
to set up a work profile for a clean
separation between your work and personal lives. Now in our example,
I want you to imagine I’m a marketing manager at an
aquatic supply company called Happy Guppy. Alongside the productivity
apps, I want my sales team to use Showpad to show a glossy,
interactive, magazine style brochure to
prospective customers. I want all my sales
team to have it. And I want them up
and running quickly, and not have to
search for an app, and maybe configure
it, or log into it. Let’s switch to the
Chromebook please. First, let’s get
set up on the web. Now Play for Work allows
IT to pre-approve apps, or make a range of optional
apps available on your device. So Rich, let’s go ahead
and approve Showpad. Cool. That’s done. Now, Showpad’s approved–
approving, approved. We need to switch to–
now we need to set up users in our new business. Think of this as
just like IT would do when onboarding a new
employee, for example. So Rich is going to go
ahead and create a user. Now, after Rich
does this, we’ll be prompted to switch to our
device and download an app that will be used to manage it. We’re going to do that in a sec. But here’s the cool thing. We’ve simplified
setup into one step. Trying out Android for
Work on your device is as simple as
scanning a QR code. Don’t scan it, it won’t work. So now, let’s switch
to our device. All right. So first, Matt’s going to
find the Android for Work app which will guide
us through set up. See there’s a wizard
in here, and he’s going to scan the QR code. Now after scanning the
QR code, a work profile is set up for work
apps and data. Now, just as a reminder,
the work profile is a secure space that’s
managed by your employer. But of course, in this
case, the employer is you. So you’re kind of
self-employed, I guess. So apps that are
available to employees are shown in a separate
Play for Work store. As well as push install
of pre-approved apps, admins are able to put
a range of optional apps into the Play for Work store for
an employee to install later. Now finally, on a BYOD device,
we place a badge on work apps. Notifications as
well are badged, and recents are badged
with the briefcase logo. This is to help distinguish
them from your personal apps. The point is here, is that
all of the setup for Android for Work has been simplified
into that single step. No more having to enter obscure
usernames and passwords, or navigate through
confusing screens. In this case, we built a
setup token into the QR code. But other mechanisms
are possible. For example, if there’s no
QR reader on the device, it will fall back to
a one-time auth code. So hopefully, after
a few moments, our work profile is set up. This work profile is a separate
space for work apps and data. And the key here is that
in a real Android for Work deployment, IT only
controls the space and not the entire device. So after setup is
complete, you’ll see work apps on the
device in a work profile. Initially it contains a
few badged system utilities in the Play for Work store. The work apps are
badged and organized into a Work Folder in
the Google Launcher. And the Showpad app
that we approved is being automatically
installed now from the cloud from Google Play for Work. While that’s happening, let’s
hope the Wi-Fi holds up. Switch back two slides, please. So we’re going to be
launching this new way to set up Android for Work on
your device later this year. You’ll be able to create
a fully functioning work profile with Play for Work in
it on supported devices, which include those
running Marshmallow, and of course, the
N Developer Preview. You can use the web
console to simulate the way an IT department
would deploy and manage apps, and set policies on your device. It’s a great way for
developers and IT admins to evaluate Android for
Work for their organization with no extra set up required. You just can use this. So for now, you can
visit our sandbox area where we’ve got some of
these devices set up. And some of our
engineering team is on hand to show you this and other
demos in some more detail. MATT GOODRIDGE:
So, how does Google help you get your
app to businesses? By publishing your app
through Google Play, your app is
automatically enrolled to be distributed to businesses
through Google Play for Work. As you just saw in the demo,
when an administrator wants to deploy your app at
scale to their users, the administrator makes sure
that the users are set up for mobile management, selects
your app in the management console, and the group of users
they want to deploy it to, and in one click your
app gets deployed to one of those users’ devices. This gives you another
route to getting users, versus trying to
get them one by one as if they were consumers. Now let’s move on to how
to make your app really awesome for businesses. Some of the biggest
challenges that we’ve heard from business
customers and developers, are app customization,
configuration, and single sign-on. How do you make your
app behave differently for different customers,
and still maintain one APK? How do you enable business users
to get started with your app, with minimum manual
configuration? How do you ensure that business
customers incur minimum support costs when running your app? We’re going to cover
two things that will help you address that. First of all, customization
and configuration of your app, and then secondly, integrating
business single sign-on with your app. You can allow administrators
to remotely customize and configure your app
in Android for Work by allowing a
configuration bundle to be sent down to your app in a
schema that you, the developer, define. What’s really unique about
Android for Work is the way we deliver that configuration
down to the device. Later on this year, we’re going
to be allowing configuration to be sent through
Google Play for Work, rather than via EMM
directly on the device. Google Play ensures
that that configuration bundle lands on the
device at the same time as install, in an
atomic operation, ensuring a seamless
experience for the user, and that the schema
of the config bundle matches the version of the
app that’s being installed. So let’s start looking at
how managed configuration can help you. Let’s say you’re the
developer of the TODOING app which you distribute
to individual users through Google Play. You only want to
maintain one APK, but your customers want
to customize your app. For example, they want to
make it corporate colors, or put their logo on it,
including in the loading screen. You can set up
configuration parameters for foreground and background
colors, a URL for the logo. And if your app loads
without the config, e.g. on individual’s device
downloaded on the consumer Play Store, your app defaults
to your regular experience. If the config is available, you
can customize the experience from the first time
the app launches. You still maintain just one APK. RICHARD HYNDMAN: So
what is this magic? For app developers,
app configurations are just like app restrictions
that came in Jelly Bean. Although this time,
it’s IT admins doing the configuration
and not parents. Your app can support any
configurations that you want. You just have to define them
in an XML file like this. The restriction type
that we have is string, but there’s lots of
different options of integer, multiple choice,
Boolean, other things. And then you refer
to that restrictions file with all the
separate restrictions you want to specify in
your Android manifest. And it’s pretty much that easy. It’s easier than adding
a preferences screen into your application, because
the rest of the heavy lifting is done by the EMMs and
the Google Play APIs. The EMMs go and read
these configurations using the APIs
straight from your XML files from our servers. And then the EMMs offer
up configuration screens to IT admins. The IT admins can
then go and set in corporate logos, logon
hints, whatever they need to do. And then in your
application, you just use the restrictions
manager just like you would with app
restrictions, and call Get Application Restrictions. When you call this, you’ll get
that bundle of restrictions down that the IT admins
have set through the EMM consoles that they’re
used to using anyway. So it really is easier than
putting a preferences screen in your application, and you
can move all that logic out and let IT admins set
preferences for users instead. Also, you’re going
to want to listen out for a broadcast on the system. There’s a broadcast action
applications restriction changed, which is harder
to say than [INAUDIBLE], but IT admins can change
these things at any time. So you listen for the
broadcast, and if they change it once your apps
already installed, you’ll get that broadcast
with the new bundle and you can change
whatever the IT admins changed– whether it’s
the VPN location or anything. MATT GOODRIDGE: All right. Thanks, Rich. Let’s move on now to
look at single sign-on. So many companies use Web Single
Sign-on, allowing their users to access all company
software and resources using a single username and password. Single sign-on has long been a
feature of web-based services, but getting it to work
on a mobile device has been pretty
challenging until now. Architectures vary. But let’s focus on
the most common case where you have a SAS backend
for your app, which might also have a web component. And that your customer is using
an enterprise authorization server to manage all of
their single sign-on and app authorization. What typically happens today,
is that the user is first prompted to identify themselves
with some type of identifier. This is often the
company email address, but it could also
be the company name. This helps the app resolve
the identity provider that the company is using
via its SAS backend. And then the app then
presents the login screen for the identity provider,
where the user enters the username again,
and their password, before getting to the app. And then if I
install another app, I have to go through
the same thing again. And again. Ouch. Wouldn’t it be great
if SSO on mobile just worked like
it did on the web? If the user has already logged
in with their SSO credentials on their device,
then all they have to do is accept an OAuth
permissions prompt once, and even then they don’t have
to do that if they’ve already accepted it on another device. We’re going to go through
how to get this ideal SSO flow in your app. There are two stages. Firstly, we’re going to
use managed configuration to tell your app which SSO
provider to use, and then pre-populate the username. Secondly, we’re going to use a
new feature in Android called Chrome Custom Tabs together
with the AppAuth library to persist the user’s
login state across apps. Let’s start with a
managed configuration. You need to create a field in
managed configuration called login_hint which
your app can send to its SAS backend which will
help it resolve the identity provider. If you’ve implemented
WebSSO, then this should sound pretty familiar. Let’s see how this login_hint
field should be used. So the administrator is going
to be using the EMM console to configure your Android app. It will send the Logon Hint in
the configuration bundle down. When your app first loads,
it sends the OAuth request to your SAS backend, it also
sends down that login hint, so the SAS backend can then
resolve which enterprise authentication server to use. Then, depending on
which technology you’ve used, whether it’s
OAuth, whether it’s SAML, or whether it’s
OpenID Connect, you can communicate
to the auth server and then present the
login screen to the user. So that’s the
initial sign up flow. Now let’s use a
persistent login session with Chrome Custom Tabs. First of all, let’s take a look
at what Chrome Custom Tabs are. It’s a secure context where
you can show any web page. But the host app can’t
inspect the contents. The user can see
the server address, but they can’t edit it. And the cookie state is shared
with any other custom tab and Chrome browser itself. This is what’s going to give
you that persistent login state. It’s a system browser activity
presented in the app context. So you don’t need to worry
about users being redirected between different contexts. It shipped in Chrome 45, and
it supports all devices back to Jelly Bean. Chrome ships with every
device with the Play Store. So it will be there. If your user’s device defaults
to a different browser that doesn’t support Custom
Tabs, then Chrome may still be available. You don’t actually need to
integrate with Google Accounts. This is just an
example, by the way. So using the AppAuth
library from OpenID, you can very quickly build your
auth step, which will directly show the customer’s
identity provider login screen if the user is not
yet signed in on the device. The enterprise auth
server is configured to pass the username from the
login_hint to the identity provider, then it will
be pre-populated as well. And if the user has already
signed into their account, then they go straight in– no
username and password at all. How easy is that? Really easy. Rich. RICHARD HYNDMAN:
Thanks very much. So you can simplify the
SSO in your application, making lives easier for
users and IT admins. And the best bit
about it, is there’s a library available for
both Android and iOS that’s going to do all
the heavy lifting for you. It speaks both OAuth
2 and OpenID Connect, and has convenience methods
to assist with common tasks like performing actions
with a fresh token. As Matt says, it’ll use
Chrome Custom Tabs which has access to that
shared cookie jar, so it’s just going to work. And if Chrome Custom
Tabs isn’t available, it falls back to
the system browser. You just lose that in-app
branding that you’d get. So you can head over
to github.com/openid and there’s an AAR there
for Android so you can drop in your project. But it’s also in Maven Central. So you can stick it
in your Gradle file, you’ve got the dependency,
and you can get up and running with the
new SSO flows embedded inside your applications. Also as Matt
mentioned, you’re going to want to use that login_hint. Are people already
doing SSO flows and OAuth with login_hints? People nodding, one, two. Yeah, quite a few. OK so, for the app
restriction for login_hints, it’s exactly the same as before. Just give the IT admins
that item in their console by putting this XML in your
application so they can add a login_hint that gets driven
down to your application, and then your auth flow
is much more simple. MATT GOODRIDGE: Great. Thanks, Rich. So that’s the theory. But let’s have a look at it on
a real app in a real device. So let’s watch the demo. Thank you. So we’re going to
go back to Showpad which we installed earlier. But first of all
I’m going to you Showpad running in
a consumer profile, so you can see the
difference in the experience. So I’ve already
installed Showpad here, just from the
consumer Play Store. It launches with a
warm welcome, telling me which features it’s got. And then I can either
log in, or try a demo. I’m going to log in. It first asked me for
my organization name. So this is this identifier
that I mentioned before. So I’m going to
type in “Google.” Let’s hope my fat fingers work. And then I’ve got
my email address, so I need to put that in. And that’s probably wrong. So never mind. Right. We’ll just do that. Make sure you’re close enough
[INAUDIBLE] and the password. Right? Yep. But if I’m a busy
sales guy, I don’t want to have to set up
every app like this. So let’s take a look
at what it looks like if it’s preconfigured
with managed configuration. So I’m going to go back
to the version of Showpad that we pre-installed earlier,
which is in the work profile. I start off with the same
warm welcome showing me what features. But once I’m through that, the
only thing I can do is log in. So I’m going to go and log in. And then it’s automatically
seeing the company name, and it’s showing me my
username there as well. So I know which username
I’m logging in as, and then I can recall which
passwords to get started with. OK. Back to slides, please. Sweet. So, I’ve had the app pushed
to my sales team’s devices and preconfigured
for them, saving them time and brainpower, and
giving them more time to spend with our customers. As a developer, you can alter
the behavior of your app based on the
configuration that can be customized on a
per-customer, per-user, or even a per-device basis. You should also be aware of
an industry standardization effort called AppConfig
Community which is initiated by a group of
leading enterprise mobility management partners. AppConfig is working with
developers and mobile platforms and others in the
ecosystem, to come up with some common best
practices on configuring apps in a business environment. Google is working with
AppConfig to further evolve the app configuration
for the benefit of the entire ecosystem. And they’ve recently unveiled
their initial Android guidance in collaboration with Google. So check it out. We’re posting a link
to the event space now. JAMES KELLY: Thanks, Matt. I hope you’re all
going to go off and provision manage
configuration. Now we’re all
familiar with the kind of devices we carry every day. They’re great for fun, and
productivity, and selfies. But beyond that, there is a
huge range of Android devices suitable for a diverse
range of workplaces. So just look in the
world around you. And wherever you
see a clipboard, there’s actually an amazing
opportunity for a good Android app experience. Now, we partnered with a group
of OEMs including Honeywell, Zebra, or Zebra,
Kyocera, and Panasonic to bring a range of
these Android devices to the wider workplace. All these devices feature
tough external cases, and a barcode-scanning
capability. So they’re perfect
for use in the field. And we have heard
from many customers that they want to deploy managed
Android devices in logistics, retail, construction sectors. And so we’ve invested
in making Android for Work a really great
platform to do that. And now we’re asking
our developers to build amazing app
experiences for what we call COSU– corporate
owned single-use devices. So what could a
COSU app look like? Here’s one possibility. Now, we all love the convenience
of shopping from home. And if you’re
anything like me, you order everything from
groceries to gifts from the comfort of your couch. In fact, Matt told me his guppy
fish was feeling a bit down. And as this real screenshot
from Matt’s house shows, he decided to order
his guppy a new pal. Now I’m sure most of us don’t
think about how our latest purchase makes its way to us. Android for Work
makes it a breeze for companies like Happy
Guppy to set up and manage a fleet of devices so all
of their delivery drivers have the apps they need
in the palm of their hand. First, IT will setup the
fleet of COSU devices. And there are a number
of ways to do this. But from a brand new
out-of-the-box device, setting up Android for Work
is as simple as an NFC bump. And in the N Developer
Preview, we’ve added fast setup using QR codes
into the setup wizard too. Once the devices
have been set up, they can be locked down so
that only apps authorized by IT are accessible in the launcher. So in this way, by combining
apps for barcode scanning, with apps for scheduling, and
apps like Maps for navigation, with their employee and
delivery database in the cloud, Happy Guppy drivers can use a
single COSU device for the job. And when the driver
reaches Matt’s house, they can use the
barcode scanning app to record the delivery. They can get a signature,
or maybe even a photo if they left the package in a
safe place, or unsafe place. And make Matt a happy
Happy Guppy customer. So whether it’s running a single
app on a dedicated device, or optimizing the entire
end-to-end experience for a mobile workforce,
you can develop great apps for mobile workers. IT can use Play for Work to
keep them up-to-date as well. You know, Matt, I’d have
gone a different way with the interior. But it looks like Matt’s
guppy loves his new pal. So how would you build
a great COSU app? To give you some pointers,
let’s welcome back Rich to show you how. RICHARD HYNDMAN: OK. So for a COSU app, you’ve
got three main points. First of all, you’ve
got the device owner. The device owner’s going
to go on the device and allow IT admins to
remotely own that device. That’s really
important because you don’t want the
user of the device to have to configure it at all. Then you’re going to have
an NFC provisioning app. The NFC provisioning
app, you bump with the device when
it’s in its setup wizard, and it transfers the data
for that device owner to be installed. And then you’ve got
your single-use device, in this case the Happy Guppy
delivery driver’s application. So here– I’ll show you how to
get the NFC app on the device owner app in a minute. But once you’ve got
the NFC app, you give it some configurations. And these configurations,
when you bump it with the single-use
device, are the things that are sent over
to the setup wizard. So in our case, we’ve got
this list of URLs, checksums, and package names. They’re going to go over during
the NFC bump onto the device. And the device in
the setup wizard is going to download the
device owner, install it, and the device owner will
set policies on that device. The first thing
it’s going to do, is go and find our COSU app,
which is also passed in here. This is our Happy
Guppy lucky app, and it will then also
install that application. It then adds it to a
whitelist of applications that can run as kiosk
applications, which is why I’ve got the
package name at the bottom. So if you want to try
it out for yourself, I will show you the demo
of this in a second. You can just go into
either Android Studio, and go to Import
Samples, and type in “device admin” and you’ll
see you’ve got a few samples. But the bottom two,
NfcProvisioning and Device Owner are the ones we’re using. So you’ve actually got
the NfcProvisioning app for creating a COSU device. And the Device Owner app
which goes on as the policy client, which owns the device. You can also go to a Google
Samples GitHub [INAUDIBLE]. They’re always, always
available there as well. So in the Happy
Guppy case, you need to set your kiosk app,
the delivery driver app, into full screen mode. And to do that, you’ve got the
startlockTask and stoplockTask APIs that came in. Before, I think they came in– JAMES KELLY: Marshmallow? RICHARD HYNDMAN:
Maybe Jelly Bean? Marshmallow? JAMES KELLY: Marshmallow. RICHARD HYNDMAN: OK. If you use those,
it pins the app to the device in full
screen, but there’s user consent dialogs and
the user can back out. With Device Owner, if you’re
on this locked task whitelist, it will go into full screen
and the user can never get back out of it again. You’ll see those demo kiosks
we’ve got over on the Android for Work sandbox. And it’s just a full
screen kiosk device. So you’re going to want to
build a backdoor for yourself whilst you’re developing,
or else you may end up with a very single-use device,
you can never get back out of. JAMES KELLY: That’s
expensive development. RICHARD HYNDMAN: That
could be expensive. JAMES KELLY: $500 device. $500– RICHARD HYNDMAN: In our case,
when we were developing, we’ve got this barcode
scanner from Honeywell. We have an admin barcode, and
if you scan that admin barcode, it drops back out of single-use
mode, called stoplockTask. It drops out, and then
you can reset your device, or do what you
need to do with it. So as a developer,
there’s a couple of things to consider
for single-use devices. First of all, you’re
going to want– sorry, single-use applications. you’re going to want
your application to be entirely self-contained. You’re going to want to
own that user journey. If you’re a hotel
kiosk app, you’re going to not want to let the
user somehow click a link, and get into a web
browser, and then just start browsing the
web on your hotel kiosk. You’re going to
want to keep them in the room booking system. So you have a website
you want to link to– put it in a webview
or a Chrome Custom Tab and own the entire experience. If you do need to link
out to other apps, you’re defining kind of
a multi-app COSU system, and you’ll have to figure
out the entry points and exit points. Or maybe just decide
that you’re going to want to have a launcher,
and have a slightly more complex system. You can still have launchers
on single-use devices if you want to. So we have that Test DPC app
that James mentioned earlier, and you can go to
Google Samples as well and get the Test DPC app to
test all the Android for Work features out. But [INAUDIBLE] is not
all that complicated if you’re just getting
into the mindset of being a single-use
application developer. So let’s see it in action. JAMES KELLY: So
here is an example of a device from
Honeywell that’s great for a mobile workforce. It’s a rugged device, running
Marshmallow, that features a built-in laser scanner. And it’s just what we need
to get our guppy his new pal. How could this work for
real, using an app for work? Rich? We’d better get [INAUDIBLE]. RICHARD HYNDMAN:
[INAUDIBLE] that one, James. Can we get the WolfVision
in the projector? JAMES KELLY: Yeah let’s
go to the WolfVision. RICHARD HYNDMAN: OK. So this is the laser scanning,
ruggedized, Honeywell Marshmallow machine that
we’ll be using today. And it’s just factory
reset on the setup wizard. So to show how easy
it is to jinx a demo, I’m going to NFC bump it, and
turn it into a delivery driver application now. JAMES KELLY: Now this
is just like what the IT team would do
when they’re setting up devices for their workforce. RICHARD HYNDMAN: Just
so you can– sorry. JAMES KELLY: Oh, sorry. During setup, on the left here,
we have the programming device. Now, once set up of the
Honeywell device is completed, you’ll see we’re landed right
into our starting screen. Now during setup,
device owner is set. And this is an important
step, because it means the device can
only be managed by IT. And IT can set appropriate
security policies to govern device and app usage. So you’ll see we’re all
set up and ready to go. As simple as that. Wasn’t that fast? Now, we need to, I think,
load up on packages. And hit the streets. RICHARD HYNDMAN: Right. Getting my delivery
driver gown on. I should’ve turned it
inside out beforehand. JAMES KELLY: Now what will
happen first in our demo app, is that Rich will scan
his employee ID badge. RICHARD HYNDMAN: OK. So, I scan this with a
lovely laser scanner. And it logged me in. JAMES KELLY: There we go. We’ve got delivery details
for his various packages. In the demo app, we’ve
integrated navigation using Google Maps right
into the launcher app. So that he can use a Google
Maps to safely navigate along the optimal route. Now devices like this are
now shipping with Google Apps like Maps installed. So as a developer,
you can be sure that navigation is
available on the device. Oh, look his delivery is
right on the Googleplex. How about that. Now once Rich arrives, he
can drop off his package and get a signature. RICHARD HYNDMAN: Happy Guppy. There we go. JAMES KELLY: Wow, cool. As an employee, Rich can’t
break out of this mode. So there’s no risk of confusion,
and support costs are reduced. The device can be
remotely administered by IT using a wide range
of Android APIs, such as, for example, being able to
remotely reboot or manage the device. So you’re going to
scan for delivery? RICHARD HYNDMAN: Yep. So if I go and scan the
package– thank you. Can I get a signature? There you go. You can all see Matt’s– JAMES KELLY: Oh,
Matt looks so happy. RICHARD HYNDMAN: There you go. JAMES KELLY: As you can see,
we’ve got the signature. And Matt’s guppy has
a cool new friend. Using Android. [APPLAUSE] RICHARD HYNDMAN: And
I want to reiterate, that was provisioning an entire
single-use device from start to end during a delivery. JAMES KELLY: In about a minute. Now this is just one
example of an app for work, optimized for COSU devices. But there are many, many more–
from retail to hospitality to health care. We’re only just getting started. MATT GOODRIDGE: So, are you all
ready to seize the opportunity to make a difference
to an entire workforce? Remember how Google and
Android can help you. Android is easy to
set up for businesses. It’s fast for businesses
to deploy your app at scale with Google Play for Work. And you can make apps
awesome for businesses by allowing them to be
customized, and configured, and use SSO as
slickly as on the web. Android is ready for business. Now let’s go build apps for it. Join us for the public
launch of our Android for Work Developer
Community called DevHub where there are loads
of resources for work app developers. Thank you. [APPLAUSE] [MUSIC PLAYING]

5 thoughts on “Your Apps at work – Google I/O 2016

  1. In single app COSU devices, .can we restrict other settings like volume limits, location services always on, which the user will not be able to change it?Here is my full Requirement as a developer.
    https://stackoverflow.com/questions/44846300/mobile-device-managed-single-app-devices.
    Thanks

Leave a Reply

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

Back To Top