[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]