 Having an app available in 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 a web view or a custom tab. Well, each of these has their own benefits, there are also drawbacks to each. With web views, the content runs full screen and supports many of the PWA features. It has the ability to use post message to send messages back and forth between the web view and your native code, which makes it possible to invoke certain native functionality that isn't available on the web. On the flip side, web views 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's safe passwords and so on. The other challenge that comes up is that web views may be out of date. Web views 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 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 user's up to date browser instead of an out of date web view. It shares the same cookies and storage within the browser and it has access to APIs that aren't available in web views. 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 down a sore 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 opened 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 our 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 key tool on the certificate that we use to sign our Android app, we'll get the SHA-256 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 dot 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 in 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 slash trusted web activities. 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.