Trusted Web Activities


PETE LEPAGE: Having an app
available on the app store is critical for many businesses. We know that there are some
use cases where it makes sense to integrate your
existing web experience into your native app. I’m Pete, a developer advocate
on the web team at Google. Let’s take a look at how
you can do this today and what we’re doing to
make your web development experience better. Today, you can do this either
using WebView or a custom tab. While each of these
has their own benefits, there are also
drawbacks to each. With WebView, the
content runs full screen and supports many
of the PWA features. It has the ability to use
postMessage to send messages back and forth between the
WebView and your native code, which makes it
possible to invoke certain native
functionality that isn’t available on the web. On the flip side, WebViews
are sandboxed completely from the user. They don’t share the same
cookie store or storage, and they don’t have access
to the user-saved passwords and so on. The other challenge
that comes up is that WebViews
may be out of date. WebViews on devices running
pre-Lollipop aren’t updatable. Custom Tabs also support
content in full screen mode, and because they’re powered
by the user’s default browser, they share cookies, storage,
passwords, and more. It’s always up to date and
supports the full gamut of capabilities required
for progressive web apps, but there is that name and
address bar across the top. The user knows that they’re
looking at web content, which isn’t always what you want. We’ve heard from you
that you want an easier way to launch a full screen
web content from a native app but do it using the
user’s preferred browser. At the Chrome Dev
Summit last year, we announced a new
type of activity that Android developers
can use to embed trusted first-party web content. Trusted Web Activities
provide a new way to integrate parts of
your web experience into your native Android app. They’re powered by
Custom Tabs, which means the content is rendered
by the users up-to-date browser instead of an
out-of-date WebView. It shares the same cookies and
storage within the browser, and it has access to APIs that
aren’t available in WebViews. This isn’t designed
as a mechanism to simply wrap your site and
dump it in the Play Store. A simple mistake can cause
some drastic problems. For example, the user installs
your app from the store, hops on a plane, and
launches your app. The user’s going
to see the dinosaur because the app hasn’t installed
the service worker yet. Trusted web activities
are designed to make it possible for you to
use the investment that you’ve made in your Progressive Web
App within your Android app. Similar to Chrome Custom
Tabs, Trusted Web activities run full screen. Each activity of
your app is either completely provided by the
web or an Android activity. There’s no way to combine them. For example, you can’t
use Android components for navigation and content
rendering via the Trusted Web activity. Transitions between
web and native content are between activities. Trusted Web Activities
do have some constraints. You can’t just show any content. It must be yours,
and you must be able to prove that it’s yours
by adding a set of digital asset links. You must include
an intent filter for the open URL in
your Android manifest. Your app must pass the Chrome
PWA installability checks, which includes being
served over HTTPS, registering a service worker,
and including a manifest. And very important,
your app must still meet all of the normal
Play Store guidelines. Let’s take a look
at what’s involved in adding a Trusted Web
Activity to your Android app. There are essentially
two steps that we need to complete to
embed a Progressive Web App in our Android app. First, we need to add a
set of digital asset links. These links establish
a relationship between our web content and
the Trusted Web Activity. By establishing
this relationship, our Android app can verify that
the content is served, is ours, and meets that first
party requirement. Then we can add the
activity to our Android app and show our web content. In our Android
manifest file, we need to tell it about
an asset statement by adding this
metadata attribute. Next we need to update the
strings.xml file in our Android app, and tell it about our
web content where it lives, and give it the
permission that it needs. Oh yeah, and all those
quotes there, sorry, they do need to be
escaped like that. Now we need to create and deploy
the assets link JSON file. Using keytool on the
certificate that we used to sign our
Android app, we’ll get the SHA256 hash, so that
later Android can verify the certificate and that hash. Then in the asset links JSON
file, we’ll include that hash, our package name, and a few
other boilerplate pieces, and deploy it to the
.well-known directory. The file makes it
possible for Android to verify the relationship
between what’s being served and our Android app. We’ve set up the digital
asset links we need. Now we can create the activity. There’s a bunch of
boilerplate code required to launch the activity that
I’ve kind of glossed over here. But we’re working on adding that
to the Android Support Library, so that you won’t have to
deal with it in the future. Once the boiler
stuff is complete, you can create the new
intent, set the URL, and open the web content in
your Trusted Web Activity. Today, this is available on
Android and Chrome 68, which is currently Chrome
Dev, and we hope to see it land in stable
sometime in Q3 of 2018. To learn more, check out
g.co/TrustedWebactivities. There’s a great post
there with everything you need to know to get
started and a sample that you can use to try it yourself. Thanks for watching.

Danny Hutson

Leave a Reply

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