Building an Android Instant App (Google I/O ’17)

good afternoon. Welcome to our session on
building an Android Instant App. I’m Shobana, I’m the engineering
lead for developer experience of Instant Apps. I’ve been on the team
since the very beginning. So I’m very excited
to be here today to bring all of you, our Instant
Apps development experience. So today, I’m going to
talk to you about what Instant Apps are, give you
a quick overview of the user experiences that they enable. I’ll then talk about
a few key principles to keep in mind as you
build your Instant App. I’ll walk you through
the developer experience that we built that you
can expect when you start. And then finally, we’ll work
through a specific example of building an Instant
App from an existing app. Sounds good? Let’s get started. So what are Instant Apps? Instant Apps are Android apps
that run without installation. They provide users the ability
to have rich native experiences at the tap of a URL. In this example,
our colleague Joyce sent us a URL for the New
York Times crossword puzzle. You tap on the URL,
and it directly brings it up inside the New
York Times crossword app. No installation needed. Now as a result of this,
my product manager John, sends me a URL every
morning with his timings. Unfortunate consequence. Anyway, so– now since Instant
Apps are launched from URLs, they are discoverable
from anywhere that you can put a URL. Whether that’s a chat
session with a friend or link in your search result. Did you know that the
White House was actually listed on Zillow? Now with installable
apps, you’re probably used to users coming
in through your front door. So your launcher activity
or your main activity. But with Instant Apps, you just
can launch into any experience that you have within your app. So that improves the
surface area for discovery. Instant Apps are a mode of your
existing app, not something separate. They allow you to provide
the exact same product experience that you provide in
your current installable app. They share the same package
name, they have the same icon, and they have the
same code bits. So now that you know
what Instant Apps are, and what user
experiences they enable, let’s talk about a
few key principles to keep in mind as you start
building your Instant App. You’ll see examples
of these principles throughout the
rest of this talk, and when you do it yourself. So I’ll cover discoverability,
security, and privacy, and performance. Instant Apps are
launched from URLs. So the first step is to
consider the experiences within your app, and make
them URL addressable. You can do this very easily
with Android App Links. App Links allows you
to associate a domain with your app, and
support specific paths against that domain within
activities in your app. The more of these paths you
support, the more discoverable your app is. Let’s talk about
security and privacy. With installable apps, apps
get access to the user’s device when they go through
an explicit– when the user goes through an
explicit installation flow. At that point, the user is
granting your app access to your device. You also have the ability to
ask the user for permissions to access private
data, like location. Now with Instant Apps, they
just launch from a URL. So there’s no explicit
installation flow, and hence no upfront consent. For Instant Apps to maintain
the same capabilities as installable apps, they
use the runtime permissions API that allows them to get
private data, like location or on-device resources
like the camera. We also provide
user-resettable identifiers for Ad ID and Android ID. But we limit Instant Apps
when querying unique device identifiers, like
IMEI and MAC address. We also limit Instant
Apps from querying what apps are installed
on a user’s device, and listening to
system broadcast. Finally, let’s talk
about performance. Instant apps are loaded
and drawn on demand. So the size of the binary
has a huge impact to the user visible startup latency. The smaller the binary,
the faster it loads, the better the user experience. So it’s very important to have
small lightweight binaries to have a great
Instant App experience. We recommend starting your app
on a very strict diet, zero fat. Take out dead code,
unused resources. Look in your manifest
for unused permissions, and your Gradle file for
unnecessary libraries. Many of our partners
saw a huge improvement in their binary size
with just this stuff. You can then build your
application into modules. Remember, Instant Apps
support multiple entry points. So having modules that support
each of these entry points, allows us to only
load the module that’s needed for a given entry point. With the ability to
load more as the user goes through different
flows within your app. So to quickly summarize,
three key principles to keep in mind while you
build your Instant App. Discoverability with
Android App Links, privacy and security
with the runtime permissions API, and performance
with small modular binaries. Now we worked with
over 50 Early Access partners, who really helped
us just define our developer experience. Their level of engagement and
their extremely valuable input is reflected in the quality of
all components of our developer experience. I’ll walk you through
a few of these. I’ll cover development tools,
some new constructs that we’ve introduced, the project
structure, as well as the publishing interface. Many of you develop
apps in Android Studio. Android Studio 3.0 comes
with Instant App support out of the box. You can install the Instant
Apps SDK through SDK manager. And then you can build, run,
test, and debug Instant Apps directly from the IDE. You can also easily add URL
entry points with the App Links Assistant that’s built
directly in Android Studio. Apart from on-device
support, we’ve also enabled emulator
support for you to do fast and easy
local development. We’ve introduced a new construct
called the feature module. The feature module is
very similar to a library module in that it contains
code resources and a manifest. But feature modules build as
APKs for your Instant App. Our Gradle plugin
will automatically build them as libraries
for your installable app. So you can use the
exact same code base. Now Instant Apps are built
across multiple features. So we’ve also
introduced a Instant App module that builds the container
to hold your feature APKs. This is a zip file. Now, installable apps are built
as a single binary, the APK. So the project structure can
be done in a variety of ways. Many of us have worked on
apps that started small, and then it ended up being
large, monolithic code bases under a single module. I’ve always dreamed of the
perfect modular structure. And sometimes I’ve
done the work, but there’s limited benefit
to the actual binary size. Now with Instant Apps, we need
to load binaries on demand. This is where our
feature module comes in. It allows you to extract
out specific features into their own modules. So you can set up your project
to take the common code from your existing
application module, and put it in a
base feature module. The base module
is always loaded. And then you can extract
out specific features into their own modules. That way, for a
given entry point, we only load the base module
and the corresponding feature module. As the user goes
through different flows within your app, we just load
more of the feature modules within the same
application context. So now, you can have
a project structure that builds both your Instant
App and your installable app directly from within a
single Studio project. Finally, when your
Instant App is ready, you can use the Google Play
console for publishing. We’ve been enabled 3
publishing tracks– development, pre-release,
and production– for you to roll out your Instant
App in a phased manner. So to quickly summarize
our developer experience, you can set up Android Studio
3.0 with the Instant Apps SDK. You can then introduce
feature modules, and refactor your app
into these feature modules such that we have a feature
module for each entry point. You can create a
project structure that allows you to
build both your Instant App and your installable app
off the same Studio project. And finally, when
your app is ready, you can publish to the
Google Play console. So let’s get our hands
dirty, and try this out. At this time, I’d like to invite
on stage, Anirudh Deawani. Anirudh is our lead developer
advocate for Instant Apps, and has worked with
many of our partners to enable their Instant
Apps experience. Welcome, Anirudh. ANIRUDH DEAWANI:
Thank you, Shobana. [APPLAUSE] SHOBANA RAVI: Next
slide, please. Still with the slides. Still with the slides. Can we switch back
to the slides? Sorry, so Anirudh has
an app called Banjara. Banjara is a Hindi
word for nomad. The Banjara app is a
tourist attractions app that gives you a list of
attractions around you. And for any given attraction,
it gives you details. Now the Banjara app is
structured this way. It has a top-level application
module with two activities– one for the attractions list,
and one for the details. Each of these activities
has their own fragments. There’s some common code,
such as integration Glide, Maps, some utilities. The app also uses the runtime
permissions API for location. Now, today we’ll work on
making Banjara Instant. So the first thing
to consider is what are the URL entry points
into Banjara that makes sense? We have two entry points, one
the list, and one the details. We want to make both
of them discoverable. So we’d add two
URL entry points. One for the attraction’s
list, and one for the details. We’ll then refactor the
existing application code into two feature modules. The base feature module would
contain the attraction’s list and the common code. And the details feature
module would then have the details experience. Remember, the base
module is always loaded. And so the details
feature module only needs to have
the additional code. So this is our target
project structure. We’ll get to it in three steps. Step one, we’ll introduce
URL entry points into our application. We’ll do this with the
App Links Assistant. Step two, we’ll take our
existing application module, and make it a single
base feature module. All the code is encapsulated
within the feature module. We can then introduce an Instant
App module and an application module to build off this
base feature module. At this point, we’ll have our
first functional Instant App. Then step three, we’ll extract
out the details experience from the base future module,
and make it it’s own module. So we’ve reach our
target project structure in three steps. Let’s try this out. Step one, Anirudh,
if we’re ready, can you show us our
project structure? And then walk us
through this step. ANIRUDH DEAWANI: Absolutely. So before we begin, let’s make
sure we have the Instant App Development SDK installed. So I have the SDK manager open. And here you see, the
development SDK is installed. Just going to click OK. All right, so now
let’s just set up URL entry points for our app. This is done by adding intent
filters to your manifest. To help us with
the process, we are going to use the Android
App Links Assistant tool. And there, it opens as
a panel on the right, and will guide us
for the process of creating our entry points. The first thing we want
to do is map some URLs to our activities. So let’s set up some mappings. So I’m going to use as my host. And then setup main part from
my attractions list activity. I’ll repeat the step for HTTPS. All right, now that we
have the main part set up, we also will now set up the
part for our details activity. So again, the same host. I use details, and
choose details activity from the drop down box. And then again, repeat
the same step for HTTPS. And there, we have
our mapping set now. There’s a Preview
window here, which shows the manifest and
the changes that we just did using the mapping editor. All right, so the next
step is then to add logic to handle our intent. This is already done, because
we are using existing code. The next step is to create
a digital access link file. And then associate our
website with our app package. So I’m going to
bring up the tool. A couple of details, here. You enter your site domain,
you enter your application ID, and then you choose
your sign-in key. Now, I’m going to
use the debug key. But when you
productionize your app, you’ll choose your
release key, here. I’ll now click on Digital– to generate my digital
access link file. Now this file basically
tells us that our app is now mapped to our domain. This is very important to
claim ownership of your URLs. This file now needs to be
uploaded to a specific location on your server. The location is here. Once you are done
uploading the file, we’ll click link and verify. And this will make the
association between your app and the domain. All right, back to you, Shobana. SHOBANA RAVI: OK. So we’re done with step one. And we now have two experiences
within our app discoverable through URLs. Let’s move on to step two. We’ll now take our existing
application module, and then put it in a
base feature module. So we’d have to rename our
application to be a feature. We’ll also change the Gradle
file to not be com Android– com.Android.application and
make it com.Android.feature. Now, since all the code will
be within the feature module, we can now introduce
an application module and an Instant App module to
build off the same feature module. Each of them don’t need any code
because they’re building off the existing model. Let’s try that. ANIRUDH DEAWANI: Sure. So as you can see,
on the left side, my project currently
has one module. That’s the Banjara-base, and
this is an application model. So what we are now trying
to do is convert this into a feature model so
all our code and resources are in this feature. And then create two
new top-level modules, an application model
and an instant module. And then we’ll
include the feature as a dependency
for those modules. So I have my build Gradle file
for my Banjara base module open. It currently says
com.Android.application. I’m going to change this
to com.Android.feature, this is the new plugin. Now, all modular apps
using the feature plugin are organized around
the single base module. Now, since this is
our only module, we’ll tell the Gradle build to’s
that this is our base module. We are going to do this by
setting the base feature property. All right, now that we have
our base module, we’ll create– let’s first create the
application module. So I’ll select New Module. Choose Phone and Tablet. And let’s call this Banjara App. I’m just going to
choose a package name that’s consistent
with my other modules. And I’ll select Add No
Activity, because for now all our activities and all our
code is in the feature module. All right, the module
is now created. I’ll remove the path sources
and resources for now. And then, in my
application manifest file, I’ll remove the application
tag, because this is going to get merged
from our feature module. So now, let’s look at the Gradle
file for our newly created application module. So the first thing I will do
is use the same compile SDK and build to version that I’m
using in my feature module. Then remove the
test dependencies. And now, we want to
include our feature module in our application module. So right, now we have the
feature module included. There’s one final
thing we need to do. So let’s head over to our
base build Gradle file again. Now the base module is
a very important module. The Gradle build to’s
look into the base model to figure out all
of the features and the application
in your project. So we need to make our base
model aware of our application model. This will help with the
manifest merging process, and will pull up the application
ID to package the Instant App. So this is done by using the
application configuration. All right, this is synced now. Let’s try to compile. I already have an emulator
running, and let’s see, we got a little error here. I’ll clean the project. All right, the build
is not successful. So I have an emulator,
here, running M. So let’s try to run our app,
which is now using a feature module, which produces a feature
APK, which produces a library file for our app. So I’d select the app
configuration, and then run. There, our app is now running. It uses runtime
permissions for location. And this is our list activity
for a list of attractions. I’ll bring up one of the details
for one of the attractions, here. All right, so now this
is an installed app, because we used com.Drive
Android.application. So I’ll uninstall this app. And we’ll now build
an Instant App. So to do that, I will
create a new module and choose Instant App. Let’s call this
Banjara-InstantApp. The module is created. As you can see, on the left
from the project structure, this is a very
lightweight module. There is no source,
there are no resources. It just has a
build.Gradle file and it’s going to build just a container
zip for our feature APKs. So using the same compile
and build tools as version. And now, just as we did
for our application model, I will include the feature
model as a dependency. Now, let’s try to
build our Instant App. All right, the
compilation is successful. Now, before, we
run this app, let’s take a look at our run
configuration for the Instant App. A habit here, as you can see
in the launch options here. Instead of using an activity,
this is now using a URL. So let’s switch it to
the main, which maps to our list of attractions. Apply. OK. And now, let’s run
our first Instant App. So this may take some
time for the first time, when you try to run this. Because it’s now
setting up our device, it’s setting up our emulator
for running Instant Apps. Now our Instant App is running. It uses the same runtime
permission model, we didn’t make any
changes to the code yet. We have a list of attractions. And then I bring
up an attraction from the details activity. So before I give it back to– [APPLAUSE] Thank you. Before I hand it over
back to Shobana, let’s quickly look at
our build artifact from the Instant App project. So here, as you can
see, this is a zip file. I’m going to use the APK
analyser to inspect the zip file. In the zip file, you can
see, I have one feature APK. It’s our base APK. I can look down, and then drill
down and look at my resource usage using the APK analyzer. All right, back to you, Shobana. SHOBANA RAVI: Great. So we have our first
functional Instant App. 10 minutes. So now, let’s move
on to step three. We’re going to extract
out the details experience into it’s own feature module. We’re doing this by introducing
a new feature module, and just refactoring out
of our existing base module into that feature module. We’ll then have to
update the application module and the
Instant App module to now build from
two feature modules. So Anirudh can show
us how to do that. ANIRUDH DEAWANI: OK, let’s
review our project structure. Right now, we have three models. Which is one is a feature
module, Banjar base. And then one application model. And then Instant App module
to wrap the feature model. So let’s create a
new feature model and defactor some code
from our base model. So I now use the new
feature model template. And call this Banjara details. Following the same
project structure, and the package naming scheme. Now remember, feature modules
are built just like libraries. So they need to have a
different package name, it cannot be the same as
your application name. Again, no activity to add. We’ll refactor
existing activities. All right, our details
model is now ready. Let’s look at the
build Gradle file. So it automatically applied the
plug-in com.Android.feature. Let’s switch to the build to’s. Now, when we
created this module, Android Studio automatically
added a dependency. It says a dependency
to Banjara base. Remember what we said about
modules there, the base module. That all the feature
models are organized around the single
base module, and they need to extend the base module. So because we already
have a base model, Studio automatically applied the
dependency to our base module. And let’s take a look at
our Gralde file for our base module. Now you remember, we added
the application configuration, here, to tell our base
module about our app. So it needs to pull
down the package ID. When we created the
new details module, Android Studio also added
a feature configuration, which tells our base module
about the other feature models in our project structure. This is very important
for manifest merging and the build process. All right, so now we have
two feature models created. But we need to go back to our
application and Instant App and include the new details
module in the build. I’m in my application right now. I’ll add the details
module, here. And then the same
for my Instant App. All right, now that all the
dependencies have been set up, let’s actually refactor some
code into the details module. So before we begin, I’ll
create a package, where I need to place the new classes. I’ll use the package
name UI, this is where our classes
are in the base module. OK, I’m going to remove
the path sources, again. All right, now let’s actually
go and get our classes that we need to refactor. So we’ll move the details
activity and the details fragment into the new module. All right, the new classes,
the details classes, are now on our details module. We also need to move
the activity declaration from the manifest file
of the base module, where the classes
were previously. And bring that, the
activity was previously, and then bring that
to our feature module. So this is my details activity. Let’s add it to our manifest
file for our details module. We’ll just create
an application tag to put the activities under it. And there, let’s now
compile the project. All right, project compiled. Now before we run this,
let’s quickly inspect the container file again. In my Banjara
Instant App module, it’ll go to build outputs,
and my zip file is here. Now, when I inspect
this using APK analyzer, I see now two feature APKs– my base feature APK and
my details feature APK. Now lets use our Instant App
run configuration to run this. And my app with two
feature APKs is running. [APPLAUSE] Thank you. I’ll bring up an attraction. Now this attraction
details, were loaded from a different APK. And before I hand
it over to Shobana, I just want to show you
in the launcher, here, we don’t have the Banjara
app installed anymore, because we were running
it as an Instant App. But if we head over
to the recents, we can see our
Banjara app running. All right, back to you Shobana. SHOBANA RAVI: Thank you. [APPLAUSE] Thank you. So just to quickly
summarize, how did we make Banjara Instant. We enabled URL entry
points into our app. We then created a base feature
module with existing code. And we extracted features
out of the base module into their own feature module. At the end, we had a
single Studio project that you could build
both the Instant App and the installable app. Now, this was a
simple sample app. It’s likely that you’ll take a
little longer than 15 minutes to make your own Instant App
for a real world application. We’ve heard from
many of our partners as to how long it took. And we found that it’s typical
to take four to six weeks to build your Instant App. You’ll spend the first
part of that thinking through the product
experience that you want to build in your Instant App. Then identify the target
project structure that’s perfect for your application. And then there’s the
refactoring effort to put code inside your
base feature module, as well as into other
feature modules. And then you’ll spend
some time trimming down each of these modules to be
light and small size so they can be downloaded
and run on the fly. We have 50 Instant
Apps live today. I see a few of our Early
Access partners over here. Thank you and congratulations. But we believe this
is just the beginning. We’re very excited to see
what Instant Apps experiences you will build. But we’re not done yet. In the coming weeks and months,
you’ll see huge improvements to the developer experience. We’re focused on
features that can enable additional
binary size reduction. That includes allowing
your app to be sliced along device
configurations, display densities. Allowing commonly used
libraries like app compact to be shared between
Instant Apps. And on the
compression techniques to reduce over the air
binary transmission. On the tooling side, we’re
introducing a new factoring tool that will make it really
easy for you to modularize your code into features. Additionally, we’re
expanding Instant Apps to more devices
and more countries to make sure your reach
reaches all of Android. Here’s some resources
for you to get started. Our Instant Apps
web site has a lot of information around product. But especially, it has a
Getting Started guide for you to walk through the developer
experience by yourself. We’re also in the
Instant Apps sandbox under Dome C, where
you can come by and see some demos of our Early Access
partners and their Instant Apps experience. Immediately after
this talk, we’re going to have a fireside chat
with some of our Early Access partners so you can
hear from them what their experiences were
developing Instant Apps, and what benefits it’s
brought to their applications. We hope this talk was useful in
jump starting your Instant App development. Thank you so much
for being here. [APPLAUSE] [MUSIC PLAYING]

Leave a Reply

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