📜 ⬆️ ⬇️

Play Store now accepts progressive web applications (PWA)


Disclaimer: I am not affiliated with Google Play, Chrome or any of the companies mentioned. This is not an official statement. The logo and names are used for illustrative purposes only.

Chrome 72 for Android has the long-awaited Trusted Web Activity feature. This means that we can now distribute PWA through the Google Play catalog and run Chrome without a UI offline for native packages! I played for some time with this function, delving into the API, and here I will tell you what it is about, what to expect and what is available today.

PWA in the Play Store catalog


Chrome 72 for Android is now available for all users, and in this version the Trusted Web Activity (TWA) system is implemented. In short, Chrome is launched offline (without a toolbar and UI) for native Android packages.

To begin with, publishing in the catalog is not such a simple procedure as it should be (for example, entering a URL into Google Play - and the application will start). In addition, you cannot use the available WebAPK and publish the application in the directory. It uses the Java API, which interacts with Chrome through services and seems to be at an early stage of development. So you have to do a lot manually.

I see this as the first step. Surely soon there will be a better toolkit (perhaps from the community) with support for all available APIs and a one-click launch. But on the current API, you can publish it in the PWA launcher directory. I will share my experience how this is done.

For some reason, this feature has not yet appeared in the Chrome Platform Status , and the documentation has not yet been updated (it has not been updated at all for more than 15 months).

Update from February 5th . Chromium's blog has posted a short note on TWA support and some of the technical details mentioned in this article.

Update from February 1 . Paul Kinlan, Chrome's lead developer at Google, confirmed the release of the TWA feature and that the documentation is delayed: the reason for the delay was that the permission for the new Chrome 72 feature was taken at the last minute.


Video from Pete Le Page a year ago with TWA explanation

Why publish PWA in a directory?


This is a web platform, Karl! Why use a directory?

Well, this is a long conversation, but for many years I have been consulting a large and small business, and when we look at developing PWA, the application catalog is constantly mentioned: “Our users will search for an application there,” “We already have our own application, and we don’t want to lose users ”,“ We ​​need access to our own API ”or“ I want to monetize PWA ”.

From now on, it became possible to publish PWA in the catalog, as well as work from the browser. Of course, this is a separate operation. Play Store does not emulate Microsoft Store: your PWA will not appear in the store unless you compile the APK and publish it.

Advantages over standard PWA


In addition to the new distribution mechanism and new users from the directory (and even from Google search in the “Applications” section), other advantages appear:


What is innovation?



There were already some PWA in the catalog, but now they are much easier to prepare and publish.

Google Play Store already has some PWA, such as Google Maps Go, Instagram Lite and Twitter Lite. The first application uses some kind of private version of pre-TWA, and the last two - WebView, it was at least not perfect, but the only way to do something like this before the advent of TWA. Applications have a lot of machine code for some things, like notifications. We want to publish PWA as web developers and don’t want to write a lot of Java code.

TWA is a special mode based on custom tabs of Chrome , which from the version of Chrome 45 allow you to launch the browser built into the application.

Is TWA a hybrid framework similar to Cordova?


Not. With Cordova and other hybrid solutions, you usually deliver resources (HTML, JS, CSS, etc.). in the apk package. In addition, there is a different engine, it is isolated from the user's browser, so it does not support session or cache sharing.


This is what PWA looks like with Trusted Web Activity. I still do not see the implementation of color schemes

Using Trusted Web Activity, you do not need to package resource files (only native components, if needed); All resources are downloaded and updated on the fly through a service worker. Your PWA is always rendered with the installed version of Chrome, with its repository, cache, and sessions. Thus, if the user has opened a session on the website, and then installed the application from the Play Store, he will be already authorized in the system.

Play Store Requirements


The URL used for the trusted web operation must meet the following requirements:


According to a Chromium blog post , "applications that do not meet TWA quality requirements or Play Store rules may be denied admission or may be excluded."

I'm not sure yet that the Play Store QA team checks all these requirements when publishing an application.

PWA security model in the Play Store


Your PWA will obey the security model of the browser, not the native application, until you add the native code directly to the APK. Since everything is under the control of the browser, the user should know that even if he has just installed the application, he will have session data, local storage and permissions already set for this host in the browser. That's why when you first start it shows a mini-message "Works in Chrome" :



In addition, when a user deletes the app, they’ll get a warning that the status and application data is still available in Chrome, so if necessary, you should clear the cache. Among such traces, for example, Web Push permission: even if the user deletes the application, he will continue to receive push notifications anyway. The message was noticed by Henry Lim:



Paul Kinlan from the Chrome team spoke about the need for such notifications.


Ways to develop


To create a package with TWA, you first need Android Studio . So far, all the options are experimental and are described only by code examples in the Chrome repository on GitHub.

Application Development Options with TWA:


February 5th update : now the Android documentation for TrustedWebUtils , the TWA helper , is now available on the Android website.

Manifest distribution


PWA in the App Store will not accept the web application manifest; you must manually copy some values. The icons are taken from the “res” folder, as in any native Android application, the orientation lock should be defined in the AndroidManifest activity record, etc.

When using the support library, the splash screen is created automatically, but other properties of the manifest will not be used. In fact, in my testing, I couldn’t apply a color theme when PWA was opened on the screen.

URL validation


TWA will work only after a digital domain handshake with the application. The mechanism is known as Digital Assets Links . It creates a trust relationship between your host and the APK, proving that you own a PWA and that you will not publish applications that you do not own to the Play Store. It also establishes a digital channel between the site and the native application, which theoretically could allow them to exchange private data (but this seems to be impossible with today's TWA API).

With Digital Assets Links, you should put a <your-domain> /. Well-known / assetlinks.json file on your domain . This JSON file contains information about the Android package (for example, the package identifier) ​​and the certificate hash of your application, which you can find out using the command in the console. The Android package will have a duplicate of the host URL. There is an online validator to check that everything is in order.

If you haven’t done a handshake, TWA is not activated, and your application will simply use regular Chrome Custom Tabs with a minimal Chrome interface, as if you include display: minimal-ui in PWA. I'm not quite sure, but probably the Play Store can reject applications that simply point to regular tabs without validating TWA. I don’t know for sure at what point Chrome is checking Digital Asset Link; if every time you access an application, it can be a performance issue. I think caching is possible, and the Play Store can do a check before approving an application during admission to the directory. Let's see what will be written in the documentation.

There is a (not very simple) mechanism for bypassing the Digital Asset Link certification process for development purposes, described below.

Application Publishing


To publish a PWA shortcut using TWA, you must follow all the rules of the Play Store. For more information, see the Developer Policy Center . You will also need to create a publisher account with a one-time fee of $ 25, metadata, screenshots and marketing materials for the application.



Depla


When you finish development in Android Studio and you have an account to the developer console, you need to create an APK for production and sign it with a key created in Android Studio. You can use the App Signing by Google Play service to simplify the process in the future.

Google Play console


There are no special rules or processes for downloading these applications, but Revision may detect that you are using TWA and will verify that: 1) Digital Assets Link is working; 2) The URL passes the PWA criteria (mainly for the fetch event handler in the service worker).


For publication in the Play Store you will have to specify a lot of metadata and graphic resources.

Update application


If you change the content, you do not need to reload the application, unless you change the application completely (in accordance with the rules of the directory). You continue to update it through service workers and updates on the server. New APK will have to download only if you want to change the metadata, native code or icons.

Restrictions


Now the platform has certain limitations, but this is only the beginning. I hope in time they will be removed.

PWA in subfolders


If you publish your PWA in a subfolder of the host, then several problems arise.


No internal applications


This is a limitation of the Play Store itself (you cannot publish applications for the local network or applications intended only for you and your company). You can use TWA and create apk that will be deployed outside the store.

Digital Asset Link works only with publicly accessible URLs, because Chrome must verify that we own the domain, and this is not possible with internal URLs.

First boot


When you first open a newly installed application, there are no application files on the device yet (Service Worker is not registered yet if the user has not opened PWA before), so the user will see a blank white screen in offline mode. I think in future versions it would be useful to implement some swap via Chrome after installing the application. If you use the TWA API instead of the support library, then you will find the situation and correctly inform the user through the native API.

Calling native code


There is already a bidirectional link between the TWA server (Chrome) and the TWA client (our APK). This channel is currently used only for sending push notifications and displaying them in a native application, and not in Chrome.

There is a certain potential in the simple combination of native code and JavaScript, giving PWA access to native code, similar to the APPX / PWA mechanism in Microsoft Store.

Perhaps in the future it will be possible to register Java / Kotlin classes in the TWA client so that we can actually call them using the JavaScript API when our PWA is rendered in TWA mode.

Today, the only way to execute native code is to use Intents to open other native actions and then reopen TWA, sending and receiving arguments through URI parameters.

In addition, you can create some kind of web server or WebSocket server in the native code, and send PWA to it, but this is strange, difficult, and it may be unnecessary to waste the battery. But we have a whole new world of possibilities. Let's see what the community comes up with!

Monetization with Play Store


If you have a paid application, you cannot easily verify that the user actually paid for it (after all, the content is just a URL). In addition, if you want to sell some digital resources or subscriptions using the Play Store wallet, then it is difficult to implement such a scheme without an actual bridge with a native code.

Debugging


I'm not sure if this is a bug or some kind of problem with my IDE, but remote debugging of service workers from TWA does not work. I can check the context of the window, but not the service worker.

Other engines


Now TWA only works on Chrome, but in the future other browsers may clone APIs: for example, Samsung Internet, Edge or Firefox.

February 4th Update : TWA works on the Android Custom Tab protocol, which other browsers are currently implementing. Therefore, if another browser is installed on the system by default, it can open TWA with the contents of PWA. However, additional testing is required to understand how this works.

What happens if the user has an older version of Chrome and he installs the app from the Play Store? In this case, the PWA will appear as a custom Chrome tab, rather than in a completely offline mode.


Google Maps Go in the Play Store has already used something similar to TWA, and Chrome is listed as a requirement for work.

What happens if a user doesn't have Chrome at all? Today, when using the support library, the application will not work at all (if there is no other browser with support for the Custom Tabs protocol). If you use the TWA API in native Java / Kotlin code, you can check the accessibility of the browser and download an alternative solution, such as WebView, or open a browser.

Although Android devices without Chrome are rare, but on some it is not installed by default, including on all new devices in Europe .

Other platforms


PWA does not work on wearable OS (watch), but I'm not quite sure what is happening on other Android platforms. There is probably no support yet, but you need to check it out. I'm talking about Android TV or Chromebooks from the Play Store. If you have not tested these platforms, it makes sense to disable them in the directory list.

WebAPK conflict


If you installed PWA from Chrome, then you already have an APK for this URL, signed by the Play Store, but the catalog will still leave the app on the list and allow the user to install it too. And vice versa: installing an application from the directory will not prevent Chrome from prompting the user to “add” it from the browser. I think this can be avoided if WebAPK also receives Digital Asset Link or we can somehow match the identifier of the WebAPK application, but this is unlikely to happen in the near future. We'll see.


Two Starbucks applications running simultaneously: WebAPK and our own APK

You can block the Chrome offer to install the WebAPK and instead show your application from the directory using the related_applications attribute and the prefer_related_applications attribute of the web application manifest. Get Installed Related Apps API may in the future help resolve this conflict.

Creating the first PWApk


I know, I just invented the word PWApk, but it sounds good, right?

A few years ago I made a video course on native Android web applications . Although not entirely related to PWA, it does help to understand the Android ecosystem.


The easiest way to make a TWA-based APK is to clone a sample SVGOMG repository from the ChromeLabs repository on GitHub

You can clone the git repository or launch a new project. In our case, we are starting a new project only to better understand the topic.

Create a new project in Android Studio and select No Activity : we will use only Trusted Web Activity from the support library.


Let's start with an empty project.

Fill in the data, select the project name (we will change it later) and the name of the package: this will be the identifier of our application in Android, as well as in the directory. I recommend using the host name in reverse order and an arbitrary name at the end. For example, if you have the host mypwa.com/calculator , then the package can be called com.mypwa.calculator .

API 19 will be suitable as a base (Android 4.4). It seems that soon it will be the minimum version needed for Chrome . Some TWA functions will only work with API 23 (Android 6.0), but the support library will take care of this.

February 5 update : Chrome officially announced that TWA only works with Android 4.4 KitKat. Thus, this function is not available to approximately 5% of active Android users: they will be rolled back to the version with the custom tab and address bar.


Selecting the minimum API level will limit the list of devices for which PWA will be offered in the Play Store catalog

Add dependency


The next step is to add the TWA support library as a dependency, so we ’ll open two files called build.gradle :


Two configuration files: for the project and for the Android application

Let's start with the project file. Add the following line in the allprojects> repositories section:

maven { url "https://jitpack.io" }

In the next step, we open the module's build.gradle and add in dependencies:

 implementation 'com.github.GoogleChrome:custom-tabs-client:e446d08014'

TWA Setup


The next step is to set the PWA parameters for Trusted Web Activity in the module file; add it to the defaultConfig section:

 manifestPlaceholders = [ hostName: "app.starbucks.com", defaultUrl: "https://app.starbucks.com", launcherName: "Starbucks", assetStatements: '[{ "relation": ["delegate_permission/common.handle_all_urls"], ' + '"target": {"namespace": "web", "site": "https://app.starbucks.com"}}]' ]

Here I will use Starbucks PWA as an example. Information from the Digital Asset Link process will be required for the assetStatements key. We will skip this part for now. The property named launcherName must match the short_name in the manifest of the web application.

Manifest customization


Android applications have their own manifest, they will not accept a web application manifest. The desired file is located in the app> manifests section and is called AndroidManifest.xml. There you will find the self-closing Application XML element.


Default Android manifest file

There we change the value of the android: label to $ {launcherName} , which we set earlier in the metadata, so that we will have the only source of truth for the name of the application.

The next step is to configure this file, starting with the <application> tag, to add child elements to it, which will look like this:

 <meta-data android:name="asset_statements" android:value="${assetStatements}" /> <activity android:name="android.support.customtabs.trusted.LauncherActivity" android:label="${launcherName}"> <meta-data android:name="android.support.customtabs.trusted.DEFAULT_URL" android:value="${defaultUrl}" /> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> <intent-filter> <action android:name="android.intent.action.VIEW"/> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE"/> <data android:scheme="https" android:host="${hostName}"/> </intent-filter> </activity>

The code below will configure the TWA using the support library and the Intent Filter so that the application gets links to PWA and Digital Asset Link. I’ll skip the details of what’s happening in terms of the Android app.


It's time to sync

At this point, you need to tell Android Studio to accept all of your changes by clicking Sync Now . If everything is done correctly, then no errors will pop up.

Replacing Icons


At the moment, the application uses only the Android default icon, so you need to replace all the files in app> res> mipmap in different subfolders for different pixel densities. There are two versions: square and rounded icons. Rounded appeared in Android 7.1, and if you want to ignore them, then delete the link android: roundIcon link in AndroidManifest.xml.


You need to take the icons from the manifest and copy them into mipmap subfolders with corresponding names

Theme setting


Finally, you need to open app / res / values ​​/ styles.xml and make some changes to the theme so that it looks like PWA:

 <style name="AppTheme" parent="Theme.AppCompat.Light.NoActionBar"> <item name="colorPrimary">@color/colorPrimary</item> <item name="colorPrimaryDark">@color/colorPrimaryDark</item> <item name="colorAccent">@color/colorAccent</item> <item name="android:windowNoTitle">true</item> <item name="android:backgroundDimEnabled">false</item> </style>

You can change the colors from app / res / values ​​/ colors.xml , but I have not yet seen this work in TWA.

If you limit the orientation in the manifest, you can add this restriction to the <activity> element in AndroidManifest.xml.

Ready for testing?


We are ready to test our PWApk, but before that you need to set up the TWA development mode for Chrome on a test Android device or in an emulator (with Chrome 72+).

Chrome setup


Make sure you have Chrome stable version 72 and open chrome: // flags . Find the option Enable command line on non-rooted devices and check the box . Restart the browser.

Then you need to configure Chrome to bypass Digital Asset Link for the host we want to test, in our example, app.starbucks.com .

To change the command line options for Chrome for Android, you need to write a text file to the Android file system. The easiest way to do this is through adb (android debug bridge), which should be registered in the path (google, if that), and run the command:

 adb shell cat /data/local/tmp/chrome-command-line _ - disable-digital-asset-link-verification-for-url="https://app.starbucks.com"

You can use a simple bash script from Google.


You need to stop Chrome so that it will accept new settings at startup.

And restart Chrome. But it’s not just to remove the application from the task list, but to force the entire process out of the settings (Force Stop). I had to do it a couple of times before it worked.


Warning that the flag is on and everything went well

If everything is done, every time you open Chrome, you will see a warning about an unsupported flag. If you launch the application from Android Studio, your PWA will finally start and work offline under the icon and name of your APK.

Conclusion


The ability to publish PWA in the Google Play catalog really changes the rules of the game. It seems that we now have a very early version of the API and definitely need some work. I really want to be able to enter the URL of our PWA and get an APK file from it. This is not very easy due to the Digital Asset Link verification system. Only the Play Store can do this using the same WebAPK that they generate.

I used to wonder if Google approves of the PWA application or leads a war with them . But now they have removed their suspicions, at least in part of the TWA.

Let's hope that TWA in Chrome 72 is the first step in a long journey!

Source: https://habr.com/ru/post/439238/

More articles: