Android Dev Summit 2018 Livestream | Day 1, Theater 2
Articles Blog

Android Dev Summit 2018 Livestream | Day 1, Theater 2

August 10, 2019


Coming up next: Getting the Most Out of Android Lint by Matthew
Gharrity SPEAKER: Howdy, welcome to another Android
developer summit! So how many people went to the last one?
How many people enjoyed the last one? We liked it here, which is
why we did it immediately again three years later. We were just
building suspense to make it extra special. Hopefully we can
do it again. A lot of this content, all of the — most of
the content is live streamed, all of it is being recorded. If
you prefer consuming this through a live stream, I can
pause occasionally and buffer and maybe that will make it more
of a live stream situation for you. I’m Che it, I — Chet, I lead the toolkit
team, I’m emceeing today. And I am making it a nice enough
event, but short enough so you are not tired of the emcee. I
will tell you how this thing is going to work today.
So Dan went over some of it, and I assumed you went over the
keynotes as much as I do. The most important to me is
office hours, there are two reasons why we like to have
these events in Mountain View, it is such an interesting city
with so much to do, we live here, and every day we are here.
So obviously, Mountain View, for the culture.
And the second reason is Google is just up the street, which
means we can drag a lot of engineers from the team that
build all of the bugs that you are now dealing with into the
product, and we like to bring them into the conference to help
answer all of your questions. The key thing for you to know,
though, is all of those people aren’t here all day.
We have broken up the event into four half-day sessions, and
there are different people in different teams in different
technoloies represented at different times.
And so there are three scheduled posted, there are screens around
the conference. This is one of the screen sscreens, if you
can’t read this, maybe you can read the screens outside the
room instead. There’s a rotating schedule, will tell you
when people are on where, if you have a question for the location
team, make sure you are at the right time. You can skip
sessions if you want, they are recorded, and there are people
in all of those sessions. So ask the right questions, find people, they are here at the
right time. There’s App Review clinices, there’s the hashtag on
Twitter, #AndroidDevSummit, there’s the application. And
if you don’t have it, it is an instant app. Do your favorite
search in the search engine, click on the link if — for the
instant app and it downloads instantly. There’s a party
tonight after the session after 6:00, that will kick in, a party
with a bunch of engineers, where we all have the excellent
experience of talking to each other while the DJ is playing
the loud music and having conversations that go along the
lines of, what! What! Enjoy the party, enjoy those
deep conversations with the new friends, that’s about it. And
one more thing, there are three different session links.
There’s the long session, 40 minutes. There are shorter
sessions of 20 minutes. The intention is to link these
things, you will go for both of them at one slot. It is awkward
to get up in the middle of a crowd, so we are about to see
two in a middle here. Please stick around for both of them,
if you need to get to one on the other side, try to do so quickly
and quietly, we are going to roll from one into the other.
And then there’s lightning talks that start at 12:05 and will run
for an hour, those are going to go back to back into each other.
So stick around for those.
And that is about it. I’m standing in the way between you
and technical content. I would like to bring up Matthew
Gharrity to talk about Lint. Thanks. [ Applause ] MATTHEW GHARRITY:
All right, let’s get started. I’m Matthew, on the Android
Studio team, I work on project stability, call integration, and
we will go to the next slide. And one of the most exciting
things I get to work on besides project stability is Android
lint. It is a very powerful tool, you know a lot about it,
but you might not know the cool things it can do.
So despite the name, it is not just a linting-tool, it is a
full-fledged stack analytics framework, it is powerful, you
can write your own checks and I will talk about that today.
No worries.
This talk is really for anyone really interested in programming
languages, compilers, stack analysis, and for anyone that
has to deal with bugs in the project. So that is for most of you. Yeah, one last thing, I only
have 20 minutes, there’s a lot of material, I will go fast
through the slides. Try to keep up. At the end of the day, you
can watch it in half speed on YouTube and get a sense of it then. Perfect.
All right, let’s get started. So what is Android lint? A lot
of you probably already know, if you don’t know the name, you
know what Android lint is. It shows up in the IDE saying that
you did something wrong. In some cases, it is like telling
you that Gradle is out of date, do you want to update it, or
maybe you are not calling a super method in a method that
expects you to do so. In Android Studio, in the IDE, it
will say that there is suspicious code, take a look.
Sometimes there are warnings, sometimes there are errors that
will fail the builds. So some of you might not know
it, there’s a lot of the ways to use Android Lint. The first is
on-the-fly, that I just mentioned, in the IDE as you are
typing, shows the error messages right away. You can also do
inspect code, this is an action in Android Studio where you can
run a batch analysis of the project, a good way to audit
your project for common errors. And an action called run
inspection by name. If you have a particular bug in mind, say
you want to find a lot of thread annotation violations, you can
run the inspection by name, run the entire projects in one batch
analysis and look through those one pie by one. You can run
Lint on the command line with Gradle, Gradle Lint debug, it
will do a batch analysis for the project. And the great thing
about that is it will make an html and XML report. You can
parse the XML report, or you can do the html report and do the
warnings. If you know what Lint is, I want
to dive into the advanced use cases, because it is a powerful
tool. I will talk about configuration, and it is
actually really important. For big projects, you want to make
sure that Android Lint is working for your projects and
needs. I will talk about annotations, it is a powerful
way to mark up your code to help Lint help you more. Lint does
as much as it can, but sometimes you need to give it hints to
help you more. We will talk about Lint internals, I’m
excited about this, I want to give you a good mental model for
how it works under the hood. This will get you set up for
kind of realizing how powerful a tool it is and writing your
customcustom Lint chuck schecks. We will talk about
configuration. The easiest way to see what Lint is capable of,
Android Studio, preferences, inspections window.
You will see the heading, Lint, and all of the inspections that
lint has. There are are hundreds, most are enabled by
default. There are some that are not, and take a look at
them, some of them may apply to your project, even though we
don’t enable them by default. One example is call
interoperability, this is a set of checks we created so you can
call it from link code and vice versa. If you do something that
makes it difficult, Lint will tell you to re-name the function
so it is easy to call from the other language. There is
another way to configure Lint, with Gradle. If you go into the
Build.gradle file, you have this Android block, as you know. You
can write a Lint options block, and there are powerful options
here. So this first option, I will go
through a few examples. This first option is a powerful tool,
if you have a big project, you want to pay attention to this.
The Lint baseline, when you add this to your options, Lint will
look at all of the warnings and errors you currently have in the
project. And this will give you a clean slate, so you can say,
hey, I want to take a baseline of this point of the project,
forget about all of the thousands of warnings that I
already have. And I only want to look at new warnings and
errors and new code that checks it. And this will help you get
a handle on the massive amount of code that you have so you can
have clean code going forward. When you have more time, free
time, you can knack go back and look at the baseline issues that
Lint stashed away. Once you have a clean slate, through a
baseline, or you want to do a new project, you want to say, I
want to have clean code forever, starting now, you can turn on
warnings as errors. I encourage you to try it out. And if you
want clean code, try to get this to work for you. And then, like
in the last slide, you can enable specific checks that are
not on by default, like interopability. Some of you may
have this Lint options block set up. And some more advanced
things I want to talk about is performance issues.
So one of the reasons we have this lint Lint options block is
a lot of people run Lint on the continuous integration server,
they are checking the application for warnings,
errors, they block Lint submit if you have it checked in. And
some people are concerned with performance.
So just a few tips here, real quick.
Try to avoid the check all warnings option, I know it is
tempting. I know I told you to enable more checks, but some of
the checks are off by default for performance reasons, for
example. If you check all the warnings, man, my time to check
the project just doubled. Be more selective in the checks
that you turn on.
Also avoid the Gradle lint tasks, it is a parent task of
Lint debug or release. It will run it multiple times on the
project in each Lint variance, that’s a simple gotcha to avoid.
Use the ignore test sources function. By default, we don’t
look at the test sources for warnings or errors, the theory
that you don’t care about how clean your tests are. But this
option makes it so you don’t parse your test sources at all.
So presumably, all of you have well-tested code. So this
option will help with that, to make things go faster.
Let’s switch gears a bit, I want to talk about annotations.
They are a really powerful way to live Lint hints for specific
issues that you want to look for.
And so, I’m just going to go for a few examples, you know about
the nullability annotations, you use it a lot in Java, you don’t
need them, it is built into the language.
But we also have really Android-specific annotations,
that you should check out. There’s the required permission,
this is an interesting example, we kind of annotate certain
Android APIs with requires permission, like the set
wallpaper permission, and Lint does analysis on the code that
calls into the API, is the program checking that they have
this permission? If you don’t, we can worry, hey, it looks like
you have not checked you have this permission, this may crash
at runtime. And this impacts the users quite a bit. There is
also one of my favorites, kind of annotations, which is UI
thread and worker thread annotations, there’s thread
annotations in url. And these are really important,
actually. So a lot of — a big problem
with application development is a lot of UI frameworks require
that you only up Tate the UI on a single thread, the network
thread, and everything else is on background threads. If it is
on the UI thread, it might block, you will not see a crash
report, the user is frustrated, it is hard to track these
issues. We have these threat annotations where we say these
method should only be called on the UI thread, or the worker
thread. And we have some analyses. So I will actually do
a demo of these analyses. Hopefully that is set up.
So let’s switch over.
Awesome. So I will go through an example.
This is just Kotlin, let’s say that we have a function, oh, the screen
is black. You’re right.
It was there for a second. Awesome. Let’s get started. We
have a function, update UI, this is run on the UI thread. This
is updating the user interface, whatever you want, and the
network request. This is a contrived example.
And this does some stuff. All right, and unfortunately,
someone decided to call a network request from the update
UI method. So this is a problem, as you can see. There
is no errors or warnings, and studying this is hard to track
down in general. If you know about the threat annotations,
you can add the UI thread here, you can add the worker thread
annotation here. And instance instantly, Lint says you are
making a worker request on the UI thread, that freezes the UI,
you don’t want that. So I encourage you to use these. And
you might think, this is a trite example. This is too simple.
In the application, we have the UI method that calls the
function, FU, and that function calls something called bar, and
then that bar function calls the network request.
There is just multiple layers of indirection here. And you might
think that Lint cannot help us here. It can’t be default, it
for performance reasons, we don’t do advanced analyses. We
have an analysis for this. I will show you an example of
that. You can do run inspection by name. The name of the
inspection is called wrong thread, and then
interprocedural. You select that, select the scope, I will
say module scope. And bam, it will find the path from Fu to
bar to network request. You cannot see the error message
right here, so I will copy it for you. I will remove the
class names, you can see the error message says, hey, you are
doing the UI, going to fu, bar, the network request, that is
annotated with worker thread and that is an issue. Let’s go back
to the slides. So please check that analysis is
off by default for — it is being performant and doing a
program analysis, pretty expensive. Use it when you can,
try to see if you can find any bugs in the application.
All right.
NERBS next I will talk about Lint internals. This part is
really cool. The way Lint works, it starts
out parsing a source file, so you have some Java or Kotlin
laying around, it builds abstracts syntax tree, and then
we wrap it in UST, universal Syntax
Tree, and this may sound pretty familiar. And this step is
really important because it means that when you write a
check, you only have to write it once, it works in both Java and
Kotlin. That is really convenient. When you write a
Lint analysis, you are writing directly on the UAST. When you
are writing the Lint check, you are scanning the AST for the
source code, calls, and expressions you are interested
in and that is how it works. And Lint actually works on all
types of files, so you can look at Gradle files, you can look at
XML files and resources. This is powerful, it gives a
wholistic view of your application and can provide a
lot more helpful messages with that.
A couple more points here, so type information is available.
It is not just — you are not just looking at text, you have
the whole AST, you can do method resolution, examine the class
hiarko of of the class you are looking at, that is important
for preventing false positives and having powerful Lint checks.
That is what makes Lint useful. We have tight integration with
the IDE. And Lint does show you the warning messages right in
the IDE. That is critical, if you don’t have that, a lot of
your messages are lost in some build-up somewhere and it is not
useful to most people. And so, with that, we are going
to move into writing custom Lint checks. This means that, you
know, Android Lint is a framework. You can write your
own Lint checks. If you have something that annoys you, a
common bug that you run into on your team, or something that you
want your colleagues to watch out for, you can run your own
Lint check, upload it to the code base, and all of your
colleagues will see in the I it DE this highlighted.
And Lint has an unstable API, we don’t promise that we keep it
the same from release to release. The good news is that
it is not changing too often, but no promises.
The other good news is that unstable APIs are really fun to
play with. All right. And with that, we
are going to move into the demo. So let’s switch over, awesome.
All right. So don’t bother reading code too
much. The example I want to set up
here is that you see that your call logs are calling
thread.yields. If you look at the documentation, there ask is
not a useful method. If you are running concurrent data
structures, it is useful. But in other ways, you want to avoid
it. It doesn’t do what you think it does. So let’s say we
will write our own lint check that calls thread.yields. So
right now, it is not highlighted, there are no Lint
checks yet. I want to show you how I have this set up. You
have an Android application module here, here it is called
app. The way you will write your on Lint checks, you will
have a Java module, checks, for example. And you are going to
add a dependency from your Android application to the
checks module. And we have this nice Lint
checks block here that makes it easy to do that. Once you have
that set up, and I’m skipping over some of the details here,
but I’m going to have some links at the end. I can look at
sample projects. Once that is set up, I can go to the Lint
check itself. You have a class, yield detector. This is a
detector for calls to thread.yields, it extends some
classes in the Lint framework, and I have typed up some of the
metadata for this check that we want to have. There’s a name,
brief description, and explanation for how to fix the
issue, the severityseseverity, whether it breaks the build,
etc. And once I have the metadata, I’m going to start
typing some code here. So one method to be aware of is
called Git applicable method names.
So the way lint works is, you know, there’s a couple options.
You can make your own AST scanner, which will give you
total control. You can scan the source file, looking for
whatever you want. And for performance reasons, we have
these hooks where you can register with Lint, hey, I’m
only interested in method calls with this particular name. And
so here, we are actually only interested in method calls with
name yield. And if I have any typos, it is
not going to work. So let me know.
Haha. Once you have the hook in place,
we have to write the hook itself. So here, we can say
visit method.
And I wil will make sure that is — this method is
only called when we come across a yield function call. We will
say, okay, let’s assert that the method name we are looking at is
actually yield. So this should always be the case.
And then, because we have type information, we can do due
diligence and making sure we don’t have a false positive
here. Maybe there’s another class with a function called
yield, and we want to make sure that the Java link thread.yield.
So we will check to make sure we is have the methods, look at the
evaluat evaluator, is the method in class, we will pass the
revolve method node and give it the class name. So
Java.link.thread. So this means that if this method that they
are callingging is part of the exact class, we can record the
error. And context.report, I will give
it the issue that holds the metadata we have above. I will
give it the node, I will give it the locations. We are telling
Lint, this is where the error is, what you should highlight.
And I think I have to give it a message.
So let’s say, please don’t use this.
And also, you should use a more helpful error message.
All right. That’s all it takes.
If I have no typos, I’m going to make the projects.
It looks like it is done. If I go back to our application, bam,
lint scanned the source code, picked up the check right in the
IDE. And this is powerful. You can make it pop up for your
colleagues and everything. Awesome, we will go back to the
slides. All right.
So 50 seconds left, happy with the timing here.
Here are some links, I want you to check them out. If you never
read the overview on the development page, go there,
there’s a lot of information from this talk and a little bit
more. Please check out the
annotations page, there are so many that can prevent a lot of
bugs ahead of time. If you are really excited about
this demo I just gave, check out the sample project on GitHub,
where you can run custom Lint checks. If you have an issue,
we have a Lint mailing list. Many of you know Tor, he is
active on the mailing list and I am, too. We answer all of the
questions that are asked there. And with that, thank you so
much. If you have any questions, I
don’t — don’t ask them now, I wills will be in the sandbox
afterward. Please check out custom Lint checks. Thanks. [ Applause ]
Coming up next: Testing Rebooted (with AndroidX Test) by Yuki
Hamada, John Gerrish SPEAKER: Good morning, everyone. Great
to see so many people here interested in testing.
My name is John Gerrish, with my colleague Yuki Hamada, we’re
presenting a session on testing APIs today.
To get started, hands up, anyone who has written unit tests. It
is not a trick question, good. And what about integration
tests? You can be honest. Awesome.
Okay. So let’s get started. Click. SPEAKER: I have a question while
you are setting up. Is this related to the project
languages? SPEAKER: There’s a project
nitrogen talk tomorrow, it is near the end of the day. I
strongly encourage CHERK checking it out. The topic we
are introducing today is part of the grander vision, along with
project nitrogen, and they work in con conjunction.
Any more questions? We can do this in reverse.
[ Laughter ]. SPEAKER: I will ad-lib this.
On Android, there are two kinds of tests you might be familiar
with. There’s local unit tests, and then there’s instrumentation
tests. So let’s start by looking at local unit tests.
So these are ones that — these are tests that are executed on
your local developer’s workstation, on the local VM
running there. And, because you don’t need to
run the entire Android build chain, to avoid dexing,
packaging, installing on the device, these tests are actually
really, really fast. And on these kinds of tests, you can
use a tool like robolectric, which comes with
its own set of testing APIs to set up the state for your
Android aenvironment, or use a tool like Mokito and you can
step out the interactions with the Android framework. And
either way, they allow you to write tests, setting up the
state of the environment that satisfied the preconditions that
you might want in your test case.
The second kind of tests are instrumentation tests. And
these are the tests that will run on a virtual, or a real,
device. A real device could just be a phone connected to
your workstation, or if could be a form of devices somewhere in
the cloud. These kind of tests run slower
because you have to execute the whole build chain and install an
application on to the device. But they have the advantage of
being a lot more accurate, because the real lure of a
virtual device is very similar, or in some cases identical, to
devices your users are using out until the field. And this
brings you the confidence your app will behave as expected.
One criticism we heard, on these tests, there’s a lack of
testing APIs available. And that makes it difficult for you
to set up the state of your environment in a way that
satisfies certain preconditions, or edge cases, that you might
want to be testing. We heard you loud and clear, this is
something that we are actively working on.
So a bit of a history less on, 2017, Android I/O, we wrote out
the testing story, the software development pyramid. In this
model, we encouraged you to write lots and lots of fast,
scalable unit tests that tested all of your exhaustive
conditions. We encouraged you to write a smaller number of
instrumentation tests that will actually prove that all of these
units assemble together, behave as you would expect, on a real
device. And, in some ways, this was kind
of a compromise. It was a compromise between the
advantages of one set of — one kind of tests, and the tradeoffs
of another. It brings you a wholistic way of testing your
app. And we showed how this kind of
approach can lead to test-drivern development on
Android. First of all, you would start
with a failing UI test. This would be an instrumentation
test, probably written with Espresso, and it would test the
UI of your component, or your feature. And then you would
satisfy that feature by a series of units, classes, coming
together that are interactions. And you could test drive these
as well, using a tool like roboelectric, or Mokeyto, as a
unit test. And this gives you fast development cycles. When
you bring them all together, you can run the slower-running, but
faithful, instrumentation test and hopefully it goes green and
you’re done. Well, we enter a refactoring
cycle because maybe your code leaves a little to be desired
and you want to do some clean-up. You can spend some
refactoring cycles there before coming around to the beginning
of the cycle where if you have any more work on the feature,
you might add another test, test another aspect to the that
feature. And you will keep iterating until you are
complete, at which time you are good to submit your code and
move on to the next task. So at Google I/O this year, we
realized there was somewhat of a test writing crisis.
And because there’s so many tools available, it is not
always clear which one to use. And each of these tools all have
their own different styles and APIs and paradigms for the same
concepts that exist on Android. And the problem with this is
that tests written in different levels are not
portable across levels, it is stuck in the environment that
you have written on. So this year, in Google I/O, we
announced the render next test, it brings in testing as part of
the tool chain, as part of Jetpack. It includes some of
the existing libraries you’ve used before, some new APIs, full
Kotlin support, which allows you to run beautiful and concise
tests. It is available on and off device.
Well, last week, AndroidX test moved out of beta into release,
1.0. And it is also, as of last week, fully open-sourced. So we
look forward to welcoming your contribution contribute —
contributeutions. . All of it is being revamp ed
to show you the new styles of APIs. So please go and check
that out. Let’s take a look inside.
The first module that we pulled across was the existing JUnit
for support, the runner and the rules that you may have used before.
We’ve already added a new module, which we call core.
This includes some new APIs: ApplicationProvider, as its name
suggestsZsuggests, is a quick and easy way to get a hold of
the application context. ActivityScenario, which is a
brand-new API that provides a course and fine-grained activities, and
FragmentScenerio that provides a set of testing features for
fragments. We also brought Espresso into the AndroidX
family. It is a set of view-matching libraries — a set
of view matching APIs and actions, allowing you to match
and interact with those UI elements.
It also includes some other things like the ability to
capture intents for the system. And finally, we’ve also released
some truth Android extensions. And truth is Google’s open
source, fluent testing assertions library.
And we brought a bunch of components for Android subjects
, which allow you to test your Android objects beautifully and
concisely. And those of you who have been
using roboelectric will know that we had a version, 4.0, in
beta for a while. And, as of last week, we did a
simultaneous release that has now gone into final.
Roboelectric four fully supports all of the unified APIs that are
in AndroidX test, as well as a number of its own new features and improvements.
Okay. So I would like to welcome Yuki on stage, who will
give a deeper dive into some of the APIs available. IA [ Applause ].
SPEAKER: Thanks. Hi, everyone. So let me introduce our new API.
This starts with ApplicationProvider, a new way
of accessing context from your test support. So when you look
on Android testing, you need to handle two different context
objects. The first one comes from application under your
test, and the second one comes from the instrumentation APK,
where your test code is stored.
So with today’s library, we have two different methods to access
this context object. And this makes your test code harder to
understand, because the library used, targets the
context meaning the context from your instrumentation APK, while,
sorry, the target context means that context from your
application while get-context means the context from your
instrumentation or APK also — it is not obviously which one to
use for your tests. So, in our new API, we hide the
instrumentation context from target API, and we only — only
the ApplicationProvider provides an application context in the
form of your application graph. And let’s take a look at the
example. So here, let’s say we have a
test for the location tracker activity. And in the set up
method, we get the target context in the old-fashioned
way, and we type cast the location tracker application, so
that we can reduce the mark object for testing, and the
second line, set a mark object for that. This code is simple,
and it actually works. But you could use the run context and
face the runtime error, and ended up with wasting your time for debugging.
Now, with the new way, application context provider
provides your context in the application graph.
So you can do exactly the same thing, but there is less chance
for confusion. Okay.
And let me move on to the more complicated stuff, activity
scenario. Actually, before I — we dive
into it, I have a few questions for you. How many of you have
written your own activity, and handled the live cycle
transitions by yourself? Raise your hands if you are. And how
many of you have shifted your activity with a bug related to
life cycle? Many of you. Who didn’t write
the tests for that? Who did not write the tests?
Cool. Well, yeah, I see some hands up,
keeping up. And to be honest, I do, too. And I agree.
Writing tests for the activity life cycle transition is pretty
hard, and there is no good API in the testing library now.
So that’s why our team have sought for a solution, and we
developed the ActivityScenario, which you can use it for driving
your activity state to laboratory state for testing.
So let’s visit the activity state first.
So the creative state is where activity is created, and
instantiateinstantiated. But it is not visible to users yet.
Or activity, sorry, can be created state, while it is
running in background. And the started state is where
the activity is created and started. It is partially
visible to the users, but not the fore ground of activities.
The activities running in picture mode is also in this
state. And the the resumed state is
where the activity state is visible to users and running in
the fore ground. And under the framework, you can
change the life cycle state anytime the user interactions,
so the activity has to handle those transitions properly for a
good user experience, otherwise you see some bugs. And activity
scenario provides a method moveToState, where you can move
it to testing. We will look at the testing code. We have a
test, location Tracker Activity, and here we want to verify that
location listener is properly registered from the system when
the activity becomes a creative state.
So across, we have to start the activity. The launch activity
takes your activity graph and it starts the activity and waits
for it until it becomes a reasonable state.
And move to state initiates the transition, and moves the life
cycle state to the created state. And the older method, the
older ActivityScenario method works as a broken code. So
after this method call, it is guaranteed that activity’s life
cycle state to be created. And then you can inspect your
activity’s internal state by calling activity method. Yes,
that is easy, and now we have our API.
And also you can use ActivityScenario for testing the
creation of your activity. So activity
creation happens when your activity is running in
background for a long time and where you can come back to it
later. And your activity has to save its internal state, to a saved
instance state bundle, where it is destroyed, otherwise you will
lose the state. We have a re-create where you can use the
testing scenario. This is the example code.
So here, in this test, we wanted to make sure that input
text is restored properly after the activity is re-created after
disruption. So first, we have some test
data, like test user, as our input. And again, we started
the activity. And then we input — we filled the text box by u
using the Espresso library. The ActivityScenario works
nicely with Espresso, and we call re-create, which disrupts
the activity, re-creates the instance, and waits for the
activity to be a reasonable state. And using the Espresso
again, we can make sure that the text is there as we expected.
Yes, it is also simple. Okay. And finally, I would like
to show you one more example from the Truth extension.
Intent Subject, by using Intent Subject, you can verify your Intent values and it produced
really good schema-friendly error messages, if that error
happens. This testing example, again,
this time, we want to make sure that Intent — we want to make
sure that the data intent has an expected contact name in extras.
So first, we create a bundle of the data intent. And then we
start with three lines, one is checking if that intent has the
expect action, the second is type, and the third is extra
bunted bundles. If the value does not meet the expectation,
you see this error. And you can immediately know the, in this
example, the intent action is not what you expected.
And there’s a lot of components that come under the release 1.0.
I cannot show you everything today. For example, we have
more assertions, and we also have Android Builders where you
can create your testing data easily. And also scenarios for activity and fragment. You can
look at the documentation to see more. I hope you try it out after the talk.
Okay, so this is our solution for the test writing crisis.
So with unified API, you no longer consider whether you have
to write an instrumentation test because you can now just write
the Android test, and that test runs on both runtime
environmentsenvironments nicely. With the unified API, you can
focus on what to test and you can forget about where and how,
and to ensure the contistancy of the behavior of our API, we have
a verification test and we run the same tests against the,
sorry, we run the same test on locally with Robolectric and on a bunch
of devices from the API 15 to the latest version.
And let’s go back to the workflow that we showed you
earlier in this talk. So we can execute the test
driven development much more effectively using the device
agnostic tests, with the tests, writing it in a unified API.
As a recommendation, we recommend that you write that
test with Robolectric until the call is
ready to submit, and run the same test, but on a battery of
devices before you submit the test to maximize your
confidence. And also, you can run the same
test as a continuous integration test against the binaries.
With the upcoming nitrogen tool change, you can set up such a
configuration easily. If you want to know more about
the Project Nitrogen, we have a session tomorrow, and we highly
recommend that you attend it. Thank you very much for
listening, and have a happy testing.
[ Applause ] .
Coming up next: Optimizing User Flows through Login by Sean
McQuillan, Jeremy Orlow. SPEAKER: Hey, everybody. With
that interstitial music, the point is to make you really
happy for when the next presentation starts. We will do
lightning talks that we have not done before. We will see how
well it works. The way it is supposed to work, we are going
to roll from one into the other. They have 5 minutes to go, when
it is up, I will call time. In the back, they are going to
press a magic button that makes this sound.
So that’s how we know it is time for the next talk. And
otherwise, I have no purpose being here. I will talk about
the next speakers, optimizing user flows through login, and I
will start my timer. Thunderous applause for the
lightning talk, please! [ Applause ].
SPEAKER: Welcome to lightning talks, I’m excited to talk to
you today about how to welcome your users to your Android app
whether you when you get a new phone. Why is this important?
On the Android system, we get a new phone every 2 or 3 years and
we reinstall the apps that have been installed, and all of the
users do this as well. If you buy a new phone every two years,
half of your users are going to get a new phone this year. And
if you don’t do anything at all with the application, you will
give them a cold welcome when they come back. You will show
is them an email and a password form that shows them that they
have never used it before, you will disrupt the flow of the
app. You want to welcome them back to the application and
create the continuous user experience that jumps from their
old device to the new device, so you don’t have friction or
retention problems for these users that are switching devices
and using your application. There’s a couple products you
can use in Google that help you do this. So one of them is
Google sign-in, it is a button you press when you log in. It
is a button you press, you log in, it is amazing
for the flow because it makes it simple to do the log in. It is
good for the activation because it makes it easier to log into
the app. In your phone, it is good for reactivating the users
because they have to click a button. On Android, you can
configure it so you don’t can have to click the button on the
new device. Google sign-in works on iOS,
Android, as well as the web. So you can use it everywhere, and
it is a great way to add federated log-in to your
application. And another feature on Android
is Smart Lock for passwords. It is a password manager, stores
user names and passwords, federated credentials in the
cloud, when the user confirms they want to save the password
after they log in. So in the old phone, they save the
password, on the new device, in the application, you will give
them a warm welcome and say, I know who you are, do you want to
log in with the new account? And it will create the seamless
experience and log the user into the application. One of our
partners, Netflix who is here today, they used this and they
found that they had 20 percent fewer support requests. If you
think about this, every time a user contacts you to get a user
name and password fixed, there are five that didn’t, and they
will just become a retention problem and may never come back.
This is a great way to improve your business metrics.
And Autofill is another feature we launched in Android
O, works like smart lock. It is an Autofill system, it Autofills
TextViews the way you would think, and one of the most
common ways is user names and passwords. After they log into
the old device, they will choose to save it to the Autofill
service, that comes to the same data store, smart lock. In the
new device, it Autofills. There’s a few ways to get the
application ready for Autofill. One is to set up a digital asset
link that links the web and the Android app. This is great, it
has pluggable password manager and all of them support this and
then the user can log in on the web. If they are using the same
password manager on the Android device, they are go to going to
get the credentials transferred. And then the password is saved
and you get the seamless experience to the Android
application. And another thing you have to do for Autofill, you
should set up Autofill hints. Tell the service what the user
name and the password field is, and that way the service does
not have to guess and maybe get it wrong, probably the worst
experience you can give your users. And the last thing we
are going to talk about is auto back up, I will hand it over to
Jeremy. SPEAKER: It is a great way to
also provide continuity to your users.
And so even if your app syncs to the cloud, there are still
device specific settings you can back up, and no user who has
been using your app for a year wants to see a tutorial on how
to launch an app on the new phone. So auto back up, when
the phone is idle, we back up to the cloud, the data is stored
securely, you can have up to 25MG, if you go over that, the
back ups fail. On the new phone, when the user restores
the app, it will restore the data before the app runs for the
first time. And the user picks up where they left off without
any friction or churn. And you can also include and
exclude specific files, so you can exclude OAuth tokens, and
keep users engaged when you switch phones. We will be back
in the back. [Gong ringing].
SPEAKER: Be around if you have any questions.
Coming up next: Kotlin + Watch Faces by Jeremy Walker.
SPEAKER: Hi, I’m Jeremy Walker, a developer platform engineer
here at Google. I wanted to talk to you about how I use
Kotlin to make watch face creation much easier on Wear OS.
So watch faces are kind of hard right now, and you have to write
about 600-plus lines of code, it is not like a nice app you do in
Android or iOS, where you declare the UI in the XML
format, you have to manually paint everything, and then you
have to include a bunch of code so when you are in ambient mode,
you are not hurting the battery life. I was trying to think of
how to improve this. Last year, we launched the support for
Kotlin. So I thought, how can I use Kotlin to make it easier? I
converted the whole thing to Kotlin, which reduced the code
lines a lot. But I found something else with Kotlin that
made it more cool, and that was something called DSL.
So what is Kotlin DSL? Well, the best way to understand
what domain-specific language is to compare it to a regular
programming language. So, again, domain-specific lang
language, that did not really help me what it meant. If you
compare to a general programming language, Kotlin or Java, you
have a bunch of key words and classes and languages, and you
make a big app, on the other side is a DSL that focuses on a
task or domain. It foregoes a lot of functionality and allows
you to do that specific task. You probably used external DSL
and have not realized it. For example, SQL, for manipulating
databases, that is a DSL. Those are expressions for manipulating
strings. They have an independent syntax, reduce
functionality, you don’t have methods or a class to make them
work. You are not going to write a full-on application in
them, either, at least I hope not. And for SQL, the first key
word indicates as a verb what you are going to do. You are
going to select and update. The disadvantage is you have to put
it as a string literal. You have to pray and hope that you
spelled everything right until run time, it fails and you have
to see what is going on. And Kotlin DSL, it extracts that out
the string and puts it in the code so you can have type
checking, you can have code hint and all of that good stuff that
comes with your IDE. So now that I have an idea of
what it is, I like to show you two structures really quick.
And I used the latter, there is one called creating ones for
chain method calls, and the other is nesting of Lambda. So
recognizing DSL is really subjective. You know it when
you see it. So let’s see some. So this is Kotlin DSL for SQL.
You can probably look at it, and if you know SQL, you can
understand it right away. And it is all words, like Slice,
then I select all, group by,ords order by, and limit. This is
all type-checked, you get code hinting so you don’t spell
anything wrong. This is great and understandable, this is DSL.
The DSL for the watch face that I liked is the nested Lambda
structure. So this is to create a watch face, you can see it
right there, create a watch face is a verb. If you look at the
structure, you may not know anything about making a watch
face, but you probably understand what is going on
right away. Analog watch face, it is not digital, it has arms.
Colors, the dimensions for the hand, the hour, the minute, the
second, I understand that. And watch face background image,
that is all — it is very declarative, you can understand
it right away. This is type checked, and I get code hints
and all of that good stuff. In the end, I get this nice little
watch face with no work. And the 600 lines, they did not go away.
I put them in a helper class and combined them with the more
important class that interprets the DSL. If you are making a
watch face, you only need to know about the DSL.
So what is next? I — this is kind of an
experiment that I did as a code a lab, check it out, it will
take eye you 15 minutes to make a new watch face, search for
Google codelab, it is under the Wear OS, search under Kotlin.
You can see how to make a watch face, you can see the source
code for how I made the transition between DSL and
interpreted it into a nice little watch face. And more
importantly, hopefully now you are a little bit interested in DSL,
you can use it in a project to make it better, or you can go
and use something like the DSL for SQL, for testing, or in html
in the Kotlin coding type checked. So thank you for the
talk, for letting me talk, and hopefully I have gotten you a
little bit interested in DSL. Thank you. [ Applause ]
Coming up next: Push Notifications: An India
Perspective by Amrit Sanjeev SPEAKER: Well down, no gong.
Next up, push notifications. SPEAKER: I’m Amrit, a developer
advocate at Google. I want to talk about push notifications
and how interapp developers are getting the delivery higher in
the region. I want to talk about a stat in India, we have
314 million-plus smartphone users, growing on a 16 percent
year on year growth rate, your apps have a chance for users and
great business in the region, and it comes with a lot of
competition. There’s a need to have a better engagement as well
as lighting your users. And push noteification is one of the
mechanisms a lot of developers use to engage your users. And
when it comes to push delivery ratess some in India affect the
delivery. Until recently, data plans were expensive and people
have the habit of turning off mobile data when they are not
using the internet. So when they go out the WiFi zone, they
will turn the mobile data off, and that changes the behavior of
time to lift parameter for the push notification, if you have a
short one and they turn the data off during that period, the
notification is never delivered. Recently, new carriers have
come in and reduced the data costs drastly, and now those
behaviors are changing, but not enough for you to ignore that
change. Secondly, a lot of devices with
custom behavior, or Android builds, where your notification
and, because of battery optimization, they kill off the
notification services. They sometimes force close the apps,
and avoid the app for never getting the notification
delivered to it. That is another problem.
And then your time to parameter, if you actually
increase it by, say, from four to-eight eight hours, you see a
drastic improvement, or a large improvement, in notification
flivverdelivery. You might go over the WiFi user. So that
makes it interesting. And in any other region, notification
frequency also, the number of notifications that are sent to
the users is affected and people get irritated and turn off
notifications if you do it too many times. So collapsible keys
and things like that are very important here.
And I want to talk about three design patterns that developers
are actually trying out for querying use cases to improve
the notification delivery. One is buffering the notifications,
to give you understanding of your use case and how the
buckets work better for you. The neckinism developed here,
there’s a period job that runs, refreshes the npm token, sends
it to the server, when the server gets the data, it maps
the fcm and the update. When it you send out oo cap — a
campaign, they split it based on recently. And you put
in the first batch based on what is in the last 7 days, the next
batch is to update it from 7 to 31 day said, all the tokens from
the 7 to the 31 days, and the third is 31 is above. And what
this allows us, in each of these buckets, the parameters for each
of these buckets will improve notfication delivery, you have a
better understanding of which users get the notification and
might react to your notification better. And because you have a
lot of tokens, which are not updated frequently, or the users
never send that update cycle, you don’t end up calculating
that in peer notification delivery and you miscalculate
the effectiveness of push notifications.
The second one is basically where you have, again, a job
that comes in. It checks whether a notification was
delivered to the device from the last one or not. If not, it
will go to a service, an RS service in the notification to
the user. And you have to ensure that this
does not wake up the device. This is not the most efficient
way of doing things, but it still works. And the last I
will call out is data messages in the scenario. In the case
you want to send a message, there’s a sale that is going to
start at 12:00 you want to show the message at 12:00, and your
users are 20 percent more on this service. Instead of
senting at — sending at 12:00 and hoping that the users
receive it, they will send it two days before, which as a data
message. So the app will receive it, and then based on
the schedule that is within the data message, they will schedule
a job to come up at exactly the right time to display the
message to the user. SPEAKER: That is time’s up.
SPEAKER: [Gong]. SPEAKER:Coming up next:
Understand the impact of Generic System Images (GSI) by Hung-ying
Tyan. SPEAKER: Hello, I’m Hung-ying,
I’m talking about GSI, the generic STIMP system images.
It is the purest form of Android framework that we can build from
AOSP. By purest, it does not have a device maker or carrier
customization. You will want to ask — AOSP has been
there for 10 years. Why does it become a thing right now?
It is because GSI is the central piece in travel compliance. So
remember the project travel, we took out the Android updateability prom in trial. We architected between the flame
work and the hardware original vendor implementation.
With this, we no longer need to update the vendor implementation with the Android
framework. This reduces the time for the
device maker to update their Android framework.
Now, to make sure that the boundary is not altered by
device makers at will, we require every treble-certified
device to pass a series of CTS and VTS tests with the Android
framework replaced by GSI. So with all of these powerful tools
in place, about a year ago, we started to see the momentum of
faster Android adoption this year.
So let’s take a look at the Android developer program
at Google iOS last year. Only Nexus and Pixel forms were able
available for you to try out Android Oreo. And fast forward
one year later at Google I/O this year, it was the first time
we had non-Google phones join the beta line up. It is not
one, it is not two, it is seven device makers joining us.
So the progress was phenomenal. We know we are on the right
track, and we will continue to push for it.
Now, despite that GSI is the central piece in Treble
compliance, we feel like it has a lot more potential than that.
So we set up a goal to make GSI be more accessible and useful,
not just for device makers, but also for the general public.
Including app developers like you, and even consumers.
An important first step toward that goal is to make GSI
available in AOSP. So, for this, we have published pie GSI in AOSP, so
you can download and build the pie GSI today. We are exploring
ways to make future GSI available earlier than the
release of the next Android version.
So you will be able to try out next century version earlier
than GSI. And, at the same time, we can
get early feedback from you. So the benefit is mutual.
So please stay tuned for our further announcement on this.
Finally, we understand that trying out GSI can be cumbersome
sometimes. We are looking into different
ways to improve the process. Right now, we have an idea of
trying out GSI without actually flashing GSI out to the device.
But I’m not going into detail here. We do have a working
early prototype at our demo booth.
In addition to that, we also prepare a set of devices. They
are all running on the same pie GSI i. So please do check out
our demoes at the Android platform sandbox.
SPEAKER: Thank you. SPEAKER: Coming up next: Buiding Reliable Apps When Connectivity
Is Unreliable by Naheed Vora, Ryan Hamilton.
SPEAKER: Hi, I’m a product manager at Android checkativity.
SPEAKER: I’m Ryan Hamilton, a manager on the Chrome networking
team. SPEAKER: So we will start with the — how many of
you have noticed this in the last few years? The signal is
flaky and you turn off the WiFi. Connectivity keeps changing
underneath you, and the application is trying to
understand what is going on underneath, is really
complicated. And, for creating a good
experience, we need to hide this complexity from the user. We
don’t want users to go and turn off their WiFi in order to use
the app. It could be any app that you can think of that the
user is using at a given point in time.
So who should care? If you are building a
user-facing application, maybe your app depends on mobility.
Maybe it is Google maps, or something like that. Or you are
building a gaming application or communicating app. Anytime you
know you need to react really, really fast, irrespective of
what is happening in the activity is critical. This is
important to make, that you address this point in your
application. And one thing I would add here
is that the user dropoff rate with had when the delayss are
1-3 seconds, or 10 seconds, it may vary in markets. If you are
in a market that is emerging like India, it may be resilient
to delays. If you are in the United States, if you go beyond
three seconds, you will lose the user.
So what I have here is a demo. And it is a Google assistant
demo, what we are doing is we are using the technology and we
will talk about that a little bit later. On the left-hand
side, there is no optimization on the phone. On the right hand
side, there’s an optimization, and we are doing a Google
assistant query and the user is walking out of the building.
The phone is connected to WiFi, as the user walks out, the user
loses connectivity. Let’s see what happens.
Trying to click. This is interesting.
Okay, in the interest of time, this is what happens.
The one on the left-hand side, it takes — is it possible?
Awesome. Okay. So the — we will make a query,
and what it is doing — it is in direction to Oxford service in
London. And you can see on the right, the response came back
already. The left one, it is still waiting and waiting. The
right one is like, eh, I don’t have anything to do. I’m out.
The left one is like, ah, finally. This is a lot from
reaction time perspective. You want to have this resilience in
your app, it can reconnect fast irrespective of what is
happening in the connectivity stack.
So let’s get out of here. It is a separate problem.
Okay, so what it is using, what you need is you need a protocol
that can handle this different mobility where the device is
moving between the networks. And so that’s where the Cronet
and QUIC comes into play, the application layer and the
protocols that you are using can handle this mobility. So I will
hand it over to Ryan to talk about Cronet and QUIC.
SPEAKER: I will do this quickly. We have taken the network stack
that is inside of the Chrome web browser and made it available as
a library for apps to use, we call it Cronet, Chrome, network,
Cronet. Since it comes from Chrome, it has the reliability
and interoperability that you would expect. It is used by a
variety of Google apps, search, YouTube, maps, and available on
iOS as well. Coming soon, it is an option to pull from the Play
Store, you will not need to bundle it in the app. You can
get the automatic opdates and security and performance
improvementes. Part of the coolness of Cronet
is that it comes with support for QUIC, a new transport we
have implemented in the user space on top of GDP. And it does
some things that TCP can. It is a modern transporter, provides
new teachers and better performance. And with QUIC
connection migration, you can switch back and forth between
WiFi and Sailor. It has a bunch of awesome performance
highlights, we release every six weeks, it comes with state of
the art security. SPEAKER: And the best part is
that the platform optimizations are built in, you do not have to
do everything time there are Android releases, it will take
advantage of the latest and greatest that Android has to
offer. For any more questions, we have
a booth outside. You can talk to us, we are happy to help. Thank you.
SPEAKER: Thanks. Coming up next: Quick Ways to Ensure App Compatibility with
Android Autofill by Felipe Leme. SPEAKER: Next talk, as a bonus,
this person lets 10 minutes on Autofill.
SPEAKER: Hello, everybody. So my name is Felipe Leme, and I’m talking
about what Android Auto fill is and why it is important for you
to optimize your apps for it. It 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 platform managers
to do their job. To use Autofill, you need to select an Autofill service which could be
provided by Google, or third-party apps, like One
password, and many others. Last time I checked, there are about
30 different apps on the Play Store that provides an Autofill
service. And one key decision we made
when we designed the API is that it should work out of the box
with existing apps. In order words, as an app developer, you
do not have to support the app — if you don’t do anything, the
password manager will figure out what to do for you.
But just because you don’t need to change it, it doesn’t mean
you shouldn’t. After all, it is your app that is on the line,
and you don’t want to depend on the third party app it has no
control over. And the tip I want to give you, you should not
rely on Autofill service heuristics, you want to make
sure that the password manager does their job properly, you can
do it quickly and easily by annotating your XML views.
The first thing you should do is make sure that you annotate
what should be Autofilled, and you do that using the Android Auto fills filling stack. So
let’s say you have the user name and password loading screen. If
you don’t annotate it for Autofill, and the layout XML is
using user name fields and password fields, it is going to
work fine. When they use the instructor, they will say,
there’s a user name string here and password here, and that is
the user name and passwords. And say you are in Brazil, your
name is in Portuguese, and I grew up there and it is common.
So my fields are [speaking in language other than language].
So the password manager you get is this instructor, and it knows
what it is. So it is providing the Autofill data, and the user,
you have to manually type in the user name and password, which is the
problem to avoid with password managers. So you will annotate
the fields, the user name, and the password, you use password.
And on Java, we provide fields for the
user name and passwords, like telephone number, etc.
And there is another issue, you should annotate what should
not be Autofills, using the Android import texts.
So to see another example, in developing the API last year, 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. Am
when you are composing an SMS, or a spreadsheet, you want to
type something dynamically, you do not want to use a pre-define
said ed variance. This was annoying for me, I knew the API,
it is confusing for ra a user that doesn’t. So you can
disable the field for the activity, you can do it on the
whole activity layer by annotating the root view, it is
important for Autofill, no exclude descendantdescendants.
It will not use password manager when it doesn’t make sense and
it will improve the experience. And say you are using the tags
and you are so excited to change, that you skip the
presentation, the summit, and go back to your laptop and change
your apps. Don’t do that. If you are going to change, how are
you going to test the changes? You need to select a service to
see what is the data provided by the service, and you will say,
we will choose whatever comes with my device, Google Autofill,
or install a third-party password manager. You can do
that, but you can go back to that problem of relying on the
password manager heuristic, and we can provide it without a lot
of changes, and you cannot see what is going on with making
these changes. You can use the standard Autofill service, and
we can provide some samples on GitHub. We provide a couple
Autofill samples permutations project, one is the
basicservice, which is a service that only understand Autofill
hints. If you are using auto fithints on your app, you will
see something like this that will pop up, because in this
field, the user name, you will see is the the options. And on
the other screens, the base fill will not show anything.
And it has a pretty simple service, less than 200 lines of
code. If you are interested in seeing how it works, you can do
this a well. And debugservice, it will try to fill anything
based on your search IDs. This is useful to test what would
happen if you are not tagging your views.
So back to my SMS app, you would see something like this, and you
will click on two. And I’m just making sure that — okay.
So we will make sure that I’m seeing, I’m looking on the
screen. So when you click on two, you
are going to see this pop-up with some user data, which is
two, which is just the name of the resource ID. You can see
how confused it is for the user if they see something like that
on the app. And then, the final tip that I
would like to give is you should also make sure that the app
works when the Autofill service requires authentication. So
what does that mean? So most password managers, they don’t
retain the data right away, it is encrypted somehow. So they
will ask the user to authenticate, a master password
or a finger print to unlock the data. The way the framework
works, we are launching this, it belongs to the service on top of
the app stack. The user does the authentication, and when you
are finished, the activity resums.
So for most apps, it is not a problem. If your app is doing
something where it is resumed, you are revalidating, or
rebuilding this new hierarchy hierarchy, you might break it
out of view. So to test this, to make sure
that the app works in this scenario, you need an Autofill
service that requires a permpermutation, the
debugservice. And when you launch the
debugservice, you need to launch the Autofill and click and
select the debugservice, you will see the debugservice is one
of the options. We provided that example. And then you can
select this authenticate response option on the top.
When you go back to the app, when you trigger out of view,
instead of getting the data, and unlock it, you will have this
response toa thent caught. So icate. So when the user
attempts to — it will ask for yes or no. So when you click on
yes, this screenshot, the sample app where I have re-created a
new hierarchy. When you click yes, you will return to your
activity, and now from the framework point of view, all of
the data is different. So they don’t know that they have the
locked data for your activity, for your user name field, it is
a different ID. They are going to show the response again.
When there’s a click there, it will launch the authenticate,
and then it go backs and asks it again. So the user is now on
this groundhog loop where it never goes forward, it is
frustrating. And the solution for this case is to make sure
that you don’t — you create a view hierarchy. So the user
attempts to authenticate, we will launch the authenticated
activity, and now when we go back, we will see the unlocked
data and when the user selects the data, and we are Autofill
and everybody is going to be happy. These are the main tips
I would like to give from this session. Make sure that you
have your notater views, the tess in the standard service,
and the work with usera thent authentication. I have links
for all of these talks for Autofill service as well that
explains all of the apps that I’m using. That’s it. Thank you for coming, and I’m supposed
to say that the QA will be out. I have 25 seconds before I’m
going to be gonged out it. SPEAKER: SPEAKER: Do you want to
say anything else, or are you done?
SPEAKER: We are done, I guess. SPEAKER: Thank you.
SPEAKER: Thank you to everybody that played the game today. $1 did.
And we will assume that the users are able to touch the
device, or they can see what is on the screen. That turns out
not to be true. So these assumption s assumptions helps people with
disabilities to overcome obstacles.
Not what they are interested in or what they are actually able
to do. And so the way Android does
accessibility is it depends on the entire ecosystem. So we
were directly on Android, and we — we build a lot of the core of
it. But we really depend on the entire ecosystem to make this
work. So the accessibility framework is able to handle a
lot of low-level features, like magnification, you are not able
to build it into every app, if you do, we will have a nightmare
experience. And that is handled down close to the graphics
level, you want to magnify things. Accessibility
developers who work on services, TalkBack, select to speak, they
build these plugin services and the idea is that they generally
have a particular type of user in mind, they will go through
and really understand what those users need, what their
challenges are, and try to build something that
works for them. But they cannot do everything on
their own, they need to get information from, somebody who
is blind, you need to be able to speak what is on the screen. We
need to find that out from the apps what is going on in the UI,
and that is where we really need the help of the ecosystem and all developers.
So as a general model, we have these plugin services, like
switch access, voice access, and Braille, they are able to query
an API for the accessibility service to tell me what Windows
are on the screen and the views inside the windows, what text is
where, what actions are available on each view.
And then they can present this to the user in whatever way they
need to. The user does not touch the screen, it do do you
want to perform this control, that control, that gesture. And
we need the apps to provide the right semantics to do that.
And the — I want to try to make this as simple as possible. So
a few things to keep in mind. One is just to make sure that
the information that you are presenting to all your users is
as visible as possible. So color — luminous contrast is
the most importantsingle thing you can do in that regard to
make sure you are not using gray on slightly lighter gray to
convey information. Thatt can look cool, but it is difficult
for people to use. And the second is to prefer controls to
be big and simple.
It is sometimes — you want to cram a bunch of stuff to get as
much options as possible for users, and you want to figure
out what is important for your users can simplify things for
everybody, and for somebody who does not have perfect dexterity
to use it. We can have a 48 by 48 density independent pixel,
that’s a guideline we can throw out there, to have a uniform
standard throughout the ecosystem. That is set as a min
height and width thing. Next is to label toff stuff.
If you are conveying information visually, if you have a button,
just have a label and the labels should be precise and concise.
So the users who cannot see the screen can find out what they
do. And so people ask when in the
project should I consider accessibility? Early and often
is the short answer. The longer answer is, in each of these
different phases of your project, there is something that
you can do. So in design, ZERL generally the
things that I mentioned, keeping the contrast, control size,
labels, that will get you a long way. If you are using standard
UI patterns. But the more innovation you are
doing on your user interface, the further away you get from
the stuff we built into the Android framework. At that
point, it is really helpful if you can think broadly about the full range of
users who use your project. So the more gesture type things
that you are doing, you want to make sure that you are taking
into account how people are going to interact with that that
cannot perhaps perform that gesture.
During development, we have a series of APIs, Qasid is going
to show those, and we have testing tools that show, as much
as possible, we can automate the processes to make sure you are
handling these things correctly. So just to explain a bunch of
stuff about the complexities of users and things you can do, you
can forgive me for saying making accessibility easy, and I said
making, and not that we already made. In general, we want this
to be easy. We want to make sure that we are doing that, if
we are not, please let us know. If you are using standard com POFE components and ways, it
should not be complicated, like how a particular user is going
to use your project. It is something like, what does this
control do? And as you evolve, it gets less
easy. But we want to make sure that the incremental work that
you do for accessibility grows more slowly than the work you
need to do to serve whatever users you have in mind to begin
with. And now, Qasid is going to talk
about a way to think about the development process for folks
with disabilities. SPEAKER: Hey, my name is Qasid,
I work for Phil on the Android accessibility team.
Let’s get into it. If you really think about it, there are
two ways that your user can interact with your application.
Right? The first is consuming
information. This can be content that the user wants, or
indications how to use the UI. And the way we use information
varies from user to user. I look at it on a screen and I
process it that way. A TalkBack user will hear a description of
what is on the screen from a device speech synthesizer. Once
a user understood and consumed that information and combined it
for the real world, they can act on your application to make it
do things. And just like consuming information, this
varies dramatically from user to user and from circumstance to
circumstance. And now these actions can be
something like a tap, a swipe, a scroll.
It can be speaking into a device, some users drive the
whole device with a single button.
And now once you combine these two modes of interaction, we see
this cycle of action and information, right?
And we can see if any part of this is su subtly broken for a
user, the application is useless. How to make it
complete for every single user? That seems like a daunting task,
like we mentioned before, the way the users interact with our
devices varies a lot and trying to understand those users is a
complicated task. If you don’t try to do anything through
non-standard, you trust us, and you use APIs, it is a pretty
easy task. I will show you some trivial things that you can do,
that are fundamental, and push your accessibility to be much
better than it otherwise would have been.
Let’s start with the way that we consume information. And I
started this search application, a novel idea. And the way that
I’m indicating this is a search UI is that, by that magnifying
glass on the little line. You will notice something, that’s a
very light shade of gray on a slightly lighter shade of gray.
That is going to be difficult for people who — for a lot of
people to see, because that is a very low contrast ratio. It is
frustrating and downright impossible for others. So we
should darken it up. And just like that, many other
people are able to use our application. The goal is to
make sure that all of the information is visible in terms
of size and contrast. If you want concrete guidelines on
this, you can go to the material website and we can give you
contrast ratios under circumstances and the hard
numbers in terms of size, like the 48 by 48.
That was straightforward, but there are dramatic variations in
how we consume information. For those situations, what we want
you to do is to fill in the blanks for our frameworks. What
we mean is that your framework can infer a lot from the view
hierarchy from the code we have written, but there are some
situations where we need your help. I will show you. Let’s
assume that I’m a TalkBack user and I’m putting a finger on a
screen to hear the description of what is under my finger. I
put my finger on the mag finying icon, but there is no way for
our frameworks to figure out what that means, because there
is no text associated with that. It is essentially an arrangement
of pixels on a screen. You have to fill in the blanks as app developers, you do
it by a label, search. Make your labels concise and to the
point. If it indicates an action, make it a simple action
word. And this is easy, in this situation, set the content
description, make sure it is localized, because accessibility
users do not only exist in America. And now that the user
can understand what is generally happening on screen, let’s make
sure we allow them to act on our device or application
appropriately. So I decided to add a new
feature, clear text button, instead of having a back space,
you can reset and start stip typing again. That’s a tiny
butpen, buttonbutton, if you have a fine motor disability,
that is going to be impossible for them to tap. We will make
it bigger. This works for many more users. And make sure that
your controls are simple and large.
I added another feature, a history feature. You can type
in the queries and see the results of the query again.
And now if you end up swiping on that, any of these items, you
will see a trash icon indicating this can be removed from
history. If you continue swiping, that item will be
removed from history. This is great and all, but it is a
pretty custom-built gesture overloaded on to an item. It is
going to be hard for our frameworks to detect. So you
guys are going to have to fill in the blanks for our frameworks
and for accessibility users. You can do that by adding an
action, or an accessibility action. And all you have to do
here is specify a user-facing label or description of that
action, a simple verb, and the code that should be executed
when the action is performed. You can do that with the
accessibility action API, but we are adding something to the
Android X library which allows you to do it in a single line
call, with a Lambda and a string passed in.
So I have shown you a way of thinking about accessibility
issues and how to address them, but you still need to know how
to find these issues and how to verify that you have actually
fixed them. This is where Casey comes in. Casey?
CASEY BURKHARDT: Thanks, Qasid. I’m Casey Burkhardt, I’m a
software engineer on Google’s accessibility engineering team,
and I lead the development on accessibility testing tools for
Android. So as Qasid pointed out, there are many
accessibility issues that actually fixes our fairly
straightforward from the development side and can improve
the accessibility of your app. The big question, though, is how
it do we go about finding those issues? There are three types of
accessibility testing today I would like to cover. Automated
testing, use of automated tools, manual testing, where you use
Android’s accessibility services itself to understand the user’s
experience, and and and user testing, where you bring in
users with disabilities and get their feedback using your
application. My section of the talk focuses
on automation because, right now, we see that as one big area
where we can make vast improvements across the
ecosystem if we have some developers’ cooperation using
these tools. So automated accessibility testing, until
several years ago, on Android didn’t really exist. Around
2015, we launched a project known as Android’s accessibility
test framework, which is an Android and Java library that
houses a lot of detection logic for the more common
accessibility issues that we can identify within an app’s UI, a
rule-based fashion. This is an open source project, so you can
find it on GitHub. And essentially what it is aiming to
do is to look at the app’s UI at runtime and find the
automateable, mechanical aspects of accessibility that we see
day-to-day that affect users the most. We can find the common
issues that Qasid discuss, so we can find an UI that is missing a
label for a screen reader, we can identify low-contrast text
and images. We can tell you if you have lickable clickable
items within an UI that meet the minimums for touch target
guidelines, and we identify a number of various other
implementation-specific issues, and the core testing library ATF
is growing constantly to find new and more interesting issues.
We have taken this library, integrated it with common
developer end points, tools that you will use commonly throughout
the development life cycle and you can leverage throughout your
project. I want to talk through some of
those integrations today and how you can use them and get started
with them quickly. So first and foremost, we have integrations
with two test frameworks that are commonly used throughout
unit and UI tests on Android apps. The first is Espresso,
and Robolectric. The idea with these integrations of ATF is
they will piggy back on top of your existing tests. You have a
test that loads, runs UI with the application, and inserts a
state. During the phase of your tests, if you used Espresso or
Robolectric, if we identify an accessibility issue that we
believe will affect a user with a disability’s ability to
interact with your application, we will failure the existing
test. If you have strong testing coverage with Robolectric or Espressoo,
enabling this will allow you to get a decent amount of coverage
in accessibility testing for your app.
And each framework offers what is known as an accessibility
validator. And this is an object that you can use to
essentially configure ATF’s behavior inside of your tests.
So you can configure ATF, for example, to not fail your test
and to log something, and we’ve run into an issue.
And you can set up ATF to crawl from the root of your view
hierarchy when you perform a view action, rather than
validating the item that was interacted with for additional
coverage. You can use accessibility validator to set a
white list. If you want to turn on accessibility tests within
your Robolectric or Espresso tests, you can do so. You can
maintain a green presubmit and burn through issues you know
about by creating and registering these white lists
for issues. And how you leverage these in
Espresso and Robolectric, you will call accessibility
checks.enable within your test set-up. This is going to
trigger our global assertion to run whenever you use a view
action within an Espresso test. So in this case, the view action
is run, runs a performant evaluation on the view
interacted with and its sub tree. Accessibility val
validator is returned through enable. So if you need to
customize the enable, you can do so through the object return in
that call. Within Robolectric, it is
slightly different. Instead of calling accessibility
checks.enable, it is annotation, and it will annotate the test
method or class that you would like to enable accessibility
testing within. It allows you using shadow view.clickon for
you to interact with your elements. Avoid the temptation
to use view perform click, do it correctly.
It is available in a different class that mirrors the same API,
you can use for accessibility Util and make data calls there
to configure your behavior. So, in addition to integrations
with these automated test frameworks, we built a separate
stand-alone tool, known as accessibility scanner.
And this is a direct integration of ATF, and accessibility
scanner acts s scanner as as a front-end for the library. It
will evaluate the fore ground for the device.
It installs the accessibility scanner, you turn it on, it will
add a floating button to the device’s screen, you will open
up the application, navigate to the UI you would like to
evaluate, and just tap the button. What you see is
essentially a report that describes the ways in which you
can improve that UI for accessibility.
And again, these will mirror the same types of issues that ATF
and Espresso and Robolectric can identify as well. It is easy to
take these reports from accessibility scanner and share
them with your team, you can export to email or drive. It
does not require technical skills, you don’t need a debug
version of your application, or a user debug device, you don’t
need to — you don’t need to do anything special to set it up.
It works on any app or any Android device running
Marshmallow or later. And you don’t have to have a lot of
experience related to accessibility. Each issue that
accessibility scanner can identify comes with extensive documentation that gives you
background, and how to think about the issue during the
design, development, and test phases of your project.
And so please do download accessibility scanner, it is
something that I highly recommend we use when we build
UI. G.co/accessibilityscanner will take you to the Play Store
page. And one last integration I would
like to cover today, this is a new one. We launched it a few
months ago. An integration of the accessibility testing
framework and the Play Store developer console’s pre-launch
report. For those of you who have not used pre-launch report
yet, it is a great tool to get a sanity check during the launch
or release process for an APK to the Play Store on an open or
closed channel. The way it works, you upload an APK,
pre-launch report takes that APK, instrument it, and push it
to a number of different physical devices in a lab.
And it will crawl your app, essentially on these different
devices and generate reports that include findings about
performance, security, and now accessibility as well.
And so ATF is running along side pre-launch report as it is
crawling your application and generating reports at each stage
in the crawl, and it is taking all of the results and
deduplicating them. So if you would like to check this out, it
is available now in Play Store developer console under release
management, you should be able to see accessibility results for
any APK that you have uploaded to the store since fairly early
in July. So please do cleck that out. Here is what it looks
like, to give you an idea. The main entry point for an APK, it
will show you the categories of issues we have identified. It
will show you the clusters of issues, you can click on any one
of those and it will show you detame tails about the problem.
So in this case, we are pointing out an issue related to touch
target size. In the column on the left, you see many examples
of the same de-duplicated issue across different crawls of the
application that prelaunch report has performed. You have
access to the same additional documentation here as well, too.
So if you are not familiar with a particular issue, the learn
more link will give you the details you need to resolve it,
regardless of the stage your project is currently in.
I want to wrap up by talking about an accessibility testing
strategy. We talked about automation, but we did not go
into manual testing and user testing. And these are equally
important. Automation is great because it
helps you find issues very quickly, early in the
development cycle, especially if you have good test coverage with
our automated tools. So think about automation as a way to
catch very common issues quickly, but not as a way to
guarantee that your app or your UI is fully accessible.
To really understand your user’s experience, to get that — to
get that awaterness of how your UI is performing within an
accessibility service, we really highly recommend you go and
actually turn on TalkBack, turn on switch Access, try them out,
learn how to use them, and gain a true understanding of your
user’s experience. The way I like to describe it is
automation is capable of finding a missing label for a screen
reader. But we can’t really tell you if your labels make
sense. So really only by understanding
and putting yourself in the user’s shoes and understanding
their experience, we are asking users directly about their
experience. Only then can you truly understand how accessible
your UI is for users with various different disabilities.
And we have found at Google, both looking at our first party
and third-party applications, the most successful, the most
highly accessible apps we see day-to-day are the apps that
combine multiple accessibility testing strategies, like
presubmit, continuous integration, and a process for
manual accessibility testing and bringing users in and
understanding the perspective of an accessibility application.
These are things to consider. With that, I will hand it back
to Qasid that will talk about the newer APIs for expressing app semantics.
SPEAKER: I’m back, say you have adopted APIs that I talked about
earlier and the testing that Qasid suggested. And you have a
pretty good foundation of accessibility in your
application, and the more you are testing, the more you
realize that there are holes in your experience, that is
breaking the cycle of interaction that I mentioned
earlier. We are adding API and new things to make it so those
holes get plugged. So the first thing is clickable
spans, the clickable bits of text. Before API 26, non-url
spans were fundamentally inaccessible. And developers
had to write a bunch of hackie work arounds to make these
things work. In the latest alpha of the AndroidX library,
we made it all the way back to API 19. You can look out for
that, too. And there are users that make
apps behave like — they have their own life cycle and so
forth. They are accessibility panes. You need to develop your
frameworks that present these differently to the user. And the
way you do that is by passing a string to the
accessibility pane title on the view. Make sure it is concise
and localized. This is available on API 28, and we
added this API in the latest AndroidX alpha that will work
all the way back to API 19. And finally, there are headings.
These are used by TalkBack users to navigate through sections
quickly and easily. And the way you specify that is
exactly what you probably expect, pass in a boolean to set
an accessibility heading on a view. This is also available in
28, and we added this to the latest alpha of the AndroidX
library that will work all the way back to ’19.
Now it is back to Phil.
SPEAKER: Circlng back to the title of this, making
accessibility easy. We really want this to be easy. The only
way that this — that user’s didn’t disabilities are
going to be able to access the ecosystem.
Sometimes you see somebody that wants to go the extra mile and
dig into the app and all the issues around accessibility,
that is great but not every developer can do that. We need
to make it as easy as possible so everyone can build it into
their workflow in a natural way. So certainly, to get the basics,
we want it to be straightforward.
So if you have reasonable contrast, to make the
information visible to everyone, you have simple controls, you
are using labels. We want that to kind of get you almost all
the way, and some of the other APIs, like Qasid was describing,
should be able to handle the specialized situations. If you
have a full screen fragment transition, you can use the pane
title to make sure that that gets handled the same way a
window transition would. So we want it to be easy. That
means, if it is hard, we have messed up and we should fix
that. And we found some developers
that really, well, the framework seems to be coming up short, I
will engineer a workaround to get around the problems with the
framework. Honestly, please don’t do that.
Let us fix it, because we can fix it at scale, and it needs to
be inside Android. You find it in AndroidX, you know, if you
wanted to fix it, by all means, upload it to AndroidX and we
would be happy to accept fixes. We want it fixed centrally so we
can get a consistent experience throughout the whole COREMS. ecosystem.
If you are engineering a custom solution, if an engineer at a
different company is going to do this work, and the answer is no,
then there is probably something wrong.
So please reach out if we are messing this up. You can file
bugs on AOSP, you can ask questions on Stack Overflow.
But we much prefer to, we probably prefer to get the
feedback that something is difficult so we can get an
elegant solution that everyone can use. Some of the things
that Qasid just presented before he did that, the effort required
to do some of these things really require, like, learning a
new API surface. We wanted to condense everything we could to
one line. So we are trying to present solutions that really
are — if you have this thing, here is one line of code, all
you need. If you get to something that seems like it
should be one line of code and it is not, let us know.
And another place you can go for other resources is to G.co/Androidaccessibility,
there’s a link for accessibility testing, how to get to
accessibility scanner, and the test framework project that
Qasid described. That is available on open source on
GitHub if you are interested in that.
So, I really appreciate your time, I would be very happy —
if you have feedback for us, and you think things should be
easier than they are, we will be having office hours for a while
this afternoon. We would love to talk to you. Thanks a lot
for coming and for your efforts and hopefully making a
consistent ecosystem of accessible apps. Thanks.
[ Applause ]. SPEAKER: Everyone, the next
session will begin in 10 minutes.
Coming up next: Bundling an App in an Instant by Wojtek
Kalicinski, Ben Weiss. 12C3W4R50I6R7B8G9SDS Wojtek SPEAKER: Hello, everyone.
So today at the keynote, you heard that we are unifying the
developerdeveloper experience for instant apps and Android app
bundles. My colleague, Ben, and I are
going to talk about how that works for the developer
perspective. So instant apps, it is a
technology that we introduced a little over two years ago at
Google I/O. It lets you give your users a native Android app
experience without them having to explicitly go and install the
app. And now how that works is you
split up your app, into smaller pieces, and the user can reach
that via a link. And now to QUET your apps small enough and
to launch it instantly, instant apps for the first time used a
technology in Lollipop, called split APKs. And they are able
to use the smallest and most optimized version of the app to
the user’s device. In order to do that, the build system, the
Gradle Android build system that you have that you build your
apps with, built all of those split APKs locally, bundled them
in a zip file, and you upload that to the Play Store they can
choose from the set of APKs and deliver them to the devices.
To do that, the developer had to do some significant
refactoring in your African apps. The project structure of
the instant app, as we looked to one year ago, probably looked
something like this. First of all, you have to take all of
your base application code and move it from the application
module into a base feature. And then you had to split your
app into feature month featuree modules containing the feature
of your activities. And then you have almost two dummy
modules, application and instant ach app. So the APK, and the
instant app zip bundle that you upload to a separate track in
the Play Store. This was not ideal. As I said, it required
significant work. Your project no longer looked simple.
And at the same time this year, we introduced a new publishing format called the
Android App Bundle. This contains metadata about the
targeting of the resource resources, native libraries, and
so on, and it contains some of the module information for a
module called dynamic feature. I called it a publishing
feature, we use it to upload a bundle, telling the Play Store
everything about your app to play. And together with Google
play dynamic delivery, we are able to serve an optimized set
of APKs to user devices. In order to do that, there’s a big
difference. Because it happens on the server side on the Play
Store, we need to be able to sign the app. If you use an
Android App Bundle, you need to enable sending by Google
play. If you allow us to store the key
for you, it is more secure. There is another benefit,
because we can transform the APKs and make them more
optimized, as we develop more apt miizations on the Play Store
side, what we bring to the users is more optimized from
compressed libraries. It makes sense to move instant apps to
this new model. Why build all the APKs locally and not be able
to optimize them further on the Play Store? What if we could use
the new App Bundle for the mat to deliver instant app
experience to our users? So let me tell you how to go
back to that simpler, better project structure for your instant apps. If you have — we need to go
back to the simple project you use as your build your APK.
So we no longer need the instant app plugin, everything we need
is baked into the application plugin that can now build
bundles. We don’t need the base feature anymore.
Instead, we can move our code back to the application, where
we will be using that to build our unified bundle artifact.
And so, again, with feature modules, we replace them with
dynamic features that work in the App Bundle world.
So ultimately, we want something simple. You can have your
application module with any additional library modules that
you need. Optionally, we have dynamic features that can be
downloaded on demand, adding functionality alt run time. We
have single piece of metadata that tells the Play Store that
this is instant bundle app enables. That would be great if
you can upload it to the Play Store and all have it downloaded
on the install and instant track which, what we is what we are
aiming for. We are testing it, but you are
not able to upload it just yet. If you want to try it right now,
create two project variants, it is in the simple project still.
In one of the variants, enable the metadata, enable the instant app for your bundle and use the
other variant to build it without that entry, or man
manifest. Still one app, one codebase, and you may have to do
that in order to upload to the Play Store.
There is another white list n , if you want to use dynamic
features in order to let your users download them on demand as
they run the app, this is on a white list for developers who
want to test that. You can apply online, however, you are
currently not able to publish your app to the production track
if you have more than one module.
Okay, so how to try it yourself right now. First thing you need
to do is use the new Android Studio 3.3 that is currently on
the channel. If you are creating a project from scratch,
you can select this check box. We will collect the modules with
the necessary metadata in there already. That’s what it looks
like, thin in the base manifest, you enable it, you are
good to go. If your app is compliant with the other instant
app restrictions, such as file size, you will be able to publish an instantly enabled
bundle. If you have a project that you use to enable an App
Bundle, you can use the wizard to allow a bundle. This will
instant enable your base module if you haven’t done so.
And next, we will build an App Bundle through Gradle, through
the bundle release command instead of assembly release, or
through the wizard and the UI. By the way if you are using our
Android dev summit app at this conference, it has been built
exactly as an instant enable App Bundle. We publish that to our
channels on the Play Store, what you are using right now is
exactly what I’m talking about. And it has been great. It is
has greatly simplified what we need to do in order to have that
working. Let me invite on stage Ben who
will tell you about best practices for modeler
modularizing this copy of your app. Round of applause, please.
SPEAKER: Thank you very much. I will talk a little bit about
discoverability of your instant apps. One of them you saw, the
try now functionality. I will talk about this. Try now is
basically a second bud button on the Play Store that allows
users to download and run the app without having to
permanently install it on the device. That’s a great
experience that we can easily see how it works, you can go to
Play Store now and check it out through the Android dev summit
app, and you can get to it directly from the dev landing
page. If you don’t have an url associated with your app, that
works as well. You don’t have the restrictions that you have
to map to your urls anymore. How do you do that? That is
basically it. I think that everybody has this somewhere in
their application, the main launcher. You don’t have to do
anything else other than add the instant metadata that you were
shown earlier, there is nothing else you have to do in order to
be eligible for the try now experience. What is your app,
you want to have your app available with an url mapping?
That allows you basically to access your app through any url
that you have associated with your app. The first thing you
have to do, you have to verify if you own the domain. In order
to do that, you upload an asset links JSON file.
There are resources where you can identify what you uploaded
is correct and the mapping you have is correct as well, you can
share the link with anyone and they can open the app straight
away. I will show you how that works where we started with the
main launcher. You have to set a second filter
with it set to true. That tells the Play Store it should check
for the asset links JSON file on the url provided below. Then
you add the action view, the browseable default, this is what
I want to use as the default to view this url. You have the scenes for https, or http, and
multiple path prefixes for multiple activities. If you
want to use a default activity, whether it come from try now or
the home screen, is the metadata here, the tag for the filter.
This is the default url, this is where I want users to come in
initially. Like I said earlier, if you don’t have an url in the
first place, you don’t have to do this. If you have to have an
url mapping, then this is the way to go.
And it is not a lot of work to do. It gives you the — it uses
the experience that you can share any link that leads to
your app and any user can open the app straightaway without
having to install it permanently. And I think for a
conference, it is a good use case to have an app that you use
once, you don’t have to fully install install it. You have a
couple features, like notifications, you have to
install the app. But it is fair enough to have the experience
that you can have straight away without the first steps that are
necessary. And also there is another thing
that we use for app bundles in order to download code
dynamically. So going back to the previous
section is basically, you can do that with the zip and feature
instant apps. What we are going on forward now, you have to
ship, as the App Bundle, and you have to use dynamic feature
modules in order to use the play core library. This allows you
to download features dynamically on demand, not during the instillation, andapp. And it does all the
heavy lifting. If you say to the library, download this, it
connects to the Play Store, downloads it, puts it in the
right place. For instant apps, it puts it into the shared catch
there, and then it installs it on the device permanently. So
how does it work? So you add it as a dependency,
available from Google.com, you can use it in your project. You
create a splitinstallmanagerfactory,
create a request where you can install one or multiple modules
at the same time. Those module names have to match the module
name that you set for the dynamic feature module directly
in the manifesto module. You build it, and you tell the
manager to start the instillation.
And that’s all the code you need to get started with it. There’s
a couple things to go around it, I will go into it in a second.
If you don’t want to do instillation straight away, you
can do deferred instillation. So you have the app, the user is
in a flow where they are buying something, so they have logged
in and then they started the purchase process and you want to
download a payment module, for example. You can do that
deferred, or during the flow with had the user is in that,
you can do the instillations. And so the deferred — it is
not done straight away, the system says I’m cleaning up and
this is where the module is removed. And you can also
cancel the instillation requests where, for any reason, you want
to cancel that, there’s an option to do it.
And there’s a listener that you can set on the manager that is
my preferred way of listening for the updates, the split
install state update listener. That’s quite a word. And
usually what happens, the happy path is you trigger an install,
the app starts with Pending and goes to downloading, downloaded,
installing, installed. That’s the happy path, for an app or
module that is small enough — that required user confirmation.
If you go into that state, you will get the — you will get
some information that you can start the intent with, to show a
dialogue whether they want to confirm or deny whether they
want to install the module at this point. If they con firm
firm they want to install, you continue down the happy path.
The instllation can be canceled in the cancelling state, and for
a couple reasons, it can fail. So that’s the path where you
have to handle all those states. We do have a sample al —
available for that, I will share the urls later in the session so
you can see how it works. I talked about file size.
The limit that triggers, for example, the — that requires
user confirmation coincides with a couple apps for instant apps
in general and for dynamic delivery.
One of the things we do is we don’t take the installed size,
or the downloaded size, as the main factor anymore.
So if your app or device has a file size that is larger than
the limit, that is all right. We can take the download size
into account. You get compression over the wire,
that’s what we take into account for that. And this we show in
the play console as well. You will see the download size is
this, you are right above or below the threshold. And
dynamic feature modules do not fall into the initial download
size as well. What falls into it is basically your base module
and your instant entry module. If you have more than one, that
you can have, it is the base module and the largest instant
entry module. And those, under a white list, have to be less
than 10MB. Dynamic feature modules that you
download later on or other instant entry modules do not
fall into the 10 instant MB in the first place. If your app is
larger than 10MB, you do not have the instant app benefits,
you are not discoverable to users as an instant app. If it
is less than 10 or more than 4MB, your app can be seen and
used as an instant app. So you can access it through try now,
on the Play Store, and also you can is show it in the web
banners and share it viaU urls. If your base module and your
instant entry model is less than 4MB, your app can be discovered
from anywhere, like ads and search results. If you research
for Android dev summit app, you will see that and go directly to
the instant app because it is under the 4MB threshold. While
you are at it, you can continue to modularize. It is a tricky
topic because it entails some work that some people are not
100 percent certain how that is done best. We recently went through the
whole process with a project, it is called Platt, it is on GitHub
and I will talk about how we managed to move away from a
monolithic app to an app that uses bundles. It uses the same
technology underneath for modularizing an instant app as
well. So what we did is we, and most apps will do it, we created
a base module which hosts the domain code and data so it
shares the shared preferences, log in, for example, some of the
repository, some persistent API calls, and things like that. On
top of that are different feature modules. Those have
their own domain code, logic, and the UI which is only
displayed in this module. And that set up can be used for many
apps, if you have a base module that shares information and the
different feature modules. I will share a little bit more in
depth what we did. So we initially had an app, a
module that most people had, a monolith. If we shift to an
APK, that is fine. There is no way to go into the whole
modularization part if we have, in the end, one single
monolithic app, APK, that we ship to our users. And since we
were considering going towards dynamic features and app
bundles, we move everything into a base, with the shared
dependencies, that means everything that we include,
coming from whatever repositories externally as well
as a couple of local, third-party APIs and libraries
that we have forked and worked with.
After we tested this, we worked on features that we extracted
from the app itself. The first thing we started with is an
about screen. Well, an about screen is kind of untangled from
most of the stuff within the app. It is a good starting
point for getting our hands wet with — what does it actually
entail to make the dynamic feature module, how we make it
do all the things. Then we did a search screen, and then we
have two new sources that we extracted into the dynamic
feature modules as well. They all depend on the app, and
everything shares the information through that as
well. You can read up more in-depth on a blog post on the
Android developer’s medium publication, and we also have
information available on instant apps on general, and on App
Bundle on dynamic features, and instant apps without urls. The
instant app scene is outside during office hours to share
information and knowledge. If you have questions, please come
there. And with that, thank you very much. [ Applause ]
Coming up next: Android Slices Best Practices by Arun
Venkatesan, Artur Tsurkan. SPEAKER: Hi, everyone. My name is Artur, I’m a product manager
on Android. SPEAKER: My name is Arun.
SPEAKER: We’re going to tell you about Android Slices, part of
Android pie. So we’re going to start an
introduction to Android Slices, user experiences, best practices
in constructing your Slices, and more details on search indexing
best practices, and finally through the — what we have been
running over the course of the summer, the important developer
gotchas for when you start building slices whether when
they are available. We will start by reintroducing
get SNOOT slices. Before we into it, I wanted to
remind you of some resources. We introduced slices at Google
I/O, you can find documentation at g.co/slices.
And you can look at our I/O session video, Android slices,
building interactive results for Google search and that will give
you information on building slices, building a custom
template and an UI for your slice . Slices are a new way
for you to present remote app content in Android.
Think of Slices as embeddable app snippits that can be
inserted inside another app or part of a system. Slices are
meant to work across multiple possible surfaces, the whole
idea of a slice is the ability to constrain and provide you
with a lot of power in how you express your app. Slices
contain a variety of components, including text and images, and
they are powerful. They are not just static pieces of content,
they can house realtime data and interactive controls, and
TalkBack to your app in the interaction. So all of these
examples you see here are examples of slices that you can
build. I mention that slices can be
embedded across a number of contexts, and we are excited to
be bringing them to search as the first surface to insert
slices. So as they are typing in a search on Android, you can
enhance the predictions offered by Google with lives, personal
content from your apps, constructed through the slices
you create. There are two types of slices you can provide in search predictions. The
first are app name queries, if somebody can search is searching
for your app, you can direct them to a canonical part of your
app. So maybe in YouTube, you want to get the visitors to the
video they were watching. Or maybe you want to get beyond
the name, and the settings app will give them toggles for data
usage. How do we build these slices?
We will start with default or app name slices. It is easy to
build an app name slice. Construct it as you would.
Android’s recent updates include tooling. When you create a
slice, you will create a definition in the manifest, like
this one, and the exception to the slice provider class. That
provides details of how the system can find your slice and
what templates it offers to the system when it does. To make
this slice map to your activity, or to make it map to the app
name, you need to add the slice content URI to the content
activity and specify it in the metadata field. So this tells
the system, this is a slice that I want to point to the main
activity, this is the content from which you can reference
that slice. The implementation details for
general terms are a little bit different.
So first, you actually don’t provide the same linking in an
activity as you would have an app name slice.
You are going to use updates to the Firebase app indexing APIs
to expose the content URI for a specific set of key words.
Using the Firebase APIs, you would construct an indexable.
That would have a public url, it will also have the name for that
indexable content, some very targeted key words for users to
find that content, a description, and then finally
with the update to the Firebase app indexing APIs, you can add
the content URI or slice URI for this indexable. When the user
is searching for the key words you specified, search on Android
will replace the prediction with the slice predicted by the
content URI in this indexable. Finally, in order for
indexables to be transilated transilatedilated from the
public urls to the content, you need to over write the URI
method into the slice provider. This allows you to talk between
the two formats in order for the URIs to be visible as a search
prediction. Overriing this method allows us to provide you
as a developer with flexibility over what schemas are important
to you, without attaching them one to one.
Now we know how to build a slice and also how to expose it
to search on Android. Let’s go into a little bit more detail on
what makes a good slice, and the user experience best practices
to keep in mind. So the first is try to focus
your slice on one task or a set of sight tightly related tasks.
Avoid making your slice do too many things, and that the
content in the slice is coherent coherent. So those slices are
embeddable as a search prediction for now, we would
like to think that the slices that you build should be
reusable in many other parts of the operating system and you
should consider when building your slice for those
possibilities. So it focuses on consuming and previewing one
video, the slice on the right goes to other functionality,
like channel selection, and stresses the definition and use
of a slice, which we discourage you doing.
Try to keep interaction in the slice lightweight, highlight the
most important features, excuse me, and make sure that the
actions you are presenting to the user are using clear and
familiar iconography so they make sure that they understand
what they represent. Avoid making it do too many things.
So the slice on the left focuses on users listening to the
content and play list, and offers them the ability to like
certain content. The slice on the right leans into things you
can do with the play list items, functionality that is probably
best within your app. When sharing your slices to
different platforms, make sure you are surfacing recognizable
features and content so that users know that they can query
for them. When they query for them and see it as a prediction,
they can understand how it might have appeared for that
particular query. And Arun will go into those
principles, but try to keep that the case to avoid promotional or
advertiing content in the slice. And finally, have the slice
accelerate critical user journeys and make sure that the
slice accomplishes as much of the user journey in line as
possible without going into the app. By providing the
information and actions that the user would need to accomplish
that action. So on the left, the user has all of the stuff
that they need to know to understand what the slice is
for, what kind of information it is representing, what kind of
actions I can do with that information, changing the song,
adjusting the transfer or brightness, and they don’t need
to click into the app to do that. The slices on the right
are missing some critical pieces of information or critical
component as part of that user journey and adds an
additional layer of friction for users in completing the task
they want to complete. There is more that Arun will go
into. SPEAKER: Thanks. So here are
the main pockets when you think about use cases for building
slices. They should be familiar, such as requesting a
ride on a ridesharing app. They should be targeted. And finally, recall
and reengage with content that the user has seen, rather than
discovery use cases. Next we will see guidelines
around the content you can surface in slices and the data
that needs to be indexed.
Slices should be targeted and personalized.
Like the video streaming app that shows slices, when a movie
a user is searching for is available in the app. The app
can index movies, like the users previously, or it is curated
based on the in-app behavior. Do not create one for all the
users in the database. Slices should give
information. A ridesharing app gives users
the ability to search for rides. Create index cases based on past
history, or popular places near the user, such as concert venues.
. Slices should give users timely
information. Let’s say that a smartphone —
they are likely in their home. It is not recommended to create
an indexed slices for controlling lights at any time
or in any place. Here are some more examples of
the type of app content to index and display in the slice.
A food ordering app can search relevant realtime data, such as
food price, when the user fetches the slice.
Similarly, a news app slice can index and display information to
the readers. Travel and local can allow users
to look at their content, such as bookings and upcoming flight
reservations. Let’s now see how to keep your
slices fresh. When a slice is indexed, the
indexable object includes the matadata and the cached slice.
And in order to make sure it is accurate and not still, you
should set a time to live. This is used by the Google search app
to make sure the cache is not displayed. In this example
here, the time is set to 1R expiration. And if the slice
has content that is not time sensitive, use it to time to
infinity. In order to present to the user, reindex the slices
in the background when content changes, and only when content changes.
Earlier, arrtur showed us how to index. What are the best
practices for key words? Limit key words to 10 per slice.
Account for likely permutations.
This is probably the most important, avoid key word
stuffing, use the minimum number needed per slice. So the app
slice will be in the search rankings, if you use too many
key words that the users are tapping on.
How do you determine if the —
the most important signal is the of times that the user uses the
app on the device. It is also important that the
user has viewed the content previously and interacted with
it. And finally, in order for us to
know that the user interacted with the content, log it to the
indexing API. We conclude the session today by
sharing the lessons learned from the early access program.
Content URI can be confusing. Content URIs are mentioned with
a slice and start with content://, and deep uris start
with http or https. Content URIs use the package
name, or the reverse of the package name shown in the
example. When you see a content URI, think of a slice. Key
words must be included in the slice title or subtitle.
This is done to ensure that the relevant content is displayed to
the user when they search for something.
How do you handle location? So slices do not provide
location to apps, and therefore use the last cached location
when displaying the slice. Reindex the key words based on
the last location. And note that indexables are not instantly updated and it leads
to bad ratios. So keep in place when handling location changes
for the app, and apply those to slices as well.
It is recommended to keep the slice initialization short. The
on create slice provider method is called for all registered
slice providers on the application’s main thread at
lunchtime, and therefore do not perform lengthy operations for
the application start up will be delayed.
And if you have multiple indexables, in the case of apps
with multiple slices, put in all — pass in all the indexables
together as we showed in the example. And make sure to test
the indexable. If one is invalid, that update called it
failed. So here is a small code snippet that shows it, how to
pass multiple indexables to the Firebase app indexing API.
So now that you have built your slice, you are
viewing the API. That’s all we have for the talk
for today. We want to give a shout out for the developer, to
the early access program. Thank you and have a fun rest of the session. SPEAKER: We are now on break,
this is the worst fab I have ever seen, I recommend people
put it on lower right and not have it be that color, there is
something disturbing about that one. It is snack time t , it
says on the agenda. There is coffee as well as tea, and there
is also coffee, there is snacks, and there is coffee, and I have
it on good authority that there is also coffee downstairs.
There is coffee, excellent question.
Thank you for asking. Let’s see, we are back here at 4:00.
Building a great TV app. There’s a talk on building
Gradle best practices. See you back here at 4:00, thanks. # #.
SPEAKER: Hey, everyone. Today, we’re going to talk about
building a great Android TV app. So before we dig into the
details, we will talk about the ecosystem. We continue to see
two times year over year growth. We are investing more in smart
TVs, desktop boxes, the ecosystem has been pretty
strong. But you are all developers, let’s get into how
you can make a good TV app. So before we talk about what the
innards of the app are, we will talk about what the TV is and
why it is so important. We have living rooms and other rooms
dedicated and focused around a TV. It is a pretty key point
for users, it is the focus of an entire room. Just think about
that for a second. So your app matters. The content matters.
So if we try to think about what is the foundation for an app,
the biggest piece is your content.
That is your value prop to your users. If you add on to that,
usant, how do you make it easier for users to add. You have
great content, how can they discover more of your content
inside of your app. If you want the cherry on top, think about
the experience. How can you layer in all of these extra
things to build a sweet experience for users, no matter
where they are in your app? We will dive into each of these
concepts and I will call ’em out later on. But the key take away
is they come from your content, but they stay for your app.
So what I would like to talk about is how to build a great TV
app. There are three things to think they can see other content in
your app easily, and distributing, making your
content easy to find should be as easy as making your app easy
to find.
Let’s talk about the player. Player can make or break an app.
We will talk about this review, feel free to read. So the key take away for me is
that it constantly stalls, this app is completely frustrating.
They ended up with just a one-star review, just because
they are a player. And reviews matter, there are whole other
talks about Google play and how to improve your reviews. But
the player was the key point here, it is the why their app
was not as good astle could it could be. So it is very clear
to users that the play back is important. They don’t want to
have stutters and stales, they want to be able to watch the
content. And even in that review, they talked about XHURNS
commercials and ads. They are okay with it, they don’t it
like that they stalled. Soshowing things that may be
annoying, such as commercials, as long as they play fine, users
are okay with it. So the player, we have many options to
build a good player. Media Player is a good tool, comes out
of the box in the framework, you give it a data source, it chugs
long in play, you can build a great experience with media
player. If you have more advanced things you want to do,
Exoplayer is a great tool. We work hard to make it customable,
there’s a lot of extensions. If you are using lean back, there’s
an extension that hooks into the lean back controller. If you
are doing ads, there’s a bunch of ad stitching support. Lets
talk about ads, ads are important. You are going to
make money from showing ads. And ads are just as important as
the content shown and displayed to the user. Focus on ads and
make sure that adstitching works, whether you do it server
or client-side, these are considerations you should make
for your app. So there’s many options for
players, media player, ExoPlayer, custom player. And
having a player is a good start. But there are things that you
can layer in, that top part of the pyramid, the experience,
there are things that you can to to build an experience around
the player to make it even better. So we talked about this
at I/O, play back controls. Everyone’s phone should be
ready, here we go. Okay, Google, skip 5 minutes. Okay,
Google, pause. Okay, Google, play. Thesep
types of transport controls can be commands through the
assistant. Adding this extra little
feature, this little nice nugget of delight, helps build that
experience experience for your app.
This works with Media Session, if you have Media Session call
back, you get all of these features for free. Since I
talked about this at I/O and there are other talks, I will
jam through this fast. Pay attention, here we go.
Boom, beautiful. Six wonderful methods: Pause,
play, stop, seek, next, and previous. But in reality,
that’s a lot. That’s a lot to think about, all of these
different casesism if. If you use ExoPlayer, it can be done
for you. There’s an extension, all you do is connect the player
to the media session and it works out of the box. Making a
media session is pretty simple, there is documentation and talks
ants about Media Session. I will not go into it, set it to
be active, set the controller, set anything else you need to
set. Set the current state, are you currently playing, what
position are you in, set up the media session to be what you
need it to be, and once you have a media session and you have an
ExoPlayer instance, connect them. There’s the extension
library for ExoPlayer, add in the media session as the parameter, and set the ExoPlayer
instance. The media session connecter helps understand how
to set up the call back, the edge cases around playing and
seeking, you don’t want to go back past the end of the video,
rewind before the video starts. It handles the edge cases for
you. In this sample, we are saying set player, player, and
then null. And you can set a custom play
back refair. There are other customizations you can do as
well, so if you are music app and you have a custom playlist,
and you want to set a different order for how the songs go
through the queue, you can set up a custom queuing mechanism on
the extension. That’s it. Three wonderful lines of code, and the instance is
taken care of for you. All the default behavior you would
expect, done. So having a great player is
great, that is one example of how to layer thin experience to
make the player even better. We’re going to skip ahead to
discovering content. So the whole point of
discovering is you want users to stayp in your app, and you want
them to discover and watch content faster.
So let’s look at this review, I love the first sentence, they
love love love — so many loves in this ach. So the key takeaway here is that
it was a five-star review, they loved that all of the content
was there. It is easy to find, they can do whatever they need
to do inside of that app and watch what they want to watch.
Funny story, it is the same app that got the one-star review.
So even though they had a bad player, they worked on
discoverability and they are able to have good review in the
flay Play Store. So how can we make content
discoverable? Everything happens in threes, that’s a rule of
comedy, and a really good rule in life. And discoverability
also happened happens in threes. We can work in in-app
browsing, search with the assistant, and the home screen.
We can start with in-app browsing, there’s a beautiful
library, Lean Back. If you have done TV development, you are
very familiar with it. It is a templated UI system where you
can plugin data and it works on building the UI for you, so you
don’t have to worry about the focus handling and the user
input. You can just, this is the content we have, and it will
show it for you. It is not just how to browse content, though,
leanback also works and showss details. So there’s a bunch of
information about content, you have duration, content rating,
the rotten tomatoes score, the album, artist, I can keep going
on and on for the rest of the 30 minutes of this talk. But I
think you get the point, there’s tons of information.
You can show it using lean back and in multiple places on the
home screen, in search. And by showing this information sooner,
it lets users make these microdecisions faster and they
don’t have to go in and out, in and out, to figure out hot what
they want to watch. Make your user’s lives easier by showing
this sooner. Let’s look at another example, search. We
talked about this at I/O, there’s tons of documentation on
this. I want to breeze through some of these things quickly.
Search is all supplied with the content. Content providers are
simple, they return a cursor, you can do whatever you want in
the background with the content provider.
If this did a network call, maybe you have a bunch of pojos.
This is a database call, you have a cursor. That’s fine, the
trick for the search provides provider is it needs to return
results that match the search manager’s criteria. A search
manager is way of saying this cursor has a bunch of columns
with these names, and then the assistant is able to pull in
from that cursor and say, here’s the title, here’s the duration,
and is able to figure out what content is where.
Super simple to do to do with the matrix cursor, we will dive
into it closer. You need to take each of the results, add
them into a row as a matrix cursor, and then return the
matrix cursor. The matrix cursor is really just like a
mock cursor, it is a 2D array, essentially, under the covers.
So if you don’t have to go about, how it do I store all of
these in a database, you can mock it out at the very end of
your search. So mapping, this is where the
hard work happens. You have a matrix cursor, it
takes in a query projection. This query projection is going
to have all of the columns defined that match the search
manager. So here we have suggest column,
text one, is the title of the content.
An action, the data ID, the ID is what is unique to your
content inside the app.
And if you take the context into this row, you supply an array, the name, and
it corresponds to the order in which the query projection was.
So the ID, the title, the action, etc. All of the fields
you have, you can return it back.
So search manager, and with the search and assistant, you can
make the return result mump much faster.
And so we will cover the new stuff that is happening.
The app will have the channel, the play next row, and for the
video apps, you will have previews. We have seen up to 2X
increase in engagement , you can see a trailer for a
movie, or a recap, but they take a little bit more work because
it requires the content team to make the content for you. We
will not talk about play next, or video.
So inserting it into the content provider. So set the preview,
the link, when they open the channel, they put it into the
app and set the internal provider ID. This is what the
app keeps track of and knows about. And then you just get
the content resolver, you call the insert, give the content
values, and you are good to go.
So you do stuff, the channel ID, you keep track of it for sink
synchronization. So it has the deep link, the
internal provider ID, and the logo, those are the key pieces
of the channel. So what just happened? We
created a channel, we inserted it, and then we stored the logo.
So we did two things with the home screen, insert the channel,
store the logo. So, as of AndroidX 1.00, we have
a new API. This API looks very similar, small differences. We
have a preview channel helper class. It takes in a context,
and then it does a bunch of look-ups to get the content
resolver for you, so you don’t have to do context, content
resolver.insert, it does the work for you. It makes a
channel, you have the builder, you set the name, the
description, the app link, the intent provider url, you think
you should set the type. But this class knows it is a preview
channel. It knows the preview, and you don’t have to set the
type. Instead, you can set the logo.
Now, all of this is contained in one united, you can call the
helper.publish channel, and it gives you all of the work for
you. And you can get the channel ID
back. So what it does under the covers, it inserts the channel
into the provider, and it goes to add a logo.
And if the channel isn’t able to be inserted, maybe you have bad
data and you are hitting an error or something, it will
return an error back to you. If it is able to insert the
channel, it tries to store the logo on that channel. If the
loFWO it go cannot be persisted, it wraps it all up, unwinds the
channel, so you have half one on the home screen. It treats
everything as an atomic unit. Pretty convenient. It does
everything CRUD does. So we talked about publishing the
channel, you can read all of the chanles les and get individual
channel, you can update a channel and you can delete them.
And all of this also happens for preview programs, and there is
support for the play next proin this class.
There are two options to do it, which one is better? You could
say I want to use content providers, I want to fine tune
the performance, I can do batch inserts, bulk operations, I can
go lower-level control. I don’t need an entire program with all
of that metadata, maybe I want the title and the duration, and
now I can slow down that query projection, and have faster
results. And it is based out of the
framework, you don’t have to do all of this extra work to access
it. You get it out of the box from the framework. If you want
to use Android X, you get more convenience, you don’t have to
worry about all of the nuances of a content provider, it is
a-liner for all intents and purposes, and you get the
benefits of having the AndroidX in your app.
Discovering content is great, three ways to go about it. In
the app, searching the assistant, and on the home
screen with chan LSS. Les. How do you make your app
discoverable? The third thing. The app store on TV is a bit different, it makes sure
that only apps designed for TV are shown. When the user opens
up the app store, they are looking at apps that can be
played on or installed on TV. Try to make your app stick out
can be hard, but there are simple things that you can do to
have your app appear on the Play Store. The first is to declare
features, and even if you don’t use it, there’s a giant
asterisk. Don’t start declarng bluetooth or location just for
fun. There are two features that really matter.
The first is touch screen, you want to declare it as false. It
is not a touch screen, this is not a phone, this isn’t a TV
from way back in the day, these are smart TVs.
You don’t need touch screen support. The second thing is to
declare lean back as true. This tells the Play Store is ready to
be deployed on a TV.
If you have all of the code in a single code base and making a
single APK that deploys on mobile and TV, set the lean back
to false. This tells the Play Store that the APK is compatible
on mobile and TV. The second thing you should do is try to be
visible in the launcher. If you are a headless app, a screen
saver or a keyboard, go away for two minutes. And I will see it then.
So you need to supply a banner to see it in the application or
activity. The launcher will go in through the manifest, find
the resource, this is what it uses to show the icon on the
launcher. And once the user selects the
icon, it needs to launch something. So the launcher
fires an intent, and you need to have an activity that accepts this intent.
It is called the lean back launcher intent, cleverly named.
And from that it will trigger the lean back experience. There
are three things you need to have. One, declare the two
features so the app is found on the Play Store. Two, how the
have the banner, and three, have the lean back intent so the app
launches when the user wants to enter your app.
And that’s it. You are ready to go in the Play Store. This talk
is done. All right.
But, in a sense, that is kind of the minimum viable product. You
are able to have a strong player, you are able to have
easy-to-find content, and you are able to distribute on the
Play Store. That is just a good app.
How do you make it great? To start with this, you should
look at your users.
Imagine the spectrum, they start from one side of the spectrum.
I bought a TV, I want to be cool, everybody is doing it, sit
s in my closet but I have one. The next part of the spectrum, I
have one, I watch a show every week. You go further down, I
love how to get away with murder, field of disease
daisies is awesome, I should watch suicide squad, theis in
that. Or for sports, here is a fantasy team, the jersey and the
player I like and I keep going into it. That side, the left,
is called the lean back user. They are sitting back, watching
TV. That’s all they want to do.
This is the lean-in user, they are sitting on the edge of the
seat, this is awesome, who are the people in the show and going
deeper into the content. Everything I talked about until
now, having a good player, making the app usable, this is
for the lean-back, the right side of the screen. If you think about it, how can you tap
into that lean-back user? Here you have a beautiful living
room, a very beautiful living room. I wish it was mine, but
it is not. If you look closer, you see a camera, a microphone,
a tablet phone, and then, as you start to think about it, the TV
is the center piece of the living room. There are so many devices around. You don’t have
to just do stuff in TV, you can tap everything around the liveic
ing room. I love the Android TV, it is the focal point around
everything that is happening. Again, we do it in threes,
threes are great. In concept, if you want to tap into the
other surfaces, what should we do? The first is controlling
media, the play back controls we talked about earlier is a great
step. It is going to go a little bit farther advanced, you
are building an experience around your app. And another
option is to have notefication notifications, the big gomis
game is going to start. Do you want to watch in your TV? And
the next is going deeper into the content, the cast and crew,
behind the scenes of this production, are there extra
sponsored content I want to know more about. And the third
pillar is about reducing friction, how do Iinstall your
app, it is installed, how do I sign into your ach.
I want to make a payment, how do I authenticate it in a secure
way inside the TV. Everybody who
has the TV has done the third step, the frictionless
interaction. The Android TV set up does it for you, during the
flow, it says, do you want to set up on the phone? They give
the UX indicator, you get the notification, you say, this is
me, this is my account, and the TV takes over from that
information and it was really frictionless.
And how do they do that? It is something that you can do today,
it is nearby. We try to use that on
TV, what you can do.
You do the work on the phone, and not on the TV. We will set
up a peer-to-peer wireless connection that is encrypted,
you don’t have to worry about a lot of things, you have an
intimate connection between the phone and the TV. We will dive
in a little bit deeper, let’s get started with this, we will
start on the TV side. So I’m on the Android TV, so I’m biassed.
So TV will start advertising, you set up the
nearby.get-connectionsclient. That is a helper class from the
nearby API that has all of these things to get you started. You
call the start advertising, you give it a name, a service ID, a
package name is perfectly fine. You are going to give it a
connection, a life cycle call callback, and set a strategy. A
cluster is a really good strategy. If you notice,
there’s a P to P, point to point, strategy. And it might
be one TV, one point, point to point, that is great. If you
try to do multi-device set-up, I have a TV in my living room, in
my bedroom, bathroom, all of a sudden that point to point
breaks down. So to make it a more robust app, think about
using cluster. You also set a success and failure listeners.
These listeners are not saying, oh, I have been found, I have
been advertising on non found, the users will say you can start
sad advertising, great for debugging and adding extra
information inside the app. The big elephant in the room is the
connection Lifecycle Callback, this talks about how the devices
talk to each other. What is going to be said is later, how
they are saying it now is handled in the connection life
cycle callback. And a simple three methods: On
initialized, results, and disconnected. And they are
pretty straightforward, but let’s dive in a little bit more.
So when the connection is initialized, that means the
phone requested a connection, you are going to prompt for
security and do a couple things. Eventually, you will see nearby.get connections client,
and you will accept it. Based on that, there’s a result, was
it okay, continue on, was it rejected, maybe it will ask for
another re-try. And based on that result, you should handle
appropriately. And the last one on disconnected
is pretty simple. So clean up any metadata that
you may have started collecting. The big line here is the
connections client, accept connections.
And here you pass in a payload callback. This payload doll
callback is what the devices communicate. So you have a
contract on your phone and on your TV for what they are going
to say to each other. Hey, phone, we want to do this. Hey,
TV, we’re going to do this. And this is all handled inside the
payload callback. So here are a couple tips.
What you are going to communicate is very specific to
your app, but here are some tips. The payload received and
payload transfer update are the only two methods you get.
They are pretty succinct. Payload receive, if you want to
send an acknowledgement back, hey, thanks for telling us this,
phone. We will send back an acknowledge.
acknowledge.Ment, so you know the message that has been
received. You call send to payload. You give it the end
point ID and some body, in this case, it says ack, or
acknowledge. And if you want to disconnect,
hey, I received this payload, I want to disconnect the connection and
close the session, you should do it in the transfer update. And
in the transfer update, you should see if it is in progress
or not. If you are sending messages like ack and send,
those are fast. If you are sending something big
like a file, that can take a while. You want to make sure
that all of the bytes have been sent. Once all of the bytes
have been sent, you can call disconnect from end point.
So now you are going to say, hey, I’m a TV, accept the
connection and you are going to communicate. On the phone, what
happens on the phone side?
You are going to discover the TV this time,
accept the connection, and everything else looks like the
slides I showed you. To discover the TV, this time
you call start discovery. Mind blown. You give it a service
ID. This time, I’m using a constant, and there’s a reason
for the service ID, depending on your app, it should be the
package name or the constant. If you have a package name that
is the same for both your TV app and your mobile app, it is going
to work great. If you have something like com.mycompany.Android, or
Android TV as your two package names, imagine they are on their
own channels. So the nearby connections library will not be
able to find the phone and the TV. Having a service ID used be
both by both sides is a good practice. You will give it a
mobile end point discovery call back, I love really big words.
And you will have a strategy, and I encourage you to use
cluster for this use case. You get
listeners, they are pretty important, and they are able to
start discovery. This does require location permission, so
if you get a failure listener, like permission for location
hasn’t been enabled, so they are great for debugging and trying
to urge the user down the correct path.
So the next part, accept the connection. Really simple, you
have the mobile end point discovery call back. It has two
methods, you found the end point or lost the end point. Pretty
simple. If you find the end point, go ahead and request a connection.
This requests the TV initialized on the TV you saw earl
ierearlier. If you lost the end point, maybe the user is no
longer nearby, or they gave up and closed the app and said
forget it. Hopefully it is the first for you, not the second.
You should clean up whatever metadata you collected already.
And anything after this is identical, you will have the
connections live cycle call back that shows how they communicate,
and the payload call back that shows what they are going to
communicate. And that’s it, that’s nearby in a nutshell.
And nearby is a cool tool, it is a nice box in your kits to have
more experience in a TV app. We wills go on payments, we will
look at one more example. Payments is cool, it adds a
family-friendly idea. Imagine you are at work, your
kid is at home, and they want to buy the next season of a TV
show. You get a push notification, are you sure you
want to purchase this, you say, man, my kid is at home buying
stuff, no, or yeah, they are bored, I will use my finger
print or anything from the phone to authenticate yourself. And
you enabled a purchase at home from your office.
And I have not seen a lot of this in Android. This is not a
good fit, it is not a good tool in the toolbox, but it is not
necessarily the best fit. So let’s talk about a good fit, you
get a push notification, and it says watch on TV, or watch here.
This a big game, you want to watch it, watching on a small
phone. Eh. Watching on a big TV? Awesome.
So you can use nearby to figure out proximity. They are close
to the TV, we should watch the TV button. That’s a great use
for nearby. Receiving the notification an example of
content immersion. When you said watch on TV, the background
lit up, the schedule for the game, the highlights, the score.
And then whenever the user wants, they can put the phone to
the side, it is very non-intrusive, and they can
focus on their game. So in a sense, this is kind of kicked
off from a notification. And in a way, you would say that
is more of a push model. Nearby feels more like a pulling, I’m
pulling a conversation between the two devices, and whereas in
this case you are pushing that information to the user.
And you are talking about Firebase cloud messaging after
this, I will not step on their toes too much. We will talk
about it for fun, what is the worst that can happen. You set
up the Firebase members of the jury messaging messaging service, and
this is what to do. And if the action happens to be
watch this movie or game, start watching and you are good to go.
Start watching, then it should literally launch
an activity. This is the Android Dev Summit,
I will assume that everybody has launched before. In this case,
we will set up the intent, the extras, this is a video to watch and the activity.
And next, what happens when the TV is off? I am at home, I get a
push notification, oh, man, the game is about to start. I have
to hit power on the remote, I have to tune to the channel,
man, this is first-world problems at its finest. But you can solve this. With
the fragment activity, you can call, set turn on screen to
true. And this is a cool API on activity. It is actually
introduced in OMR1. So if you are on API 27 or higher, you
should do a check. Hey, turn on screen to true, otherwise you can add the flag. So start with
your player, your content is king. So really focus on the
player, whether it is content or an ad, make sure the player is
solid. How do you make the app more usable and get the
lean-back experience so users can quickly find other content
to watch? The third pillar is distribution, is my app deployed
to set up on the Play Store correctly? When you have all
three of these, you have happy users, and who DUNCHT doesn’t
want that? If you want to take it further, use these lean-in
experiences, have payments, push notification control, add the
immersive content, the details of the game.
Thank you, and everyone go build great TV apps. If you have any
questions, you can see us at the office hours, thank you very much.
SPEAKER: The next session will begin.
Coming up next: Android Suspenders by Chris Banes, Adam
Powell. S PEAKER: Hey, good afternoon, everyone. Thanks.
SPEAKER: I’m Adam. SPEAKER: I’m Chris.
SPEAKER: This is Android suspenders. We’re going to talk
about coroutines, and to get started, many of you are
probably familiar with Android’s main thread. Like any other
toolkit, it exposes a UI or main thread for exposing updates to
parts of the UI. You may be inflating views, measuring
layout operations to change the shape of your view hierarchy,
drawing, and many other things like processing input events and
so on and so forth. So today you are probably
familiar with the 16 millisecond time limit, the vast majority of
devices out there are have a refresh of 16 hertz, which means
you have 16 mill secondss to load the display framework. You
have less and less time to get this work done as the hertz go
up. The things that cause you to
miss a frame and have Jenk in your application is app code.
If you are binding items to a recycler view, these are all
bits of work that are great if we can keep it out of the main
thread and off the critical path. How do we fix it? This
talk is not about achieving 8 millisecond refresh boundaries,
but using the resources we have available. All the phones we
have have multiple cores in them today. How do we make use of
that? Some of you probably remember this thing, it has been around for some time.
It has issues around rotation, a lot that it gets wrong. There
are executors, that developers are familiar with. It has
thread pools that are nice, but it is a raw API. You can build
things out of it, but it is not convenience — convenient to
use on its own. Loaders are a thing out there
that solved a few problems, narrowly-scoped, it is
deprecated and there’s not a whole lot there. We can use
features, there’s listenable future that showed up in the
AndroidX APIs, but you might not want to pull in all of the
infrastructure that helps you to leverage some of the thingsout
you can do with it. And unless you are working in min SDK24,
you cannot use importable future either and there’s a lot of
reasons you don’t want to use it to begin with.
So Guava, you can use that to pull into the app. And RSDK is
helpful as well. If you are here, you probably want to talk
about coroutines, which went stable in Kotlin 1.3 this fall.
So why should we use them? All right.
So whaI when I think about this question, what does the typical
mobile app do? They are CRUD apps, they Create, Read, Update,
Delete data. And usually it is a source, a database, or
whatever it may be. And it has some kind of sync. They will
upload data and pull it back from some kind of web service.
And apps are pretty simple computationally, you are not
taxing the CPU very much. And I guess the logic can be tricky to
get right, but they are pretty simple. And in Android, we put
a lot of stuff in your way. We make your life harder, but your
apps are pretty simple from a logic point of view.
So why coroutines? And how do we fix that? They are great for I/O
tasks, especially a resource-constrained system,
like the phone and tablets you are using today. And you cannot
create a thread for everything network request that you ever
use, because threads take in the space of that, they take about a
megabyte of RAM every time you create one. That is why thread
pools cache threads for you. And coroutines take in the realm
of 10s of kilobytes in a Coroutine, they use threads
underneath in a much more optimal way. They have an
easier development model. It is easier for developers to come
into a new source, and see an imperative, line-by-line
Coroutine of something like an RX Java chain. To understand
what is happening there, in my mind it is easier, and the same
for call-backs, everyone knows about call back hell, and going
line by line and seeing what you have called and stuff. And
coroutines hopefully, anyway, fix that.
And so a lot of this talk was written in mind with an app I
have been writing called Tivi, I went all in in RX Java, it is 50
percent coroutines and 50 percent RX Java. I use
both, they both have a place in Android development, so I say
use both. And as developers, we have to care about APK size and
method cans. I’m using free libraries from the coroutines core, and RX2 that
allows you to interact with RX Java.
And if you are actually pulling down the jars files to central,
they come to 774 kilobytes. That is quite big. And once you
are actually putting that in your APK, it shrinks down. It
comes down to 500 kilobytes. And the references are quite
high, 54 percent of your 64K. And as soon as you turn on
minify, and now this is tree shaken, no optimization turned
on here. And they both have results.
You are looking at 113K. So a lot less, and again, the
references is dropped. As soon as you turn on optimization, and
you fix all the program rules, you are coming down to the magic
value, which is less than 100 kilobytes. And your reference
is now 834, less than 1 percent of your references.
And now one thing to note, when you are using R8, you need to
use this rule. It is not bundled with Java, hopefully
added soon, but a simple rule to add.
SPEAKER: Okay. So hopefully you are thinking
about how to use coroutines in your app, we will talk about how
to write them. Anything you do with a call back feature, you
can do with a suspend function. Anything with coroutines is a
suspend function for creating APIs, they can suspend without
blocking and resumed later with a call back and can only be
called from another suspend function to set up the machinery
involved in that. The core thing is all of this fits in one
slide, the language works the same in thethe presence of
suspend functions and we will spend the talk talking about
that. This is the suspend from Chris’s app, a data repository
for TV shows, you call the update show function with the
ID, we get some shows, and we get a little bit more data from
a remote source, and a little bit more data from a second
source. We merge all of that together and we save that data.
So these three main tasks where we spend the bulk of the time,
these are done sequentially, but none of them have a dependency
on one another. Wouldn’t it be nice to do it concurrently? With
the async builder, we can do it. We start from the top here, we
open a Coroutine scope, and this allows us to build a parallel
composition using the async builder, it has the receiver in
the scope for the Lambda block block we have. We build the
async operation, the second, and the third. And we await the
result of each one in turn. So the nice one is that we have
launched all of these things, let them run independently and
then we bring them back together again.
So since all of these things can be now done in parallel, things
should complete faster. Trying to do this with raw threads by
hand is a lot more code than you need to maintain along the way.
The async builder is when you want to run something and await
the result after giving it a chance to finish while doing
something else. It is similar to C# or promises in JavaScript.
What if you want to launch something and forget? There is
that, too, it is called launch and works the same way. In this
case, it is a lot more similar to executors and just sort of
submitting a task, submitting something to an Android hand led
handler when we just want to fire and forget and deal with it
later. Those are the basics of running
coroutines in isolation, how do you handle it on Android?
So you may have the components ViewModel, wouldn’t it be nice
to have a way to put all of this stuff together automatically?
You need to open a scope, where can you open those things to
begin with that you can launch into? In this case, the model
has a show repository, the data layer, we have the viewer state
that the viewer activity or fragment observe. We refresh on
construction and we have the construct property.
This is coming up soon. The refresh function uses the
Coroutine, the launch builder, and updates the function on the
repository. And the Coroutine updates back on the main thread
so we can manipulate the view hierarchy, so we have a nice,
clean, sequential ordering of operations.
So those of you who want to check out this thing that is
upcoming, you can go to this link, take a look at the change
so far in advance of the actual release. It is a release of the
KTX libraries. We will demystify how this works.
Before we go deep, we will talk about the other primitives that
are under the hood here. Woah, we lost our deck.
Uh-oh. Did we switch to the wrong — keynote crash .
SPEAKER: We will talk about jobs, so what is a job? So when
you look at the code snippet, you are actually using the
launch method. And now when you are actually running that launch
method, it returns what we call a job. And a job allows us to
reference, keep a reference of the ongoing piece of work, it
has one method on it, it is called cancel. In this example,
we would not call cancel straight away after we launch
something, that is ridiculous. What it does allow us to do is
to handle double refreshes, if you have something that pulled
the refresh in your app, you don’t want the bugs to happen at
the same time and then you have two things happen at the same
time. So here, this code snippet, you can keep a
reference of the one that is currently running, and if first one. And that is the kind
of how the job works, it is a very simple object. It allows
you to keep a reference of the on going piece of work. So you
may have seen that scope and wondered what it is, Adam
explained it earlier. You can have a scope, and it provides
you with all the context that you need to run a launch or an
async. So let’s look at how they work
underneath. So Coroutinescope ask an
interface that allows objects to provide a scope for coroutines,
think things like with a life cycle, like fragment,
activities, ViewModel. They can provide a life cycle full of
Coroutine itself and start and stop it as it needs. Async and
launch used to be global methods, and a recent refactor
brought them as instant methods on the coroutines scope. And
what it means is that, mentally, instead of just launching
something, you are launching a Coroutine on X. So I’m
launching a Coroutine on the activity. It changes it in your
head, so it is tied to the life cycle of something else.
SPEAKER: Right if you are used to working with the life cycle
owner in arch components, the life cycle owner has a life
cycle that you can observe and attach things to. A Coroutine
scope has a context that carries everything necessary to launch
the Coroutine. SPEAKER: YOU CAN s.
SPEAKER: You can essentially map the context.
SPEAKER: And it crashed again. SPEAKER: Well, it is a good day
for slides. SPEAKER: Got it back?
SPEAKER: Okay, cool. SPEAKER: So we will look at
another example. We are not using the V model scope, we’re
going to add the data ourselves . We created a job, a simple
instantiation, and then we are going to keep that — we are
going to create a Coroutine scope using add a job. Anything
that runs on it allows us to track back using that Java
object. We will give it a default dispatcher, talk about
it later. And anything that is launched on that scope will be
run on the main thread, so the Android main thread. So once
we’ve done that, we will have the refresh method, and we will
use our own creative scope, the same code, using a different
scope. And this time the launch we scoped to the job object woe
created — we created earlier. And what has been torn down,
we can call the job.cancel, and any coroutines that are running
when it goes down will be canceled at the same time. It
reduces memory leaks and allows it to tidy up. So if you can
look at how things are running now, so we have launched the
Coroutine and we are going to go into the update/share method.
So here we are in Coroutine, the launch, which is that blue thing
going around. And in the update share method, which is denoted
by the yellow. And this is the async builder, we have a first
Coroutine running. And so it is running nicely, doing its thing.
And the outer Coroutine goes past that, and the second async,
which is the remote. We have two coroutines running, well, we
have three. But two in the launch.
And once they are going along, we go into the first await. And
that first async, the local, to finish itself off and return a
result, what is what the await will return. Because we are
waiting on the first Uync, the outer coroutines are suspended.
And during that time, the ViewModel is down, and we call
job.cancel. And at this point, the outer Coroutine is cancels
and the inner two are canceled. And the child coroutines inherit
from the parent. So if the parent has been canceled,
anything below it will also be. That is something that was added recently.
WLAUPS if what happens if you are using view models? So as
part of the Android architecture components, we added a listener
functionality of the life psych cycles. You create a life cycle
observer, in this case we are using default, you can add
create, destroy, stop, or whatever it be. And you can
create instance or observer, hopefully you have seen this API
before. And this builds a scope of where life cycle observer,
which allows us to scope coroutines to the actual life
cycle instance. The primary API is it passes the Lambda, and
that is what everything runs with when you are started, that
is kind of what you are using most of the time. So it will
allow the governance, and the first thing we want to do is on
start, we are running the piece of code, creating the Coroutine
scope, and running the dispatches domain. And then we
will call script.launch and call the Lambda. Pretty simple. And
finally, on stop, it seems like a good life cycle to use that
will call and will eventually cancel the job. And that means
the Coroutine will be canceled. You can see that it is not
actually that complex. In AndroidX, if you look deep down
into it, it is pretty simple. To finish it off, we will have a
nice build function, you pass the Lambda, and it will observe
it for you. And what it allows us to do is
like this. So here we have a detailss fragment, the live
scope, and then run something. And it will automatically start
it, when we get to — it will be started when we go to start and
new fragment, and then it will be closed or ended when we get
on stop. All right. Brings us to
cancellation. SPEAKER: .
SPEAKER: We talked a lot about cancelling a Coroutine, what
happens when this cancels? If you have a block of code that is
running, what is torn down when you need to clean up? So when a
Coroutine is canceled, if it is while it is suspended and
waiting for something else to happen. In call back terms, it
has not been invoked yet. It will throw a cancellation
exceptionexception, it will resume from the point it was
suspended with a cancellation exception. What does that look
like? This is the example from before. What happens if we need
to clean something up if this is canceled in the middle of the
update show function? Because it throws a cancellation exception,
this is something we know how to do already. The blocks run as
expected, we don’t need to add concepts from what we already
know from the rest of Kotlin. If the block-in code is running,
it requires cooperation in order to stop what it is doing. So we
can check for that cancellation explicitly in a couple ways.
Generally this means checkinging to see if the Coroutine is
active. And one of the patterns is if
you know the job is canceled, you can call the stock
suspendingsuspending method, such as yield, to force the
cancellation to be thrown. If you are canceled, when you are
trying to suspendsuspend, you will resume when the
cancellation exception, so it will immediately throw if we
happen to be canceled. If you throw a tight loop, you can
check the is active that is available from any suspending
scope and you can stop what you are doing. There is no reason
to involve an exception here if you are doing a tight
intercomputational loop you need to break out of. And that leads
into how exceptions are handled with coroutines in general, and
there’s a few things to point out, especially if you followed
Kotlin’s development leading up to release, because there were
significant things that happened. Launch will re-throw
unhandled exceptions as they happen. It fails the parent, it
cancels the parent job. The parent sees the cancellation
with the original exception as the cause. And they get thrown
back to the exception handler in the root of the job tree, and
the Coroutine context gets a chance to intercept. You can
attach a special element to the Coroutine concept itself that
you can use to handle handle unhandled exceptions.
How does it work? So say that save show throws a
domain-specific exception in this case.
So in this case, this will be treated like an on-call
exception at run time, just like anything else that calls the
exception on the main thread. Async is different, if the
exception is thrown while something you launch with async
is running, it will hold the exception and only throw when
the caller calls await. So going back to the example from
before, we will use what we know.
So we throw our exception from one of these async jobs, and
that gets thrown from this call to await itself. So we know
exactly where we need to try and catch that exception in the
normal way and handle that error.
But there’s a gotcha here, and that is that async works the
same as launch in terms of how the nested job tree is handled.
The deferred object is another kind of job, it will cancel the
parent, just like launch does, and it will do it even if we did
an await and called it. This is important, if something throws
an exception, it is important that your app knows about it, it
should not disappear into the Ether, but it we caught it, what do we do?
So instead of using Coroutine, we can use supervisor scope. It
works like a Coroutine scope, but it is a supervisor job that
will not be canceled if it is handled with
an unhandled exception. SPEAKER: And earlier, we
mentioned that me can decide when coroutines are run and what
thread they run on. On Android, we run on threads, and we are
using the thread pull underneath. And we can decide
when that is dispatched on. And now let’s have a look. We
are running a very simple launch, that is missing a scope.
We are looking at the example. And default is the context we
are using what is called a dispatch.default, that is what
is given to you for free, and it is default for everyone
FWLNCHLTS . SPEAKER: A computation thread
pool. SPEAKER: So what is a Coroutine dispatcher?
It schedules it to run on something, in a thread in this
case. And the default, which you can
get, is it uses CPU threads. So your device has four CPUs in it,
you will get a thread pull of four. So it is not as great as
I/O, it is more like a computational-type dispatcher.
And it is also an Elastic thread executor, that I will talk about
in a minute, but it is the default. There are
dispatchers.I/O, that was added recently, and it was designed
for blocking I/O tasks, so things that we care about,
network, image loading, reading disks, database, blah blah blah.
It uses 64 parallelism, which means you can have 64 tasks run
at a time. It can launch it like that. And the really great
thing about the I/O dispatcher is it shares thread pulls with
the default dispatcher. And the point where it is great is this.
We have an async that is using the default dispatcher, and then
we load an image on the I/O dispatcher, we do disk reading,
and then we’re going to use that result and process it somehow.
It is a computational task. And now what?
Because this is running on the default dispatcher, there is no
actual switch in there, we are using the shared thread pools,
the I/O uses the shared threads, and there is no actual thread
switch which makes it a whole lot quicker. And we have
dispatch.main, it allows running coroutines on the main thread.
And it uses service loader to load the dispatcher in your
code, which is tricky when we have things like Pergyle, so you need to be
careful and add the Android dependency. So use it, launch the dispatch. That
brings us to reactivity. How many launches can be
summarized by this slide? I have been guilty of this.
And I will make the premise and the statement that most devs use
RX Java because you can switch a thread, or switch multiple
threads, that is when most RX Java is useful. And I think,
for 80 percent of the cases, it is a switcher thread. And that
is because the APIs that we have, and we spoke about them
earlier, are not so great to use.
And because of that, most people end up using things like single,
maybe, and completeable. That’s what they are, they are a
single, one-shot thing, a single allows you to have a type, maybe
it is nullable, and the completeable doesn’t have a
return type. They are all pretty similar. But in fact,
they only exist on RX Java, RX Ruby.
So they can be replaced by single, maybe, and completeable.
They do what you think. They replace call-backs, and they
replace these nicely. So as an example, we have a retrofit
interface, and it has a Git and returns a single. And the way
you use that a in RX Java, we have the scheduler, and we will
do some calls when it is finish ed. The nice thing about the RX
two libraries of coroutines, you can use that exact single as an
await. So you can actually use it as a suspending deferred. So
it is handy for when you are slowly migrating towards
coroutines and you don’t want to change from day one. You can
actually keep those interfaces, and you can actually just call
await on them and you never receive using coroutines. It is
a handy way to slowly migrate.
And wouldn’t it be great if we can make the retrofit call, a
suspending function, and remove the RX from the start?
Well, we can. And that is coming to retrofit soon. Jake
has a PR, in review, and he tells me it is soon. And if you look at
consuming code, it is a normal suspending call. And that
brings us to a final section, bringing it together and trying
to think of two scenarios that we will show you to use
coroutines to make your lives easier on Android. Both of
these examples are about location. The first is about
getting the last known location, which is the call
back. And we will use the fused location provider client. And
it is kind of cool, it combines all the providers that we have,
like WiFi, GPS, mobile, and bluetooth, it provides all the
providers for you into one single API. It is a nice API to
use. And it returns a task, a futury-type thing that the
library has. And so you get the
classification and it returns the task. And then you add the
complete listener and you get the result back. So it is
completely async. So what we are doing is we are
converting the call back API into a suspended function. The
coroutines library has two builders that do what we want.
The first is suspend Coroutine, and you pass a Lambda under it
that allows you to set up the call back. So we call play
services. And then, at that point, the Coroutine suspends
waiting for the results to come back, and the call back can wake
up, basically. So right now, you are getting a
continuation to later resume. And then you will pass the
result back. And it allows the call.
So there is the suspend cancelable Coroutine. So let’s
say it is canceled, you can — under the line API, play
services, to cancel its call. So we will build that function,
get classification, and it returns a location, not the
future or anything like that. Just a straight location. And
so we are going to use our suspend cancelable Coroutine
builder, and then you get a continuation, the call-back type
thing, and then we are going to set up, so you are going to call
the location client, the play services API, the last location,
and then we get a task back and add the complete listener. At
that point, we are going to wake up our Coroutine. So that is
how we pass back to the suspended Coroutine, the result,
and it wakes up in the suspended function basically, or it
resumes. And because this is a
cancelable, because this we are using task, we are not using
success, we are using the complete listener, which means
that the task itself can throw an exception. It can fail for
whatever reason, so you don’t have location permission or
whatever it be. It will raise an exception on you, so you can
populate that back up to the call, which is done with the
review and exception method. And finally, because we are
using suspend cancelable Coroutine, we need to tell the
play services API that we have been canceled, so therefore it
should cancel. So we did that with a call back, which is
invoke on completion, and once you know it has been canceled,
you have play services. And play services does not have the
cancel method, but imagine it exists.
And now Adam is going to talk about observing.
SPEAKER: Sure. So what happens when you want to observe a
sequence of events over time? This is what RX is good at, if
you are using it for anything t , it should be this. People
compare RX and coroutines quite a bit, so what does it look like
if we emulate this using coroutines as a primitive. So
it is an API in addition to letting you get a one-shot, it
the current location, you have the up adapts updates. So this
is a prime candidate to be an observable. And we get this
composable control over shutting it down the down the updates
cleanly. It offers a lot of functionality to build things
like this. So how many similar benefits can we get if we base
this off of suspending functions?
So let’s again start just writing a simple function, or it
is going to start out simple. Suspending functions do not
return until the work is done. There is no disposable or
closeable return, since the calling scope itself is
cancelable, we do not return until we are done. So the
observer in this case can be a Lambda that accepts a location
result, we will call it whenever a new location is reported
without returning from the observed location. So if you
take in the giant pile of code here, some of you may mote
notice that it looks like an observable.create. We will
create the done signal that we can await on later, so is this
like the observable completion. If you have a stream with a
well-defined end signal, you can clean this up to let it clean up
and return and we will see that in a bit. So the next piece
here, we are creating a location call-back, we need to know when
to receive updates from the provider. We use launch to get the — the Coroutine scope
that we opened here carries the dispatcher with it that it was
called with. So we know that we are going to call the observer
in the same place that the caller wanted the information
reported. So we cancel the old job, and we
call the observer when holding the suspending new text, it
keeps it serialized so we don’t have too many at once.
And it will not have multiple calls open at once either. And
this is an example of some of the things that if you are
building one of these things yourself, this is a comparison
that RX Java does a lot of these things for you. With
coroutines, we have the primitives to build it, but we
need to do a little bit more by hand. And so we register the
call back, and then we await on the done signal. Since we never
complete it, when is the location stream complete anyway?
This waits for the calling job to be canceled. So we have it
on the blog, and request location updates takes a looper
instead of an executor, which is unfortunate. So if you can use
a direct executor, it will just go ahead and run the observer
wherever the update happens on the incoming binding thread, it
shines when you can avoid the extra hops. You get the idea.
And so here is what it looks like in use, and it looks a lot
like a four H call in a collection and behaves the same
way. If we use launch to call the observer, if the location
call itself will throw in itself. So it is a
child job, it will chancel the parent scope with the exception
as well, what wraps the observed location function body. It will
have the await, unregister it from the final block from above
and all of this composes so you can lean on the constructs of
the language that you know by adding some of these suspending primitives.
SPEAKER: So we will wrap up a little bit. What is next?
Well, the first is that, as you saw thin keynote earlier, we
have a code lab for coroutines, that was released three weeks
ago, a really good introduction into coroutines and how to use
it in your app. Read the manual, and the docs are really,
really good. And you can edit them how you
want to, they are use-case based, so I need to do X, how do
I do it? Make sure to check it out if you are using coroutines.
That is it, thank you very much. [ Applause.]
Coming up next: Modern WebView Best Practices by Nate Fischer,
Richard Coles, Toby Sargeant. Coming up next: Modern WebView
Coming up next: Modern WebView Best Practices by Nate Fischer,
Coming up next: Modern WebView Best Practices by Nate Fischer,
Coming up next: Modern WebView Coming up next: Modern WebView Best Practices by Nate Fischer,
Coming up next: Modern WebView Best Practices by Nate Fischer,
Coming up next: Modern WebView Best Practices by Nate Fischer,
Richard Coles, Toby Sargeant. 1XZ Coming up next: Modern WebView Best Practices by Nate Fischer,
Richard Coles, Toby Sargeant. [ Applause ].
SPEAKER: Hi, everyone. My name is Nate, I’m here from the
WebView team, I would like to talk about some modern WebView
best practices or, as I like to call it, using WebView like it
is 2018. Because it is.
Before I dive into what is modern with WebView, we will
talk about what is old. So WebView has been around since
the very beginning, added in API level 1, and it changed in a
significant way, starting with Lollipop. It became updateable,
the implementation was. And this was great, it meant that
users could benefit from security fixes and bug fixes, it
would update every six weeks, just like your browser. And a
lot has changed since then, too. We added 40 new APIs, ZUST —
just to make it easier to work with WebView to help developers.
But what has really changed? Well, when we look at the
ecosystem, it seems like apps are kind of using WebView the
same way they have always used it. And when you look at
StackOverflow, the answers are outdated at best. They are
certainly not best practices and, often times, they are just
wrong. But some of the blame is on our shoulders, too. A lot of
the doc is still written like it is API level one and a lot has
changed since then. So we looked over the past year and we
looked out at the Android ecosystem and the devices that
are out there today. And what we found is that, although we
added, you know, on nougat, all of these great APIs, a lot of
apps cannot take advantage of them because they run on the nougat devices, less than 5
percent of devices today and it has been two years since it came
out. And a lot of devices are running lollipop and the
implementation of the APIs are not exposed on older platform
levels. We thought, can we do better?
So, over the past year, we worked on our AndroidX library.
We launched a new AndroidX library, and we are pretty
excited about it. The basic idea is we will bring in all of
these brand new developer APIs, but we are going to try to give
you the device coverage you need, and we are going to
support lollipop and above. We will leverage the update cycle,
and make sure that it is usable so you can use the APIs to do
productive things. We designed them to be straightforward to
swap out from the framework’s APIs. So this all sounds fine,
but how can we use it to make your apps better?
So let’s take an example. Since the very beginning of Android,
we have given apps a lot of power to customize WebView’s
behavior. And, in particular, we added a call back called
override loading, and the idea of this call back, for search
and navigations, you can cancel things in the WebView and
dispatch them to a different thread instead. Joy can have a
YouTube url that is better suited in the YouTube app. And
this is great, a lot of apps took advantage of this. But
there was a problem with the API, we did not get it right the
first time. And the issues that JavaScript can trigger
navigations, there is malicious JavaScript out in the wild that
actually tries to exploit this app behavior. And, from the useruser’s perspective, they
might be reading web content and without their interaction, it
starts opening up some new Android app that they are not
trying to open. And so we actually already fixed
this issue. We fixed it back in Nougat, where the idea is that
we exposed this notion of user gesture. Did the user trigger
this navigation? And it actually works really,
really well, but it only works on the Nougat and above devices,
and these — before, Nougat devices are still vulnerable.
Weal thought it was a candidate for AndroidX library, we will do
this gesture all the way back to loll Pop for devices and you can make
it a safe experience for all of your users, and we can make it
easy for apps to override T. There is no confusion. I think
we succeeded, but we will look at the code. Before Nougat this
is what a lot of app code looked like, we are doing overview coding,
and in the coding, and this is the insecure
version of the API but in the past the best we could do. Some
better apps that were out there is something like this, you are
overriding the old implement from before, the before Nougat
devices, and the newer devices, you have this implementation, we
are choosing user gesture, we not launching intent if we don’t
have user gesture. So this seems great, but it only
runs on a small number of devices, even today, only 50
percent. So here’s how it looks like with
AndroidX. And the first thing I want to point out is that almost
nothing changed on this slide. I think that is really
beautiful, it means all the code that you already wrote to
handle, you know, the old framework APIs, that code is all
the same. The only difference here is that
we are employing — we are importing our WebView client
compat class from the AndroidX library, we setting this compat
client, and the idea is that we are using the compat client, instead of invoked on Nougat and
involved, they are invoked to Lollipop so you can provide your
users a safer experience without changing a lot of code.
This is one example we have to everyone in AndroidX. O I I
would like you to check it out it to so how it can make your
app better. We are giving you the device coverage you need to
use these APIs, but we will have a lot more APIs available. Some
of these are small improvements on classic APIs, like we’ve
seen, and some them are for en tirely new features, like safe
browsing. And had point is this is not in
a soon to be released library, it is out there, ready to go, so
you can try to 1.0 release. I would like to shift gears a
little bit. We looked at the AndroidX APIs, these same great.
You are going to give us new APIs with, you know, pretty good
device coverage, almost ninety 90 percent. What about the APIs
around forever, they have 100 percent device coverage, but
some of them are hard to use. Even I struggle to use them
correctly and I working on the team. A common use cay we have
seen is loading in-app content. And the idea is that you want to
display some content in your application, but you don’t
necessarily want to fetch it over the internet, you want to
just compile it right into your app.
But you also want to continue to build this content with web
technology. You want to use html, JavaScript, CSS. And
WebView has had pretty good support for this, in fact, we
almost have too much support for this. We have so many APIs that
it is hard to figure out which one is actually the right thing
to use. And some of them have some weird
gotchas that make them kind of hard to use.
And so I thought maybe we could take a look at some of these
APIs and talk about what is so tough about them and recommend
some best practices. You don’t have to start from scratch with
a new API, but you can kind of tweak how you are using these.
So the first API that we can look at is Load Data, and the
basic idea is that this is going to accept some html content. It
accepts it as a string, and it is supposed to display this in
the WebView. And but one of the gotchas is it
does not really accept html content, but encoded content.
The idea is that you need to escape special characters,
replace them with a percent sign and the code following it.
And we call this percent in coding, this is the default
configuration for the API. But there is actually no framework
API to do the percent in coding for you.
It is kind of an oversight. But the end result is that
developers, what we’ve seen, is that developers tend to actually
do this percent in coding by hand themselves. And this is
manual, it leads to bugs, and these bugs can have significant
impacts for your application. You know, one small bug might
seem okay today, but it might break in a future WebView update
if you forget to encode a particular character.
The other issue with load data is this thing called an opaque
origin. So when your content is loaded
with what is called an opaque origin, this means that it is
going to fail all the same origin checks in the web.
And these same origin checks are actually chit critical to
providing powerful web APIs securely. Without these, you
cannot provide great APIs, like html http requests.
So what can you do with this APIAPI? You can escape the
coding-related problems. This API has always accepted an
alternate encoding scheme, base 64. This is not that special of
a coding scheme, it is just a different scheme. It is not
necessarily better, but it is kind of nice because there is
actually a framework API that will do the encoding for you,
and it does it correctly. Great.
So the base64, encode to string, it will take the content, spit
out the right answer. And the only reason it is not documented
is because this came out in API level 8, which today is ancient
history, but was still in the future at the time of writing load data.
But we can also take a look at the same origin restrictions.
So the way we recommend to get around this is to use something
called load data with base url. And one of the nice things about
this, I think of it as a feature, not a bug, is that it
actually accepts the content as is. You can give it content
that is totally unencoded, you don’t have to worry about the
base 64 stuff if you use this API.
The other really nice thing about it is it has this thing
called a base url. You are displaying this as you pass in
as a string, the base url configures the origin that it
operates it. You can control the origin that you get without
disabling the important security settings, just to make the APIs
work. How do we choose the right base url?
So this is something that even I struggle with when I try to use
this API, I know it is the right thing, but I don’t know what the right
thing is to pass to it. So we will go through the common
use cases. So something that we’ve seen in a lut lot of apps
use cached content, it is downloaded from the web over the
internet, but they are saving it for later. Now when they show
it, they need to show it with the right base url. And the url
you choose is just the original url it came from. So if it
worked originally, it has the same origin and all the APIs are
going to continue to work. The other use case that we have
noticed is that apps tend to shift the own content and
display it this way, which is great.
And we recommend that you choose a real internet-type url, and it
should use your organization’s real domain. The reason for
this is so you can import other resources from the servers and
use this content without worrying about same origin
checks, it will all work. And the question is, do we use https
or http? Here is the rule of thumb, you want to use https as
the secure protocol. If you need to share insecure
resources, we recommend that you use the html scheme as opposed
to disabling important security settings just to get your app
working. And as a last point I want to
urge apps to avoid curs custom url schemes. This is something
that cropped up, they make up their own scheme and use that.
But the problem is that the web standards don’t really expect
custom url schemes. They are very vague about how to handle
this, and it turns out that they wind up getting handled very
inconsistently, and this can lead to surprising app breakage.
So if you can stick to one of the internet url schemes you
will have a much better time.
So hopefully I have expressed that we care about developers at the WebView
team and we are working hard to make sure THLT that you have
powerful new APIs, paying attention to the old APIs, and
explaining how they need to be used and they are actually
usable. If you have any questions, me and my colleagues
will be around for the rest of today as well as tomorrow and
would be more than happy to talk to you about WebView usage and
what you need for your application. Thank you very
much. [ Applause.]
Coming up next: Low Latency Audio – Because Your Ears Are
Worth It by Don Turner. Coming up next: Low Latency Audio – Because Your Ears Are
Worth It by Don Turner. SPEAKER: Hello, hello. My name
is Don, I work in the Android developer team, I’m here today
to talk to you about low latency audio on Android.
So why is audio latency important? Well, there are many
use cases where the audio latency is directly proportional
to the user experience. So this can be in games, where
you tap on the screen and you hear a sound, particularly in
rhythm games, like Guitar Hero-style games, you are
tapping in response to some rhythmic event and you need to
have audible feedback as quickly as possible, like the longer the
delay between tapping on the screen and hearing a sound, the
worse the user experience. And also in DJing apps, you are
tapping on the screen and manipulating odd we and you
expect that audio manipulation to happen in realtime. Karaoke, you have the input,
your voice, against a backing track and also your own voice.
So if the delay between you singing and hearing your own
voice is too long, then it sounds awful.
And also, in VR, we have objects that make sound in a virtual
world and, if that sound doesn’t follow you around as your head
moves in this environment, then it kind of distorts the reality.
And lastly, of course, theres a whole load of apps for live
performance, sin hesizers, drumming apps,
anything where you press a key and make a sound, you need
low-latency audio. So, with this in mind, we built
a library to help developers build these kind of apps. It is
called Oboe, and it is available on GitHub now. We just launched
version 1, it is production-ready, to be included
in your apps today. And the way it works is, under
the hood, it uses the audio API on API 27 and above, which is
the new high performance, low latency, audio introduced in Oreo. And on all the
devices, it uses open SLES. It provides a simple, easy-to-use
API that works across the widest range of devices.
So rather than me talking about this API, I thought it
would be fun to build a musical instrument in 17 minutes and 23
seconds. So, before I start that, I’m
going to explain the architecture so it makes sense
when I’m in the code. So we have an app, and I’m going to
build the audioengine part of this app.
This audioengine is going to be responsible for creating an
audiostream that is provided by the Oboe library, we’re going to
be passing audio frames of data into this audiostream.
Ultimately, this stream is responsible for putting data out
of the audio device. In this case, it will be the 3 and a
half millimeter jack on this pixel XL phone. And every time
the audio device needs more information, it is going to give
us a call-back. So we get this call-back loop of, hey, I need
more audio data, and our audioengine is going to be
passing frames of audio data into the audiostream.
For some form of control, we’re going to monitor tap events in
that screen. When you tap down, the sound will go on. When you
lift up, the sound will go off. This works about 50 percent of
the time in rehearsal, we will see what happens.
Okay. First, I need to log in.
Okay, and can you see my screen? Fantastic.
Okay, so I’m just going to run the app. So I have a very
simple shell of an app. It doesn’t really do anything at
the moment, but it has a few little shortcuts that make it
possible for me to do this in a short amount of time.
So I would just run the app on this pixel XL, and hopefully you
will be able to see that it does nothing.
So here we go. Here is the app, when I tap on the screen,
nothing happens. No sound comes out, it is non-functional. I
want you to know that there is no smoke and mir and mirrorers,
it is jen genuinely live.
[ Laughter ]. Thank you, GLRKS Glenn.
I have a few methods I will use, and I will implement them
in a second. So we will create an
audioengine, and we will start by calling start engine.
So we will just jump into our J&I code.
So this is in native lib.CVP here. So I’m going to define an
audioengine up here. I will call it engine.
And then I’m going to call a method on my engine called
start. And now, I have already created
the header and implementation files, just the blank files for
this audioengine class. So I will go ahead now and write the
class. So audioengine.
And I’m going to have one method called start.
Okay, now I can use option enter to generate the definition for
this in my implementation and I’m in the
start method. Before I use the Oboe library, I need to include
the Oboe header.
There we go.
And the other thing I need to do, where it makes it easier for
me, to use the Oboe name space. And this avoids me having to
prefix the objects with the word Oboe.
So, in our start method, I will create an audiostream. To do
that, we use an audiostream builder.
That builder allows us to set properties on the stream. That
is like the format of the stream.
And now, when I set the format, there are two choices I can
choose from, 16-bit integers, or floats. I will use floats. I
can also set the number of channels, so that is two for
stereo, or one for mono. And I can also set properties
which inform the stream of my latency requirements. So the
most important one here is set performance mode.
And there’s a number of options, but the one I want is the low
latency one. The second thing I can do is set
the sharing mode on the stream. We will set that. I will set it
to an exclusive sharing mode. So that means that I’m
requesting the audio device give me an exclusive stream, that
means that my app’s audio is not mixed with any other audio in
the system. If the device supports it, I can avoid having
my odd ye — audio mixed with anything else and I can cut a
few milliseconds of latency in the output.
So that’s all I need to do to open the stream, Joe can go
ahead now and call open stream, this takes a reference now to an
audiostream pointer. I can use option enter to create a new
field called stream. So back in the header, it is done
automatically for me. And once the stream is open, there is one
final step I need to take which, is to set the buffer size on the
stream. I can do this by setting buffer size in frames.
To get the smallest possible buffer size, we have to
interrogate the audio device for the minimal amount of data it
will read in one operation, a discrete chunk of audio data,
and we call it a burst. So we want to obtain the burst size
from the odd — audio device.
We will use stream, gets per burst. And that’s the minimum
number of buffers we can set our stream to have, but we to not
recommend that you use this absolute minimum. We recognize
that you use double this, because it provides a good
protection against under runs, and it is a good tradeoff with latency.
That’s all I need to do to create a low latency stream. So
I can go ahead and start the stream, which will do nothing
because we have not found a way of putting data into the stream.
To get the data into the stream, we use a call back. I’m back in
the builder, I will send the call back method. It will take the call
back object, and using this, I will use my this object, which
means that my audioengine needs to implement this interface.
So I will do this, and I will use control O to show me the
methods I can override in this interface. I want on radio
ready, the method that is called every time the audio device needs more data.
So inside here, I will look at what this method signature is.
So on audio ready is called, it tells me the stream that wants
more data, and it gives me a container array. So this
container array, which is of type void star, because it can
be either 16 bit integers, or floating point samples is
something that I’m going to write my audio data into. SoI
so I write that, that is passed to the audio device. And next
is num frames, it tells me the number of num frames that need
to be populated in this container array. I need an
audio source, I will cheat a little bit here. I created an
oscillator in advance, we will take a quick look at it, and it
is going to generate a square wave here. So that’s a periodic
signal, varying between two points to create a square wave.
We will create an oscillator. So this is the template object,
I need to tell it what type.
I will include the oscillator header. And now I have the
oscillator, I will do ask render, so Android Studio is
complaining about the signature. I will build, and that will
normally sort it out.
Ignore the arrows. So on my oscillatoroscillator, I have a
render method to put the audio frames from the oscillator into
the audio data array. So the first thing I need to do is to
cast it to this — an array of floats.
So audio data. And pass in the number of
frames. So the last thing I need to do
on audio ready is return a result. This can be either to
continue where the call backs will continue, or it can be
stopped and the call backs will stop. So, in my case, I’m going
to continue. And the final thing I want to do is set some
things up on my oscillator. And soso I’m going to set the
amplitude, which is the volume, and I’m also going to set the
frequency, set that at 80 hertz, a nice base freaks frequency,
and the sample rate, which tells the oscillator how frequently
these samples should be produced.
And I can get that from the stream, get sample rate there.
Okay, I know that you are all desperate to hear a sound.
There is a final thing I need to do here, I need to respond to
tap events. So I will just go back into the main activity and
I will override the on touch event so that if the event is down, then I’m
going to call this native method tap, to make that true.
Otherwise, if the event is up, I’m lifting my finger off the
screen, then I will pass in false. Okay, let’s have a look
at the tap method. This needs implementing.
So I will pass in the true or false value, create the new
method, and they will just call ask, set, wave on, and that is
going to pass that in there. Now, a moment of truth.
So I’m going to run this and, in theory, you should hear a sound.
And when I tap on the screen, we should hear an 80 hertz square
wave. The pressure.
[Tone]. There we go.
[ Applause ]. [Buzzing noise].
SPEAKER: So you can see, it is the lowest possible latency
here, and it is actually — [series of beeps] — pretty
responsive. So we have a musical instrument. Admittedly,
it is not the best instrument in the world. It is a little bit
to be desired on the sound. So what I thought would be nice is
if you could add a little bit more control. So for the last
four minutes and 30 seconds, I will tie the motion sensor to the pitch of the oscillator. To
do this, I’m going to cheap. I will call in some code that I
did earlier, and it will register a list now that will
listen to the rotation vector sensor.
So to listen to these events, I need to implement the sensor
eventevent listener interface, implement the methods,
onsensorchanged. So what I want to do is set the frequency based
on the event values of the X axis. And I also need to scale
this value. So I want to have it from, let’s
say, from 20 hertz, the limit of human hearing, and we will go up to, like,- this will give me
up to around 100 hertz. So, yep, that looks good.
So again, I need to implement this. Frequency… so we will just go
ask set frequency, and there we go.
Okay, so we are good to go on that. Brief interlude. Very
brief, in fact. Has anyone heard of the R man break?
One person. So the R man break comes from a song in the ’60s, R
man brother, 4bar four bars of the most incredible drum solo,
the most sampled loop in history, but nobody has heard of
it evidently, apart from one guy. I thought it would be nice
if I can play my new musical instrument over this loop.
So here’s the loop, I need to run the app. We will give it a go.
We will make sure it is here.
So, with a bit of luck [drum sample].
[Oscillating tone].
[Drumming and oscillating tone]. SPEAKER: Right. [ Applause ].
SPEAKER: Okay, so that is about it from me. If you can go back
to the slides.
And, yes, the library is available on GitHub. There’s a
documentation, codelabs, all sort saidsses of stuff in there.
We would love for you to build awesome experiences on Android,
and I’m here for any questions. Thank you all very much.
[ Applause ]. SPEAKER: Thanks, Don. With the
end of that talk, that is the end of the day.
That means that it is time for a par party. So the theory is we
will have food, drinks, and a DJ. I vote for Don do the DJ.
I wanted want to hear that tune all night long, or a two-minute
loop and that is probably about enough. So 6:20, the party starts….

Only registered users can comment.

  1. Thanks for tuning into #AndroidDevSummit livestream for Day 1. Be sure to come back tomorrow for Day 2! Both Theater 1 and Theater 2 live streams start at 9:30 AM (PST)

    All recorded sessions will be available in this playlist → http://bit.ly/ADS18-Sessions

    Livestreams from Day 1 are still available:
    Day 1, Theater 1: https://www.youtube.com/watch?v=Wkl9GmluS7E
    Day 1, Theater 2: https://www.youtube.com/watch?v=OraUYXz1yFM

    Livestreams for Day 2:
    Day 2, Theater 1 → https://www.youtube.com/watch?v=UljafaxRcEE
    Day 2, Theater 2 → https://www.youtube.com/watch?v=mtEALHDWsSs

    Take a look at the event schedules here:
    Day 1 Schedule → https://developer.android.com/dev-summit/schedule/day1
    Day 2 Schedule → https://developer.android.com/dev-summit/schedule/day2

Leave a Reply

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