[MUSIC PLAYING]
FELIPE LEME: So my
name is Felipe Leme.
I am a software engineer in
the Android Framework team,
and I'm the technical leader
for the Android Autofill
Framework-- of the topic
of today's presentation.
So our goal today is to
give a quick introduction
of what Android Autofill is,
and why it's important for you
to optimize our apps for it.
So the Android
Autofill Framework
is a new feature that
we introduced last year
on the Android Auto release.
And the goal is to provide a
safe and fast way for password
managers to do their jobs.
So basically, to
use autofill, you
need to select an
autofill service, which
could be a service that's
provided by the OEM
in a Google Autofill
or [INAUDIBLE] pass.
Or it can install third-party
apps, like a password manager,
like LastPass, Dashlane,
1Password, Enpass,
and many others.
Last time I checked, there
is about 30 different apps
on the Play store that
provides an autofill service.
And one key decision
we made when
we designed this API was
that it should work out
of the box with existing apps.
In other words, you
as an app developer,
you don't need to change
our app to support Autofill,
because if you don't do
anything, most likely
the password manager will
figure out what to do for you.
But just because you
don't need to change it,
doesn't mean you shouldn't.
After all, it's your
app that's on the line,
and you don't want to depend
on the third-party app which
you don't have control over.
So the rule of thumb, the main
tip, that I would like to give
is you should not rely on
the autofill service risks.
Rather, you should
provide your own tips,
like you want to make
sure that the password
manager or the autofill
service do their job properly.
And you can do that
quickly, or easily,
by just annotating
your XML views.
The first thing you should
do, you should make sure
that you annotate what
should be autofilled,
and you do that using
the Android [INAUDIBLE]
autofilling stack.
Let's take a quick
look at an example.
Let's say you have the
traditional user name
and password looking screen.
So if you don't do
anything at all,
if you don't annotate
your app for autofill,
and layout XML is using Android
IDs like user name field
and password field,
most likely it's
going to work fine, because
when the password manager sees
this real structure, they're
going to be some high risks,
and I'm going to say, OK, there
is a username superstring here
and a password here.
So they will know this as
username and password fields.
Now let's say you are a
software house in Brazil,
and you like to use
a name in Portuguese.
I actually grew up in Brazil and
I know this is kind of common.
So now my research ideas
are called [PORTUGUESE]
and [PORTUGUESE],, and this is
totally valid from the Android
point of view.
So now the password
manager, they will get you
through this structure,
and they will
know what this field means.
So basically, they're
not going to be providing
the autofill data and the user.
You have to manually type the
username and password, which
is exactly the
kind of problem you
try to avoid with
the password manager.
So the solution
for this problem,
you simply can annotate your
views, so with the Android
column autofill hints.
In case of username,
use username.
And password, use password.
And on JUDO Java,
we actually provide
hints for the common fields,
like username, password, credit
card number, telephone
number, et cetera.
Now, there is also
the other issue,
which is you should
also annotate
what should not be autofilled.
And you do that using
the Android column
imported for autofill text.
So just to see
another real example,
when I was developing this
API last year, at one point
I wanted to send an
SMS to my friend,
and then I got a pop up
with my own telephone number
as a recipient of the SMS.
That doesn't make
sense, because when
you're composing an SMS,
or email, or a spreadsheet
editor, usually you want to
type something dynamically.
You don't want to use the
predefined values that password
manager has, so this was
kind of annoying for me,
because I knew the API but it
could be confused for a user
that doesn't.
So the solution for
this case was simply
should disable autofill
for your activity,
and you can do that on
the [INAUDIBLE] layer
by annotating the root view
with importance for autofill
equals no exclude descendants.
So now, not only you don't risk
the password manager providing
that data where it
doesn't make sense,
but you also improve
the performance,
because you're not
triggering autofill at all.
So these are, I would
say, my main tips.
And let's say I convinced
you to use these tags
and you are so excited
to change your app.
You're going to skip
the rest of the summit,
go back to your laptop,
and change your apps.
Don't don't do that, but
if you do, how are you
going to test your changes?
Remember, you need to
select an autofill service
to see what would be the
data provided by the service.
And your first impulse
might be, OK, let me just
choose whatever
comes with my device,
like Google Autofill,
or [INAUDIBLE],,
or maybe you install a
third-party password manager.
You could do that,
but again, you've
got to go back to that problem
of relying on the password
manager, high risks.
In other words, maybe they
will provide autofill data
with all to your
changes, so you're not
going to really see what's going
on with making these changes.
So my suggestion
is to test using
standard autofill service.
And we provide some of them
on the official samples
that is hosted on GitHub.
So basically, we provide a
couple of autofill service
implementations at project.
One of them is
called Basic Service,
which is basically
a service that only
understands autofill hints.
So if you're using
autofill hints
on your app, when the
user clicks on a field,
you're going to see
this pop up like this.
Because you set it at
this field as username,
you'll see this
username options.
On the other hand, if you're
not using these screens,
then the Basic Service
wouldn't show anything.
This is also a pretty quick,
pretty simple, service.
It has less than
200 lines of code,
so it's very interesting
to understand
how an autofill service works.
This is a good example as well.
Now, we have another service
that's quite the opposite.
It's called Debug Service.
So this one tries
to fill anything.
So if you don't use
the autofill hints,
it's still going
to try to autofill
based on your [INAUDIBLE] IDs.
And this is useful to
test what would happen
if you're not tagging your
views if imported for autofill
equals no.
So for example,
back to my SMS app,
you would see
something like this.
When you click on two, you're
going to see this pop up
with some autofill data,
which is two, which is just
the name of the research ID.
So you could see how confusing
it would be for a user
if they see something
like that on their app.
Now, the final tip
I would like to give
is you should also make
sure that our app works
when the autofill service
requires authentication.
So what that means?
Most password managers, they
don't retain the user data
right away, because the
data might be encrypted
or might be locked somehow.
So they're going to ask
the user to authenticate,
so the user might need to type
a master password or maybe user
fingerprint to unlock the data.
And the way the
framework works, we're
going to be launching
a new activity that
belongs to this service
on top of your apps stack.
So the user is going to
do the authentication,
and when the user is finished,
your activity resumes.
So for most apps, this is
not going to be a problem,
but if your app is
doing something weird
on the active resume,
let's say you're
rebuilding the view
hierarchy or using some web
view to do some JavaScript
code dynamically.
So basically, you
might break autofill,
as we're going to see
in the next slides.
So again, to make sure that
your app works in this scenario,
you need the autofill service
that requires authentication.
And the simplest way to do that
is using the Debug Service.
So when you launch the settings
for the Debug Service--
actually, first you need to
enable autofill and select
the service, so you can
click on the bottle,
and select the Debug Service.
You see the Debug Autofill
Service is one of the options.
We provided that sample.
Then you can select these
authenticate response options.
It's on the top.
Now when you go back to
your app, when you triggered
autofill, instead of
getting the data unlocked,
you're going to have to get
this prompt to authenticate.
So when the user taps this
respond, we launch an activity.
In this case, it just
asks for [INAUDIBLE]..
So now when you click
on yes, in this case,
let's say for this
screenshot I'm
using a sample app where I'm
explicitly recreating the view
hierarchy on start.
So basically, when
I click yes, we
retain interactivity, but
now from the framework
point of view, all
the data is different.
So they don't know
that they have
the locked data for
your username field,
because it's a different ID.
So it's going to show the tap
to authenticate response again.
So when the user clicks there,
it launches the authenticate,
and say yes, sure, I
want to authenticate.
And then go back, ask
to authenticate again.
So basically, the user is
now on this Groundhog loop
where it never goes forward,
and it's kind of frustrating.
So the solution for this
case is just to make sure
that you don't create a
view hierarchy on Create.
So now when the user
taps authenticate,
we still launch
authenticated activity.
The user says yes.
Now when we go back, we show
the unlocked data and when
the user selects the
data and we autofill,
and everybody is
going to be happy.
So these are my main
tips that I would
like to give from this session.
So basically, make sure you
annotate reviews for autofill.
You test your standard
services and make sure
they work with the
service authentication.
So I have some links here.
If you go to the
official Autofill guides,
we are explaining
all these topics,
and we have links for
the Autofill Sample
Service as well.
That also has all
these apps I'm using,
I'm using for [INAUDIBLE].
So that's it.
Thank you for coming.
SPEAKER: Thank you.
[MUSIC PLAYING]
