Register for this year’s #ChromeDevSummit happening on Nov. 11-12 in San Francisco to learn about the latest features and tools coming to the Web. Request an invite on the Chrome Dev Summit 2019 website

There are a few things that make Trusted Web Activities different from other
ways to integrate web content with your app:

Content in a Trusted Web activity is trusted -- the app and the site it
opens are expected to come from the same developer. (This is verified using
Digital Asset Links.)

Trusted Web activities come from the web: they're rendered by the user's
browser, in exactly the same way as a user would see it in their browser
except they are run fullscreen. Web content should be accessible and useful
in the browser first.

Browsers are also updated independent of Android and your app -- Chrome, for
example, is available back to Android Jelly Bean. That saves on APK size and
ensures you can use a modern web runtime. (Note that since Lollipop, WebView
has also been updated independent of Android, but there are a significant
number of
pre-Lollipop Android users.)

The host app doesn't have direct access to web content in a Trusted Web
activity or any other kind of web state, like cookies and localStorage.
Nevertheless, you can coordinate with the web content by passing data to and
from the page in URLs (e.g. through query parameters, custom HTTP headers,
and intent URIs.)

Transitions between web and native content are between activities. Each
activity (i.e. screen) of your app is either completely provided by the web,
or by an Android activity

To make it easier to test, there are currently no qualifications for content
opened in the preview of Trusted Web activities. You can expect, however, that
Trusted Web activities will need to meet the same
Add to Home Screen
requirements. You can audit your site for these requirements using the
Lighthouse "user can be prompted to Add to Home
screen" audit.

Today, if the user's version of Chrome doesn't support Trusted Web activities,
Chrome will fall back to a simple toolbar using a Custom Tab. It
is also possible for other browsers to implement the same protocol that Trusted
Web activities use. While the host app has the final say on what browser gets
opened, we recommend the same policy as for Custom Tabs: use the user's default
browser, so long as that browser provides the required capabilities.

Getting started

Setting up a Trusted Web Activity (TWA) doesn’t require developers to author
Java code, but Android Studio is
required. This guide was created using Android Studio 3.3. Check the docs on
how to install it.

Create a Trusted Web Activity Project

When using Trusted Web Activities, the project must target API 16 or higher.

Note: This section will guide you on setting up a new project on Android
Studio. If you are already familiar with the tool feel free to skip to the
Getting the TWA Library section.

Open Android Studio and click on Start a new Android Studio project.

Android Studio will prompt to choose an Activity type. Since TWAs use an
Activity provided by support library, choose Add No Activity and click
Next.

Next step, the wizard will prompt for configurations for the project. Here's a
short description of each field:

Name: The name that will be used for your application on the
Android Launcher.

Package Name: An unique identifier for Android Applications on the
Play Store and on Android devices. Check the
documentation
for more information on requirements and best practices for creating package
names for Android apps.

Save location: Where Android Studio will create the project in the file
system.

Language: The project doesn't require writing any Java or Kotlin code.
Select Java, as the default.

Leave the remaining checkboxes unchecked, as we will not be using Instant Apps
or AndroidX artifacts, and click Finish.

Get the TWA Support Library

To setup the TWA library in the project you will need to edit a couple of
files. Look for the Gradle Scripts section in the Project Navigator. Both
files are called build.gradle, which may be a bit confusing, but the
descriptions in parenthesis help identifying the correct one.

The first file is the Project level build.gradle. Look for the one with
your project name next to it.

Add the Jitpack configuration (in bold below) to the
list of repositories. Under the allprojects section:

The tags added to the XML are standard
Android App Manifest.
There are two relevant pieces of information for the context of Trusted Web
Activities:

The meta-data tag tells the TWA Activity which URL it should open. Change
the android:value attribute with the URL of the PWA you want to open. In
this example, it is https://airhorner.com.

The secondintent-filter tag allows the TWA to intercept Android
Intents that open https://airhorner.com. The android:host attribute
inside the data tag must point to the domain being opened by the TWA.

Note: When running the project at this stage, the URL Bar from Custom Tabs will
still show on the top of the screen. This is not a bug.

The next section will show how to setup
Digital AssetLinks
to verify relationship between the website and the app, and remove the URL bar.

Remove the URL bar

Trusted Web Activities require an association between the Android application
and the website to be established to remove the URL bar.

Close Chrome and re-launch your application from Android Studio. The
application should now be shown in full-screen.

Note: It may needed to force close Chrome so it restarts with the correct
command line. Go to Android Settings > Apps & notifications > Chrome,
and click on Force stop.

Establish an association from the website to the app

There are 2 pieces of information that the developer needs to collect from the
app in order to create the association:

Package Name: The first information is the package name for the app. This
is the same package name generated when creating the app. It can also be found
inside the Modulebuild.gradle, under
Gradle Scripts > build.gradle (Module: app), and is the value of the
applicationId attribute.

SHA-256 Fingerprint: Android applications must be signed in order to be
uploaded to the Play Store. The same signature is used to establish the
connection between the website and the app through the SHA-256 fingerprint of
the upload key.

With both pieces of information at hand, head over to the assetlinks
generator,
fill-in the fields and hit Generate Statement. Copy the generated statement
and serve it from your domain, from the URL /.well-known/assetlinks.json.

Note: The AssetLinks file must be under /.well-known/assetlinks.json, at the
root of the domain, as that's only the place Chrome will look for it.

Creating an Icon

When Android Studio creates a new project, it will come with a default Icon.
As a developer, you will want to create your own icon and differentiate your
application from others on the Android Launcher.

Android Studio contains the Image Asset Studio,
which provides the tools necessary to create the correct icons, for every
resolution and shape your application needs.

Inside Android Studio, navigate to File > New > Image Asset, select
Launcher Icons (Adaptative and Legacy) and follow the steps from the Wizard.
to create a custom icon for the application.

Generating a signed APK

With the assetlinks file in place in your domain and the asset_statements tag
configured in the Android application, the next step is generating a signed app.
Again, the steps for this are widely
documented.

The output APK can be installed into a test device, using adb:

adb install app-release.apk

If the verification step fails it is possible to check for error
messages using the Android Debug Bridge, from your OS’s terminal and with the
test device connected.

Generating the images for the Splash Screen

Android devices can have different screen sizes
and pixel densities.
To ensure the Splash Screen looks good on all devices, you will need to generate
the image for each pixel density.

A full explanation of display-independent pixels (dp or dip)
is beyond the scope of this article, but one example would be to create an image that
is 320x320dp, which represents a square of 2x2 inches on a device screen of any density
and is equivalent to 320x320 pixels at the mdpi density.

From there we can derive the sizes needed for other pixel densities. Below is a list
with the pixel densities, the multiplier applied to the base size (320x320dp), the
resulting size in pixels and the location where the image should be added in the
Android Studio project.

Density

Multiplier

Size

Project Location

mdpi (baseline)

1.0x

320x320 px

/res/drawable-mdpi/

ldpi

0.75x

240x240 px

/res/drawable-ldpi/

hdpi

1.5x

480x480 px

/res/drawable-hdpi/

xhdpi

2.0x

640x640 px

/res/drawable-xhdpi/

xxhdpi

3.0x

960x960 px

/res/drawable-xxhdpi/

xxxhdpi

4.0x

1280x1280 px

/res/drawable-xxxhdpi/

Note: An alternative to creating all the images sizes is to use one Vector Drawable.
The Vector Asset Studio
offers tools to help developers to transform SVGs into Android Vector Drawables.

Updating the application

With the images for the splash screen generated, it's time to add the necessary
configurations to the project.