[go: up one dir, main page]

Custom Tabs is a browser feature, introduced by Chrome, that is now supported by most major browsers on Android. It gives apps more control over their web experience, and makes transitions between native and web content more seamless without having to resort to a WebView. Similar to when using the browser, users frequently want to share the content that is rendered inside the Custom Tabs.

Custom Tabs do not provide a default sharing experience and many apps don’t provide a way for users to share content at all. This results in a poor user experience where users must find the share action from the overflow menu in the browser. This action takes the user outside of the app and opens the link in the browser, resulting in decreased app engagement.

In Chrome 88 we're running an experiment to automatically add a default share action in certain scenarios. For example, where an app has not specified its own Action Button, we will display one in the top bar. Where a site has specified its own top bar Action Button, a default share action is added to the overflow menu.


A default Action Button that shares the URL is added to the top bar when the application doesn’t provide one.

What do I need to do to enable the new default share action button in?Nothing! The default Action Button will be automatically added to the application, as long as the application doesn’t set its own. Since this change will happen in the browser, it will be automatically applied to all apps using Custom Tabs.

Please note: this is a change in Chrome’s behavior and we hope other browsers will add similar functionality.


How can I opt-out from the share icon showing in my App?
Starting with androidx.browser version 1.3.0, developers can use the setShareState() method from the CustomTabsIntent.Builder to disable the default share:

val customTabsIntent = CustomTabsIntent.Builder()

        .setShareState(CustomTabsIntent.SHARE_STATE_OFF)

        .build();


As part of this change, the addDefaultShareMenuItem() and setDefaultShareMenuItemEnabled() methods from CustomTabsIntent.Builder have been deprecated and developers should use setShareState() instead.


If your application uses Custom Tabs, we’d like to hear your feedback, and you can reach out to us using this form.


A Trusted Web Activity (TWA) displays a full screen Chrome browser inside of an Android app with no browser UI. Although Android apps routinely include web content using a Chrome Custom Tab (CCT) or WebView, a TWA offers unique advantages when you need Chrome’s performance and features in your app in full screen mode.


In this post I’ll introduce you to TWAs, review suggested use cases and link to resources to get you started.



What’s different about a Trusted Web Activity?  


A Trusted Web Activity runs a Chrome browser full screen in an Android app, meaning there is no browser UI visible in the app, including the URL bar. This is a powerful capability so we need to verify that the app and the site belong to the same developer - hence ‘Trusted’. To verify that the app and the site opened in the TWA belong to the same developer, a TWA uses Digital Asset Links to certify ownership.


Because a TWA is a special case of a Chrome Custom Tab (CCT), it has access to all Chrome features and functionality including many not available to a WebView. If you’re not familiar with Chrome Custom Tabs, this article provides a complete overview. Some of the features of a TWA not available in a WebView include web push notifications, background sync, Chrome form autofill, Media Source Extensions (MSE) and the Sharing API.


Just like a CCT, a website loaded in a TWA shares stored data with the Chrome browser, including cookies. This implies shared session state, which for most sites means that if a user has previously signed into your website in Chrome they will also be signed into the TWA.



What can I use a TWA for?  


TWAs are great for including full screen web content in an Android application where you need Chrome features not available in a WebView or if shared origin storage with the Chrome browser makes your user journey easier.


An example of this is an e-commerce site where product pages are implemented in native views but the checkout flow takes place on the website. By using a TWA your app will have Chrome’s performance and can use Chrome’s one tap signup and automatic form filling features.




Trusted Web Activity Criteria


All content in TWAs must comply with Play store policy including policies for payments in-app purchases and other digital goods.


App users expect a great experience on their device. To ensure the quality of experience TWAs must meet PWA installability criteria and load fast. Loading speed is measured using Lighthouse and web content in TWAs must achieve a performance score of 80. Lighthouse is an open-source, automated tool for auditing performance & progressive web apps and is useful both as a benchmark and to help you build better websites.

As with any Play app, additional quality criteria may apply in the future. Apps which fail to meet TWA quality requirements or Play store policy may be denied entry or delisted.




Trusted Web Activity content security and version availability


The content of a TWA is protected and cannot be read or modified by the enclosing application. That means state can only be shared from the app to the TWA when it is initialized by passing in query string parameters and it is not possible to insert content into the TWA from the Android application.


TWAs are available on devices running Android KitKat or newer (over 95% of Android devices) with Chrome installed. If Chrome is installed but is out of date, for example due to user disabled Chrome updates, a Chrome Custom Tab is automatically substituted for the TWA.



Your first Trusted Web Activity

Getting started documentation & example code for TWAs is in development and will be released soon. In the meantime reference documentation is included below.  



Reference


Posted by Peter Mclachlan, Product Manager