[MUSIC PLAYING]
WOJTEK KALICINSKI:
Hello, everyone.
So today at the
keynote, you probably
heard that we are
unifying the developer
experience for Instant Apps
and Android app bundles.
And so my colleague
Ben and I are
going to talk to you a little
bit about how that works
from the developer perspective.
So Instant Apps,
it's a technology
that we introduced a little over
two years ago at Google I/O.
And it lets you give your users
a native Android app experience
without them having to
explicitly go and install
your app from the Play Store.
Now, how that works is
you split up your app
into smaller pieces
called features.
And the user can reach those
via a link, a URL, and also
via other means, as we'll see
later in this presentation.
Now, to get your
app small enough
and to be able to
launch it instantly,
Instant Apps, for
the first time,
used a technology that we
introduced in Android 5
Lollipop that's
called split APKs.
Now, with configuration
split APKs,
Play Store was able to
deliver the smallest,
most optimized version of
your app to a user's device.
Now, in order to do
that, the build system,
the Gradle Android build
system that you build your apps
with built all of
those split APKs
locally, bundled them in a zip
file called an instant bundle.
And then you upload
that to the Play Store.
So the Play Store can
choose from the set of APKs
and deliver it into the devices.
To do that, the developer had to
do some significant refactoring
in your apps.
So the project structure
of an Instant App
as it looked two, one
year ago, looked probably
something like this.
First of all, you had to take
all of your base application
code and move it from
the application module
to a base feature.
Then you had to split your
app into feature modules
containing the various
features in your app,
or normally, we would call
them screens or activities.
And then you had these two
almost empty dummy modules--
application and Instant App--
for building the
artifact that we need.
So the APK for
application, that would
be the installed application
that you used to have.
And then the Instant
App zip bundle
that would contain
all the split APKs
that you upload to a separate
track in the Play Store.
Now, this was not ideal.
As I said, it required
significant work from you.
Your project no
longer looked simple.
At the same time this
year, we introduced
a new publishing
format for Android apps
called the Android
App Bundle, or AAB.
This format preserved
some more information
about what's happening
in your project.
It contains some
metadata about targeting
of the resources,
native libraries,
and so on that are
in your project.
But it also actually retains
some of the module information
about a new type of module
called dynamic feature that's
in your project.
Now, I called it a
publishing format,
because you use it to
upload this whole big bundle
of telling the Play Store
everything about your app
to Play.
And then together with
Google Play Dynamic Delivery,
we are able to serve an
optimized set of split APKs
to users' devices.
In order to do that,
there's one big difference.
Because it happens on the
server side, on the Play Store,
we need to be able
to resign your app.
That's why if you use
an Android App Bundle,
you have to enable app
signing by Google Play.
Now, that's a good thing.
Actually, if you let us store
your key for you, it is safer.
It's more secure.
But there's also
another benefit.
Thanks to the fact that
we can transform your APKs
and make them more optimized,
as we develop more optimizations
on the Play Store
side, over time,
what we deliver
to users' devices
can be even more optimized,
as we just announced
with uncompressed libraries.
And so it would
make sense to move
Instant Apps to this new model.
Why build all the APKs
locally and then not
be able to optimize them
further on the Play Store?
What if we could use
the new App Bundle
format to deliver an 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.
So if you've ever done that
whole dance to move modules
around and move your
code to a base feature
and so on, we literally have to
go back to that simple project
you used as you
would build your APK.
So first of all, we no longer
need the Instant App plugin.
Everything that we need is baked
into the application plugin
that can now build bundles.
And so we don't need the
base feature anymore.
Instead, we can move our
code back to the application,
or we'll be using that to build
our unified bundle artifact.
And so again, with
feature modules,
we now replace them
with dynamic features
that work in 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
to your app at runtime.
And we have the single
piece of metadata
that tells the Play
Store that this bundle
is Instant App enabled.
So that would be great if you
could upload that one artifact
to the Play Store and have it
published both on the install
and instant track.
And that's exactly
what we're aiming for.
Now, there's one caveat.
We are currently testing
that with our partners.
But you might not
actually be able to upload
the single artifact to
the Play Store just yet.
That's why, if you want
to try it right now,
I suggest you create two product
variants in this simple project
structure still.
And in one of the variants,
simply enable the metadata
with enabling the Instant
App for your bundle,
and use the other
variant to build a bundle
without that entry
in the manifest.
Still simple enough,
still one project.
One app, one code base.
Just for the time being, you
might have to do that in order
to upload to the Play Store.
By the way, there's
another white list.
If you want to use
dynamic features in order
to let your users download
them on demand, as they run
your app, this is also under
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.
OK, so how to try it
yourself right now.
First thing you need to do
is use the new Android Studio
3.3 that's currently
on the beta channel.
And if you're creating
a product from scratch,
you can simply
select this checkbox.
We'll create the modules
with the necessary metadata
already in there.
So that's how it looks like.
In your base manifest,
you instant enable it,
and you're good to go.
If your app is compliant with
all the other Instant App
restrictions, such
as file size, which
Ben will talk about
later, now, you
have a chance to publish an
instant-enabled bundle already.
Now, if you already have
a project, which you're
using to build an
App Bundle, you
can also use the
new module wizard
to add a new instant
dynamic feature module.
If you add one of
these, this will also
instant enable your base
module if you haven't done so.
Now, all that's left
is build an App Bundle
either through Gradle, the
bundle release command,
instead of assemble release or
through the wizard and the UI.
By the way, if you're using
our Android Dev Summit
app right here at
this conference,
it's been built exactly as
an instant-enable app bundle.
So we published that through
our channels on the Play Store.
What you are using right now is
exactly what I'm talking about.
And it's been great.
It's greatly simplified
what we had to do in order
to have that working.
Now, let me invite
on stage Ben, who'll
tell you a little bit about best
practices for module arising
and discovery of your app.
Ben.
BEN WEISS: Thank you.
WOJTEK KALICINSKI: Round
of applause, please.
[APPLAUSE]
BEN WEISS: Thank you very much.
So yeah, let me talk a bit about
discoverability of your Instant
Apps.
Basically, one of them you
already saw, which is the
Try Now functionality.
I'll talk a little
bit more about this.
So Try Now basically
is the second button
that you get on the Play Store,
which allows users to instantly
download and run the app
straight from the Play
Store without having to
permanently install it
on the device.
That's a great experience
that you can easily
see how it works.
You can go to the Play
Store now and check it out
for the Android Dev Summit app.
Your users can launch it
directly from the landing page.
It's quite cool.
And if you don't have a URL
associated with your app,
that works as well.
So you don't have
the restrictions
that the app has to
map to URLs anymore.
How do you do that?
That's basically it.
I think that everybody has this
somewhere in their application.
It's the main launcher.
You don't have to do anything
else at the instant metadata
that Wojtek showed you earlier.
So there is nothing
else that you
have to do in order to be
eligible for the Try Now
experience.
But what if you want to
have your app available
with a 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 is
you have to verify that
you own the domain.
To do that, you generate
and upload an asset
links JSON file.
There's a couple of
helpers online that
verify whether the file
you uploaded is correct
and the one that you
have in your app--
that the mapping is
correct with that as well.
And then you can share
the link with anyone,
and they can open
the app straightaway.
Let me walk you through how
that works from where we
started with the main launcher.
Basically, you have
to set a second intent
filter with the auto
verify flag set to true.
That flag tells the
Play Store that it
should check for
the asset links JSON
file on the URL provided below.
Then you add the Action View
category browser by default
that you say that
this is the one
thing that I want to use as
the default to view this URL.
You then add the
schemes for HTTP, HTTPS.
And you can add multiple
path or path prefixes
to just walk the user to
multiple of your activities.
For the one that you want to
use as the default activity--
so when they come from Try
Now or whether they come from
your home screen--
is the metadata here.
It has to be a sibling
[? tack ?] to the above intent
filter, which just says
this is the default URL.
And this is where I want my
users to come in initially.
Like I said earlier,
if you don't
have a URL in the first place,
you don't have to do this.
But if you have to
have a URL mapping,
then this is the way to go.
And it's not a
lot of work to do.
And it gives users
the experience
that you can share any link
that leads to your app.
And any Android user can then
open the app straightaway
without having to
install it permanently.
And I think, for a conference,
it's a good use case
to have an app
that you use once,
and you don't have
to fully install it.
You have the instant
app, and for a couple
of features, like, in our
case, it's notifications,
you still have to
install the app.
But it's fair enough
to have an experience
that you can start straightaway
without the first steps
necessary.
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.
We're going on forward now.
You have to ship your
app as an App Bundle,
and you have to use dynamic
feature modules in order
to make use of the
Play Core Library.
The Play Core Library allows
you to download features
dynamically on
demand, so not during
the initial installation.
And it's unified between
Instant App and installed app.
So you don't have to do
different calls on that,
and it does all
the heavy lifting.
So if you say to Play Core
Library, download this,
it connects to the Play Store.
It downloads it.
It puts it in the right
place for Instant Apps.
It puts it into the
shared [INAUDIBLE]
and installs it on that
device permanently.
So how does it work?
Well, you add it as a
dependency available from Made
from Google [INAUDIBLE]
and use it in your project.
And then you create a split
install manager factory
within your activity.
You hold onto that.
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
manifest of that module.
You build it and then
you just tell the manager
to start the installation.
And that's all the code
that you need in order
to get started with it.
Obviously, there's
a couple of things
that you have to do around it.
I'll go into that in a second.
But before we do
that, if you don't
want to start the
installation straightaway,
there's a way to do a
deferred installation.
So for example, if you have your
instant app, you'd start it.
And you know that your user
is in a flow, where they're,
for example, buying something.
So they've logged
in, and then they're
starting the purchase process.
And you want to download a
payment module, for example.
You can do that deferred
or during the flow.
When the user is in that, you
can do these installations.
Also, uninstallation
is deferred.
So that means the uninstallation
doesn't get done straightaway.
But at some point,
where the system
says, yes, I'm cleaning up,
this is where this module also
gets removed.
You can also cancel
installation requests.
If, for whatever reason, you,
from a developer perspective,
want to cancel that,
there's an option to do it.
And there is a listener that
you can set on the manager.
That's my preferred
way of listening
for the state updates, the
splitinstallstateupdatelistener.
It's quite a word.
That's quite a few things.
So usually what
happens-- the happy path
is you trigger an install.
Your app starts with
pending and then goes
to downloading, downloaded.
And then there is
installing and installed.
That's your happy path.
That's what happens
for a module that
is small enough to not trigger
the required user confirmation.
If you go into that
state, you will
be given some information that
you can start an intent with.
And that intent allows
you to show a dialog
that the user can
confirm or deny
whether they want to install
this module at this point.
If they confirm that
they want to install,
you come back into
the happy path
and continue downloading
and installation.
At most points that your
installation can be canceled
or in the canceling
state, as well
as for a couple of
reasons, it can fail.
So that's the path
where you have
to handle all those states.
We do have a sample
available for that,
and I'll share URLs for that
later on in this session.
So you can take a
look at how it works.
I talked a little
about file size.
The limit that triggers, for
example, the requires user
confirmation, coincides
with a couple of limits
that we have set
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 on device
has a file size that's
larger than the
limit, then that's
all right, because we take the
download size into account.
So you get some
compression over the wire.
And that's what we take
into account for that.
And this will be shown in
the Play Console as well.
So you'll see your download
size will say you're
above or below the threshold.
Also, dynamic
feature modules don't
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, which you can have,
then it's your base module
and your largest instant entry
module.
And those currently
under our white list
have to be less
than 10 megabytes.
Dynamic feature modules
that you download later on
or other instant entry
modules that are smaller
don't fall into these 10
megabytes in the first place.
But let me tell you a little
bit about what this entails.
So if your app is larger
than 10 megabytes,
well, you don't get any of
the Instant App benefits.
Your app can't be discoverable
to users as an Instant App.
If your app is less than 10,
but more than four megabytes,
your app can be seen
as an Instant App
and can be used
as an Instant App.
So you can access it through
Try Now on the Play Store.
And also, you can show it in web
banners or share it via URLs.
If your base module and
your Instant Entry module
is less than four
megabytes, then your app
can be discovered
from everywhere.
That means from ads,
from search results.
So for example, if you search
for the Android Dev Summit app,
you will see a
search result. If you
click that, you will go
straight to the Instant
App on your Android device.
That's because it's under
this 4 megabyte threshold.
And while you're at it, you
can continue modularizing.
I know modularizing
is a tricky topic,
because it entails some work
that some people are not
100% certain how
that is done best.
We recently went through the
whole process with a project.
It's called Plaid.
It's online.
It's available on GitHub.
And I'll talk a
little bit about how
we managed to move away from a
monolithic app to an app that
uses app bundles and
dynamic feature modules.
While it's not currently
an Instant App,
it, due to a unified approach,
uses the same technology
underneath that you can use
for modularizing an Instant
App as well.
So firstly, what we did is--
what most apps will do is we
created a base module, which
hosts all the domain code and
data, so shared preferences,
log in, for example,
some of the repositories,
some persistent API calls,
and things like that.
And on top of that are
different feature modules.
Those feature modules have
their own domain code,
their own logic, and
obviously, the UI,
which is only displayed
in this module.
That setup can be
used for many apps
if you have a base module
which shares information,
and on top of that, the
different feature modules.
But let me share a little bit
more in-depth what we did.
So initially, we had an
app, which is the module
that most people have.
So we had this monolith.
And if we shipped
as an APK, that's
fine, because, well,
there is no reason
to go into the whole
modularization part if we then,
in the end, have one
single, monolithic app
APK that we ship to our users.
But since we were considering
going towards dynamic feature
modules and app bundles,
we moved everything
into a base, which,
on one hand, had
the shared dependencies, which
basically means everything
that we include coming
from whatever repositories
externally, as well as a couple
of local third-party APIs
in libraries that we have
[INAUDIBLE] and worked with.
After we had this, we
started working on features
that we extracted
from the app itself.
The first that we started
with was an about screen.
Because, well, an
about screen is
kind of untangled
from most of the stuff
that we have within the app.
So it's a good starting point
for getting our hands wet with,
what does it actually entail to
make a dynamic feature module?
How do we do all those things?
Then we went on to
do a search screen.
And after that, we
have two new sources
that we extracted into dynamic
feature modules as well.
And they all depend on
the app, and 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 Developers'
"Medium" blog publication.
Also, we do have information
available on Instant Apps,
in general, and on
App Bundle, as well
as samples on Android
dynamic features,
as well as how to use
Instant App without URLs.
The Android Instant Apps team
is outside at the office hours
to share information
and knowledge.
If you have questions,
please come over there.
And with that,
thank you very much.
[APPLAUSE]
[MUSIC PLAYING]
