 Hello, I'm Andrei, a developer advocate at Google, and I help developers to create great experiences on the web and Android with trusted web activities. And I'm Peter. I'm a product manager with the Chrome web platform. And I work on the web and operating system integration, so things like trusted web activities. I'd like to thank you all for joining us today. I know you're probably tired after two days of pretty mind-blowing sessions. So you've all been through these kinds of engagement exercises before. My job is to get you through one more session today. I keep you awake. So I'd like to find out a little bit about who we have in the room today. So if we could begin just if you develop for Android primarily, would you stand up for me? A couple, a few? Yep. Yeah, there's a few of you here. Awesome. Thank you. You can sit down. If you develop for the web primarily, could you stand up please? Thank you very much. OK. You can sit down. Now, if we want to get a little more athletic, if you develop for both, do I handstand? No, OK. How about we just raise both hands if you develop both for Android and web? Quite a few. Is there anyone here who doesn't develop for Android or the web? There's one. Well, I hope that we keep you entertained today. So we're here today because the web is awesome and Android is awesome. And the web on Android is, I think, well, you're getting the idea. But we may have heard feedback from our community that there's something that could do make the web and Android a little bit more awesome. So the question is, what exactly could that be? The web on Android is really nothing new. I mean, using the web has been an important part of an Android developer's toolbox almost since the beginning of Android. And this has been in the form of WebView. And there are major media companies, Twitter, LinkedIn, Instagram. They're using web technologies for important parts of their Android apps. And the problem with WebView is, though, that it's not as fast as Chrome. And it's basically a rendering engine. So if you need anything that isn't included in it, you've got quite a lot of work to do. There's quite a lot of development. You basically have to build an entire browser around it if you want more sophisticated behavior. So it turns out that that is actually a lot of work and it's pretty hard. And I know a lot of you in the room are engineers. So we all appreciate hard problems. We like solving hard problems. But solving hard problems that other people have already solved is probably not the most exciting thing that you could be doing with your time. So that's what Trusted Web Activities are here for. It's here to offer you a building block for your Android apps that's the best of all worlds. You can use the web for what it's great at in your Android experiences. And you get the performance APIs and the assistive features of the Chrome browser. And you don't have to reinvent the wheel. Basically, a Trusted Web Activity is faster than a WebView. It's feature-complete. And it's evergreen, which means that it's always up to date with the latest version of Chrome, the version of Chrome that's installed on the device, which auto-updates. Basically, if you're showing first-party web content in your Android app, you should be using a TWA. So when I went through the rehearsal this session, my coach told me, make sure that the audience leaves with the takeaway. So I'm going to give you the takeaway now. And I'm going to come back to it at the end. The takeaway is, if you're including first-party web content in your Android app, you should seriously consider using a TWA. Let's talk a little bit about the kinds of things that you can use a Trusted Web Activity for. Well, pretty much anywhere that you're using a full-screen WebView today, there are all kinds of reasons why you might not have APIs in your back end. I come from an e-commerce background. And checkouts, if you've worked on them, you may know that they are a lot more complicated than they might look at first blush. There's things like shipping. There's things like taxes. And a lot of this third-party plug-in ecosystem, that means that APIs often won't work for you in this stage. So it's pretty common to have this part of a journey be done using a WebView on the web. TWA would be a great fit for this kind of use case. Some organizations start new journeys inside of their apps using the web. And that way, they can use WebAB testing tools. They don't need to redeploy changes through the app store. And this is just a great part of the way that they develop for Android. So again, TWA is a great fit for this use case. And finally, big surprise, it turns out that the web is pretty good at documents. So things like FAQs, contact forms, these are routinely web views today in apps. And the TWA is a great substitute for WebView in these cases as well. So let's get into some of the details about what exactly is different about a trusted web activity. And I know that some of you are focused only on the web. So I'm going to start with the basics here. If you're new to Android development, you might wonder, what's an activity? In fact, you might have seen TWA and thought, surely that acronym has something to do with a PWA. And it kind of does, but only incidentally. We'll get to that a little bit later. An activity, a complete review of an Android activity is really much too large of a topic for me to cover inside of the scope of this talk. But the good news is that you actually don't really need to know very much about them as a web developer in order to get started. So this is something where probably just a very short amount of time will get you everything that you need to know about instantiating a trusted web activity so that you can play around with them. And Andre will get a little bit more into those details later. You could think of an Android app as a shell or container for activities. And an activity is Android's version of a window inside of the app. And that's where the exciting user-facing stuff is happening. And it contains views that render UI in the native app. And of course, all the code that glues user interactions to things that are happening inside of the app. Since the TWA is a web activity, you're going to be doing all of that drawing and user logic inside of your web code. The TWA is the Chrome browser with no browser UI. It loads your web app from a URL that you specify when you initialize the TWA. So I'm going to be using this word full screen about to describe TWA's throughout the talk. So I'm going to take just a moment and explain to you what it is that I mean when I say that a TWA is a full screen activity. I mean that the web content area is going to fill the entire screen of the app except for the system UI. Full screen also means that you can't mix web content with other native controls. So for example, you can't draw a native toolbar on the bottom of the screen like I'm showing in this example. Now let's talk about this trusted part. A TWA is trusted because it's going to cryptographically verify that the app owner is the content owner. And that way, a user can be sure that what they've installed from the Play Store is owned by the same person who owns the web content that's being displayed. This last point is a really important one. I've already told you that a TWA is just Chrome without any UI. That also means that data is being shared between Chrome and the TWA because the TWA is Chrome. So let's say, for example, a user has visited your website. They've signed in and they have a session state. If they later go through the Play Store, they install your app and you're using a trusted web activity in your app, that trusted web activity is going to know about the session that's happened in the Chrome browser. It'll be just as if they opened a new tab and browse to a URL on your site, in fact. So that works the other way around, too. Let's say they modify something about their session state. If they're in an e-commerce journey, for example, they added something to their cart, that's going to show up when they go back to the browser and navigate to the next page. They're going to see that change in their cart. So this is something that has a lot of advantages. It can really simplify life for the user around sign-in. But it's something that you should be aware of in the design of your applications. Now, to let users know that this is happening, you're going to see a little infobar at the bottom of a trusted web activity the very first time it launches. And it's going to say, running in Chrome. This is to let the user know why their data is being shared and how their data is being shared. You might want to include additional web UI inside of your applications if you think your users might be confused about what's going on. Here's a summary of all the ways that TWA's are different from other approaches to including web content in your Android app. I think you all know how to use these tables, right? You look for the column with the most green in it, and that's what you do. There's really only two things that I want to call out here. And that is data development effort is flagged as low on TWA's. There's really, to get started with them, there's really very little that you need to do, whereas there can be quite a lot if you're using a web view. And the second thing I just want to observe here is how many rows have a yes next to them for the TWA. It is so much easier to use a TWA, and there are so many more features. The most important one, in my opinion, being that complete Chrome API. So whenever a major new API ships with Chrome, you're going to have instant access to it, and that assurance that you're always going to have the latest and greatest is great for a developer. I've mentioned a couple of times that it's fast to get started with TWA's. In fact, it's so fast that Andre can do it in less than five minutes. Check this out. So while creating this talk, Peter and I were considering doing some live coding, but we were convinced not to challenge the demagogues on the first IOTop. Still, we created the speedrun to show the development flow for our trusted web activity. The implementation we're seeing here is based on the GitHub demo, and the flow is basically going there, calling the project, updating some configuration files to open a different domain, creating a new Android icon, and then running the application. And it took me about five minutes from start to finish when doing that. And we'll talk more about this in this case later. So the speedrun helps us understand the overall effort to create a trusted web activity. Now, let's take a better look on how to get started. There are basically three steps needed. Importing the support library, configuring digital asset links, which will enable validating that we own both the domain we are opening and the Android app, and then finally launching the TWA. So adding the support library works in the same way as any other Android library, that is, adding a dependency to the application build file. Adding digital asset links, so digital asset links must be enabled on the Android app and the domain being opened by the TWA. On the Android side, the markup looks a little bit like this, with it's mostly boilerplate and the site bit is the thing that will change between different implementations. Enabling a digital asset links on the domain site requires some pieces of information. The first one is the hosting domain, which is the domain that we are opening in the TWA, followed by the package name, which is also known as application ID. And it's what's used to uniquely identify an application on the Play Store or on Android devices. And the last bit is the SAJ fingerprint, which is extracted from the signature key that we use to upload the TWA to the Play Store. And we can get the fingerprint using the Java key to comline utility. And if you run this command, and you can get the fingerprint from the line that starts with the SAJ256. With those three pieces of information, we can go to the statement list, generate-arranged-tester, that's available at developers.google.com, to help us generate the markup. And then we can just input information and click Generate Statement. And then copy the results that you will get, and serve it from your domain at dot well-known slash slinks.json, the tool will give you the right path to the domain at the bottom. And it's important that you serve that from the right place, because that's where Chrome is going to look for the data to validate the domain. With that done, launching the TWA is straightforward. The support library provides helper classes that help us do that, and that will solve things like figuring out which browser to launch, or triggering the asset links validation, or setting parameters that will tell Chrome to open a content full screen. So now that we know the basics of how to build a TWA, let's take a look on how it works under the hood, as it will help us understand some of the use cases we're going to talk about later. The Thirst of Web Activity Protocol is based on the Android Intent System. For folks coming from the web, you can look at the Android Intent System similar to the router pattern, where activities work like routes, and the Android system works like the router, and intents are kind of like requests. On the TWA, when we call the Launch Thirsted Web Activity Method, the support library will create an intent. And this intent contains extra information that will tell which URL Chrome should open, or which browser to use, and also that Chrome should open that URL full screen. Conversely, if a developer wants to send the user back to a native activity, they can also do it by defining a custom schema in the Android application and then linking to that custom schema from the Thirst of Web Activity. To create a custom schema on the Android side, we can use an intent filter. And the most relevant bits for the intent filter are the scheme and host, which will combine and link that to that from the TWA. So building on top of the Intent System makes Thirsted Web Activity compatible with any Android device where Chrome 72 is available. That means from Android 4.4 KitKat and above, it is covers 95% of Android devices. This also means that other browsers may implement the Thirsted Web Activity protocol. While working with developers and helping them to implement Thirsted Web Activities, we heard some frequent questions. One of them was, well, what happens when Chrome is not installed, or maybe if Chrome is not the user's default browser? The default behavior is to fall back to using constant tabs if the browser supports it. Otherwise, it will fall back to using regular browser intent, so it would just open the browser normally. But as developers, you have the power to change that behavior and implement your own fallbacks if you want, like opening the content in a web view. Another common question was, what happens when a user navigates to a different origin, an origin that hasn't been validated by Thirsted Web Activity? The behavior is that Chrome will use a constant tab in this case. And if both origins have been validated, the user will remain in full screen for the whole navigation. So we heard this one from developers a lot. Can I open a Thirsted Web Activity from the app launcher? And you may have noticed that to open a Thirsted Web Activity, you have to open a native activity first and then launch it. The trick here is to make the launcher activity invisible and then finish it once the Thirsted Web Activity is launched. So from a user perspective, the result looks like this. And the support library contains support for exactly this use case. And it contains a class called LauncherActivity. And it can be used simply by referencing that from the Android manifest. And no Java or Kotlin code is required to use it. So if you want to get started with Thirsted Web Activities, a good way to do it is using the SVGOMG demo available on GitHub. So go ahead and call the repo after the talk. The advantage is that all required changes are centralized in a single file, the build.gradle file. So the application build.gradle is a file used to add information when building an Android app, like libraries, the minimum Android versions, and others. It also allows us to add variables that are replaced when building the app. And the advantage of that, we take that as an advantage to simplify the usage of the launcher activity. Let's take a look at the relevant information for that file. The first one is the application ID, which, as I mentioned before, is the same thing as the Android package name. And it's used both by the Play Store and an Android device to uniquely identify applications, meaning that two applications cannot have the same ID on a device or on the Play Store. The host name, defining a host name, will allow the Thirsted Web Activity to handle links from other applications, like Gmail. So if a user gets a link on their email, they click it. Instead of opening in the browser, it will open in the site of the Thirsted Web Activity. The default URL is the URL that will be opened from an Android launcher. It's the same thing you would use for the launcher URL in a web manifest. And it can take query parameters if you want, for instance, to track when a user is coming to your domain from a Thirsted Web Activity. The launcher name will set the name that shows on the Android launcher for your application. It's similar to what you would use on the name or short name in a web manifest. This asset statement contains the same statement we talked about before when discussing Gista, that's the links. And finally, the caller primary will set the status bar caller for your application. And it will also be used when a user navigates to an origin that hasn't been validated in a custom tab. And it's the same caller you would use as the same caller in a web manifest. So those are all the changes required. And Peter will now tell us how to build a great CWA and some live case studies. Thanks, Andre. So there's some rules for web content inside of your Thirsted Web Activity. And the first one is that you should be building a great PWA to include in your Android app using TWAs. And the great progressive web app, if you're not familiar with them, consists of three parts. It loads and interacts instantly. It works reliably even when you have an intermittent internet connection. And it's going to enhance device features. Most importantly, it should look and feel like it belongs on the user's device. Now, you can see a little demo here at Buher. It's a great PWA. It's instant. And when I activate airplane mode, it even gives me a neat little mini game to play just to keep myself entertained and tell if my train has come out of the tunnel. I keep tying at it for some reason, I'm not sure why. If you've done all that, you're going to want to know whether or not you're actually meeting the requirements of being a great PWA. So to do that, you're looking for a tool called Lighthouse. Now, Lighthouse is a Chrome extension. And it's there to help you improve your performance, the quality, and correctness of your web content. If you're primarily an Android developer, you might not be familiar with it yet. It's a Chrome extension. You can find it where you get all your other extensions. The web has a lot of great features. I mean, it's ephemeral, it's universal, and it's linkable. But it does have drawbacks. And that is that there's a lot of older patterns out there that are not performant. So Lighthouse is there to literally help you light the way and avoid common performance pitfalls and quality pitfalls, and to get to a great PWA. And when you're done, this nice little PWA badge will light up on the right side of your Lighthouse performance report, and it'll help you feel good about yourself. The Play Store is a curated environment. It's there to offer users a source of high-quality content that they are going to expect to run well on their device. And this is the reason for the quality requirements. To be included in the Play Store, web apps need to comply with all of the normal standard Play Store policies, and they need to be exemplary of web applications. That means being instant, being reliable, meeting user expectations for use of device where appropriate, such as push notifications. As a curated experience, these requirements can change over time. So however you're putting an app in the Play Store, whatever technology you're using to build it, at some point, you're going to need to update that app. And that's true of web content inside of a trusted web activity that you've used as part of your Android app as well. You can expect that quality bar to go up over time, and you expect at some point that you're going to need to refresh the web content, as well as your native code. I just want to repeat this one more time, make sure that it's completely clear. All content in Play, and it doesn't matter whether or not it's coming from a web view or any other way, it needs to adhere to the exactly the same Play Store policies as any other Play content. TWA's launched in late January as part of Chrome 72, and they're still very new. But we already have some fantastic brands that have either adopted TWA's already and launched recently or are planning launches in the next few weeks. Now, some of these haven't been alive very long. In fact, many of them are still in split testing, so you may or may not, if you go to their app, get the version of their app that's using trusted web activity in the experience. I hope that we'll have a lot more data to share with you at Chrome Dev Summit. But we already have some great early results. I use Booher as an example of having a great PWA. They're a leading German book and media retailer. I often get asked this question of web versus app in the context of e-commerce websites and publishers. And my answer is always that you should be giving your users and customers the best possible experience wherever they reach out to you. So Booher is doing exactly that. They're providing their customers with a top quality progressive web app. And they've used trusted web activity as a building block for their Play Store experience. And the results are great. Booher's app users convert pretty comparably to the users of the PWA who add to home screen. So these are a self-selected group of highly engaged customers. And they convert at a rate of more than three times that of median web visitors. Mintra is a leading Indian fashion e-commerce site. And they've used TWAs as a building block in a light app. And their focus with their light app is to help them retain users that have storage anxiety. So these are users who would routinely delete apps as a first step in freeing up space on their phone. They're using device targeting here to focus their light app just on users who are most likely to experience this scenario and to help them to stay installed on those apps so they can continue to have an engaged relationship with those customers. Number of times is one of the largest circulated Hindi newspapers in Delhi, Mumbai, Lucknow. And just have a look at those Lighthouse performance scores. Actually, I think maybe they deserve a round of applause. Yeah, really. I'm guessing pretty much everyone here who develops for web has tried to use Lighthouse on their page before. So you probably have some sense of just how difficult it is to get to 100 of performance. It's really a fantastic achievement. Tencent News is one of the world's largest media and technologies companies. And many of Tencent's users start their journey by searching for them explicitly in the Play Store because they're a known brand. And using a TWA has made it easier for them to offer web news to these users inside of their Android app. Early data from these heavy consumers of Tencent News are showing that they spend more than three times as much time in the Tencent experience than users who found them via unbranded keyword search. Finally, Oil Rooms is India's largest hospitality company. And they're also using their TWA to target a light experience at users who are having storage anxiety and where their flagship app may not be the right fit. Their Play Audience is their most engaged user segments. These might be people who regularly travel for business and use Oil Rooms on a weekly or monthly basis. As a result of that, they're also the most engaged user segment. And these users convert more than twice as often. And they're seeing great early results from their light app. There's more. TWA's are still really new. So there's lots of other brands that are testing and launching new experiences using them. Twitter's actively experimenting with TWA's has already given us some great feedback on improving push notification support. 1,800 Flowers has launched a new app that uses trustable app activities just in time for Mother's Day. And they've already seen a 30% lift in conversions. Let's talk a little bit about what's next for trusted web activities. The most important thing that for you to know is something that I already covered in the introduction, which is that TWA's are always going to have access to the latest Chrome features and APIs. They are Chrome. And whenever Chrome Auto updates, those features are available for you to use in your web content inside of the TWA. I also have a few announcements of things that are coming in just a few weeks. Android apps are often composed of a mix of native and web tech. Sometimes the first view to load is a web experience. And you transition to data views later. When you do this, it can be complicated to know when the web content has actually painted and when to hide the splash screen. So we're going to provide you some utility to make that easy and do that more or less automatically for you. Couple of things that you would need to know if you do launch a TWA before Chrome 75 ships, you will need to update the support library and make some changes to your Android manifest, and you'll need to redeploy your app. So this is 100% automatic. There will be some code changes that you need to do to take advantage of this. The second announcement that I want to share for Chrome 75 is if you are using push notifications from your web content, Trusted Web Activities can match the behavior of native Android apps and auto-enroll users in web push. You'll also need to update your app if you want to take advantage of this feature. Trusted Web Activities are built using the Android intent system, which means that TWA's can be implemented by other browsers. And in fact, the Custom Tabs API, which are a very close relative of TWA's, are already supported by Firefox and Samsung Internet. So we really hope that we'll see TWA's being offered by other browsers in the future. I'd love to hear from you. If you have any feedback on how you're using Trusted Web Activities in your projects or suggestions for things that we should provide developers, with Trusted Web Activity, please reach out to Andre and myself. You can use the Trusted Web Activity tag on Stack Overflow, or you can message either one of us on Twitter. I told you I'd come back to this message at the end of the talk. Trusted Web Activity is the best way for you to include web content in your Android app. Anywhere that you're using first-party web content, you should consider using a Trusted Web Activity. It's a replacement for WebView. It's fast. It's featureful. It's always up to date. Thank you so much for joining today. There's a PWA session that's happening right now at the web, Chrome OS, and Payment Sandbox. So I'll be over there. If you have questions about Trusted Web Activity or PWA's, you can come talk to myself and other team members at the Sandbox. A couple of resources that might be useful for you after the talk. First, web.dev is a fantastic resource for building great PWAs. There's a Getting Started Guide link here, and of course Stack Overflow, which is addressing a lot of frequently asked questions. Thanks so much for joining today, and I hope you enjoy the rest of the IEO conference.