Implementing the Web Share Target API in Android TWAs

When developers distribute their web applications as native packages using a Trusted Web Activity (TWA), they often aim to match the deep OS integration found in native platforms. One major integration vector is the Android share sheet. While the Web Share API allows your web app to send content to other Android applications, the Web Share Target API performs the inverse operation. It enables your web application to register as a target, allowing external applications to send text, URLs, and files directly to your web application.

Understanding the Web Share Target API

The Web Share Target API allows an installed progressive web application (PWA) to behave like a native application in the system-level sharing menu. When a user is in another app, such as a web browser, photo gallery, or social media application, and selects the sharing icon, your application will appear as an available destination. When chosen, the operating system launches your application and transfers the shared data directly into your web view.

For this process to function within a Trusted Web Activity, two components must align. First, the Web App Manifest must declare how the web application handles incoming shared content. Second, the underlying Android wrapper must map these web-level declarations to native Android intent filters. When both elements are configured correctly, the native Android system routes the incoming data smoothly to the web environment.

Configuring the Web App Manifest

The configuration begins inside the web application manifest file. You must add the share_target member, which outlines the endpoints and parameters your application uses to ingest data. The target can be set up to handle simple GET requests, which are ideal for URLs and plain text, or POST requests, which are necessary when dealing with binary files like images.

For a standard implementation handling URLs and short text snippets, a GET request configuration is structured as follows:

{ "share_target": { "action": "/receive-share/", "method": "GET", "params": { "title": "shared_title", "text": "shared_text", "url": "shared_url" } } }

If your application must process multimedia uploads, such as images, videos, or documents, you must configure the target to accept POST requests with a multipart form data encoding type. Below is an example of an advanced manifest configuration designed to receive files:

{ "share_target": { "action": "/receive-share-file/", "method": "POST", "enctype": "multipart/form-data", "params": { "title": "shared_title", "text": "shared_text", "files": [ { "name": "shared_media", "accept": ["image/png", "image/jpeg", "image/gif"] } ] } } }

Mapping Intents in the Android Project

While standard mobile browsers read the manifest and handle registration automatically, an installed Trusted Web Activity relies on native intent filters inside the Android package manifest to signal to the OS that it can accept shares. When building or configuring your TWA wrapper, you must declare these capabilities inside the AndroidManifest.xml file within the activity definition that launches the TWA.

The native Android platform uses intent filters containing action and category elements, along with explicit MIME types, to matches your application with the data types being shared. Below is a guide to the primary configurations required in the AndroidManifest.xml block:

<intent-filter> <action android:name="android.intent.action.SEND" /> <category android:name="android.intent.category.DEFAULT" /> <data android:mimeType="text/plain" /> </intent-filter>

If your application handles media sharing, you must append additional filters specifying the exact file MIME types allowed, matching the properties defined in the web app manifest:

<intent-filter> <action android:name="android.intent.action.SEND" /> <category android:name="android.intent.category.DEFAULT" /> <data android:mimeType="image/*" /> </intent-filter>

These native declarations ensure your TWA is visible inside the system share sheet. When clicked, the TWA launcher extracts the incoming intent payload and translates it back into the query parameters or multi-part form parameters that your PWA expects at the designated action URL.

Handling Shared Data inside the Web App

Once the system routes the request, your web application must parse and process the incoming data. For GET-based configurations, handling this logic is straightforward. Since the data is appended as URL query parameters, you can extract the values on the client side using standard JavaScript search parameter APIs.

When the user lands on your sharing action route, run a script to process the query string:

const urlParams = new URLSearchParams(window.location.search); const title = urlParams.get('shared_title'); const text = urlParams.get('shared_text'); const sharedUrl = urlParams.get('shared_url'); if (title || text || sharedUrl) { processShareInput({ title, text, sharedUrl }); }

For POST-based sharing, particularly involving file transfers, client-side JavaScript on a standard page load cannot directly read the request body of a POST navigation request. Instead, you must intercept the request within your service worker. By listening to the fetch event, your service worker can intercept the POST request, parse the form data, and either process it or save it to local storage before redirecting the user to an interface where the files can be displayed.

Below is an outline of a service worker intercepting shared file data:

self.addEventListener('fetch', (event) => { const url = new URL(event.request.url); if (event.request.method === 'POST' && url.pathname === '/receive-share-file/') { event.respondWith((async () => { const formData = await event.request.formData(); const file = formData.get('shared_media'); await storeSharedFileInIndexedDB(file); return Response.redirect('/share-received-dashboard/', 303); })()); } });

Validating and Testing the Share Pipeline

Validating the complete data flow requires a systematic approach. Developers should first test the implementation directly inside a standard mobile browser before testing the compiled Android application wrapper. The table below outlines key troubleshooting areas during the validation process:

By mapping your manifest configurations directly to your Android intent filters, your Trusted Web Activity behaves with the deep OS integration expected of high-quality mobile applications, lowering the friction for users to bring their external content into your software ecosystem.