[MUSIC PLAYING]
WOJTEK KALICINSKI: So far in this series,
we've looked at the changes to the app signing
process that Play App Signing brings,
as well as the benefits of releasing your app as an app
bundle, and Google Play's advanced delivery
options for modular apps.
But many of us, or the development teams
that we work with, have built up a lot of existing knowledge,
processes, and tools around regular old APKs
based on assumptions that no longer hold true
in a modern Android development world,
such as that one APK fits all devices,
and that it can be sent in an email
or put on a server for testers to download and use.
APKs, as the installation format,
are not going away any time soon.
But with signing on Play's servers
and generating optimized sets of APKs from app bundles,
you need to adapt and understand the tools available to you
to maximize both the quality of your testing,
as well as your productivity during development.
Let me walk you through some of the tools
that you should be using when handling Android App
Bundles, as well as a few tricks in the Play Console
that will make your life a lot easier.
Let's start with some basics when you're developing your app
locally in Android Studio.
By default, when you press Run, the app will be built as an APK
and transferred to a connected device or emulator.
This is all fine when you want to have the quickest iteration
times when developing.
But at some point, you might want
to start testing how your app behaves
the way it's going to be distributed when using an app
bundle.
In order to do that, go into Edit Configurations,
then change the Deploy mode to APK from app bundle.
By default, all your feature modules
will be deployed when you click the Run button.
If any of your modules are configured for other delivery
modes than install time, you might
want to check how your app behaves
without that module installed.
One thing to note here is that with your app deployed
using these settings, you will not
be able to use the runtime Play Core API
to install the missing modules, at least
as of the current Android Studio version which I'm using,
and that's 4.2.
If you want to test how your Play Feature Delivery or Play
Asset Delivery installation flow works locally,
without uploading the app to the Play Console,
it's possible with bundletool.
You can download the newest version of bundletool
on GitHub, then run it on the command line.
Normally, if I wanted to deploy an app using bundletool,
I can run two commands.
First, build-apks to build an APK set for my bundle.
It will contain all the APKs for all modules in my project.
The build-apks command optionally
takes a --local-testing argument,
which adds special metadata that will let me test future module
installation locally.
To deploy the app on a connected device,
or in this case, the running emulator,
use the bundletool install-apks command.
It will read the local testing metadata from the previous step
and push all optional modules into the device's
local storage.
Now when I run my app, without any code changes required,
installation of on-demand features
works all locally without connecting to the Play Store.
If you want to try this yourself,
we've added a custom Gradle plugin in our Play Core KTX
sample that adds a new build task
called debugInstallApksForLocalTesting.
All it does is run the two bundletool commands
that I mentioned before, so you don't
have to use bundletool on the command line every time.
This is helpful if you want to quickly iterate on your app
while developing.
But at some point, you will want to test your apps real flow
using APKs served by the Play Store.
I'll show you a few of the ways you can share and install
test versions of your app with your development team.
But first of all, you need to create an app listing
and upload a first version into any of the tracks.
Then wait until it's reviewed, which
can take a few days or even a week, so best do it early.
But remember to upload a version of your app
that follows all Google Play policies.
I recommend starting with the internal testing track
so you can select a small number of people
from your organization who will be able to access it
while developing.
After the initial review, uploading new versions
to the internal testing track is fast,
but it still needs to follow unique version requirements.
If you want even less restrictions and a faster
iteration time, check out the Internal app sharing tab.
Artifacts uploaded to internal app sharing
don't have to follow any version requirements.
It also accepts debuggable APKs and bundles.
Simply configure who can upload and download artifacts here
and start uploading.
You can drag and drop files from your computer on this page,
and for each artifact, you got a URL
in seconds, which you can then share with downloaders.
Internal app sharing is not a regular track,
so testers always get the specific artifact
that the URL is pointing to, and it will not
be updated to any newly uploaded versions.
At the same time, it supports all advanced app bundle
features, such as downloading on-demand feature modules.
Here, I've installed a version of our Play Core KTX sample
from an internal app sharing link.
I can see which APKs have been installed.
And when I open the app and invoke the camera
on-demand feature, it will start downloading from Play.
Once it's installed, I can see it on the internal app sharing
screen on the device.
And if you'd like to test your in-app updates API
implementation, there's another neat trick you can do.
Upload two versions to internal app sharing.
Install the one with the lower version code
first, as I've done already.
Then open the link to an artifact with a higher version
code on the device, but do not click Update just yet.
Instead, go back to the app, and it should now
show the available update.
There's one more way you can use internal app sharing.
In the App bundle explorer, select any of your published
artifacts, including previous versions of your app,
and switch to the Downloads tab.
Here, you can get a direct internal app sharing
link to install that specific version
on a device with Play Store.
It's especially helpful if you want
to investigate a bug in an older version of your app or test
updates to a newer version.
All right.
That was it for my demo.
I think it covers most of the things
that developers need in order to verify and test
how your apps behave on various device configurations,
and when using advanced delivery features,
such as Play Feature Delivery, for accessing modules
dynamically.
I hope that with the improvements
to tooling that we've made, the transition to app bundles
will be smooth for everyone.
But if you think anything is missing,
we'd like to hear from you.
Please let us know on Twitter, tagging me and @AndroidDev
or @AndroidStudio.
Or file a bug or a feature request
in the bug tracker on b.android.com.
Thanks.
[MUSIC PLAYING]