[MUSIC PLAYING]
Hi.
I'm Richard Hyndman, an engineer on the Android
Developer Relations team.
With the launch of Android Jellybean 4.3, we've seen some
great new features for users and developers alike, and I'm
going to run you through restricted profiles.
In Jellybean, we announced multiple users so you could
share your tablet easily with your family members.
Everyone would create their own profile, sign in with
their own Google accounts, install their apps, and just
use it as if it was their own tablet.
But if you were sharing your tablet with a child, this
sometimes got a little bit complicated.
You'd probably create them a profile, but then sign in with
your own Google account, install some apps, maybe put a
PIN code on the Play store, change the synchronization
settings, maybe disable some apps-- just really try and
make it a restricted, safe environment for
that child to use.
With restricted profiles, this has become a whole lot easier.
Restricted profiles are based on the primary user's profile.
They share the Google account and the applications of that
primary user, but in a restricted manner.
The restricted users don't get access to your Gmail,
Calendar, Play Store, or in-app purchases.
The primary user can choose which apps they can access,
and whether those apps can access
things like device location.
As a developer, the Restricted Profile API allows you to
offer up fine-grain control over your application and your
application's restrictions.
And the user manager has also been extended so your
application can find out what restrictions are
being imposed on it.
Application restrictions are managed under
the Device User Settings.
So when you create a new restricted profile, you'll see
a list of all the applications, and you can
choose which ones are available.
And your application will automatically
appear in this list.
But if you have specific settings, you're going to want
to let the platform know about them.
So how do you do that?
You add the intent-filter into Android Manifest for the
GET_RESTRICTION_ENTRIES.
This is going to prepare Android to add that Settings
button in the Settings screen like this.
So here we've got the Settings button.
And when you press it, it's going to populate with your
restrictions.
Here we've got some example restrictions,
Full Restriction Enabled.
In this particular app, you can choose whether or not the
child user, the restricted user, can change the language
or access any in-app items.
So to populate these settings, the system is going to
broadcast the action GetRestrictions intent to your
application.
And it's going to expect that you return with an array list
of restriction entries in the bundle.
So in the broadcast receiver, when you get the broadcast,
the first thing you want to do is call goAsync on the
broadcast receiver.
This is going to keep it active, and also give you a
PendingResult object to return your restrictions in.
Then you create an array list of restriction entries and put
it in the bundle and return it.
We've got three different types of restriction entry.
We have the Boolean type, just on and off.
We've got the check box, single select from a list, and
we have multiple selection from a list.
Three different types.
And looking at those in code, we have three different
constructors for those different types
of restriction entry.
And all of those constructions take a key so that later on
you can retrieve the setting from the system, and also a
default, or current value.
Here we've got the Boolean type, and then the single
choice type.
Maybe in the single choice type, you want to use it for
content rating of the content available to
a restricted user.
So you could have single choice of under
12, 15 plus, whatever.
And then you could just choose one of those and make the
content in your application relevant for the user.
And then the multiple choice type is going to take an array
list of strings for the default.
So now, the system's asked you for your restrictions.
You've returned them in this bundle, an array list of
restriction entries.
And then the device owner has been and set the exact
restrictions for their child.
So the final step, of course, is going to be to retrieve
those restrictions from the system.
So onResume in your application, you can recall
the restriction set by getting hold of the system service for
user service, and then get the application restrictions for
your package.
Of course, this may come back without any
restrictions in it.
In that case, you'll be running in the device owner's,
or an unrestricted profile.
But if you're in a restricted profile, you'll see all the
restrictions.
You can collect them back from the keys that you specified
earlier and find out the settings that there are.
If you don't want any specific settings, but you just want to
find out if you're in a restricted profile at the
moment, you can call GetUserRestrictions and just
check if that bundle is empty or not.
If it's empty, you're not restricted.
And if it's not, you're almost certainly in
a restricted profile.
So that's how restricted profile works.
But there is, of course, just one more thing.
If you'd rather have your own nice, tidy UI inside your
application, a single place to manage all your restrictions
that when the device owner is running your app, they can see
it, and then when they go through settings and press it,
it launches your activity instead of showing the
settings directly in the Settings screen, you can have
custom restrictions.
So when the GET_RESTRICTION_ENTRIES
broadcast is broadcast out to your app, instead of returning
an array list of restriction entries, you can return an
intent to launch your custom activity.
This is similar to the way it works for battery users, data
users, things like this, where you can launch an intent into
your application to show you around the screen.
So that should be all you need to know
about restricted profiles.
They're especially useful for content-based applications,
and I'm looking forward to seeing what use
cases you come up with.
Thank you very much.