Shared Storage and Cookies in Android TWAs Explained

Understanding Storage Sharing in Trusted Web Activities

For developers converting a Progressive Web App into an Android package, the architecture of the browser wrapper dictates how user state is managed. Unlike traditional Android WebView wrappers, which maintain an isolated, separate cookie jar and storage sandbox, a Trusted Web Activity operates on a completely different model. It runs within the user default browser context, which is typically Google Chrome.

This structural change introduces shared storage. A Trusted Web Activity shares cookies, local storage, IndexedDB databases, and service worker caches directly with the system browser. This unique integration has deep implications for user experience, authentication flows, security isolation, and data persistence that every Android app publisher must understand.

The Architecture of Shared Storage

When a user launches a Trusted Web Activity, the native Android application initiates a specialised Custom Tab intent. Instead of instantiating an embedded browser engine inside the application process, Android coordinates with the installed browser. The browser engine renders the web application within the security context of the user system browser profile.

Because the app runs within the user system browser profile, the storage layers are identical. If your user visits your web application via Chrome on their mobile device, and then subsequently opens your installed Android application, both access the exact same underlying storage directory. This shared context is verified and secured using Digital Asset Links, ensuring that third-party applications cannot gain unauthorised access to these directories.

Cookies and Single Sign-On

The shared storage model provides a major advantage for web-to-app conversion: native Single Sign-On out of the box. Traditional WebView applications require complex native cookie synchronization or custom header injection to pass authentication state from a web browser into the native container. In a Trusted Web Activity, this friction is eliminated.

When a user authenticates on your website using Chrome, the session cookie is saved in the Chrome cookie jar. When the user later installs your application from Google Play and opens it, the Trusted Web Activity inherits that exact cookie jar. The user is logged in automatically, bypassing the friction of re-entering credentials. This seamless onboarding experience significantly improves conversion rates and user retention.

Digital Asset Links and Storage Security

Allowing a native application to access the system browser storage could present a security risk if not heavily restricted. To prevent malicious applications from wrapping your website and reading your cookies or session state, Google mandates the use of Digital Asset Links.

Digital Asset Links establish a two-way association between your native Android package and your web domain. The association is verified using a JSON file hosted on your web server at a specific secure location and a package signature embedded in your APK or AAB. If this validation fails, the native container will not launch as a Trusted Web Activity. Instead, it fallback to a standard Custom Tab with a visible URL bar, and the shared storage capabilities are heavily restricted or isolated to protect the user data.

Comparing Storage Behaviours

Understanding how storage behaves across different container types helps developers choose the right wrapper strategy and plan their authentication flows. The table below outlines the core differences in storage lifecycle and isolation between WebViews and Trusted Web Activities.

Clearing App Data and Handling Sessions

The shared storage model introduces unique edge cases when users attempt to clear their application data or log out of their accounts. Developers must design their applications to handle these asynchronous states gracefully.

If a user goes to the Android settings screen for your installed application and taps the option to clear storage, Android will delete the local configuration files of your native wrapper. However, because the web storage resides within the Google Chrome profile, this action does not necessarily clear the web cookies or LocalStorage. The user may still remain logged in when they relaunch the application.

To ensure a complete logout experience, your web application should provide a robust sign-out mechanism that explicitly deletes session cookies and invalidates authentication tokens on your server. Relying on the user clearing their native Android application cache to force a logout is not a reliable strategy when working with Trusted Web Activities.

Managing Multiple Subdomains and Domains

Because Trusted Web Activities leverage the browser engine, cookie isolation follows standard web origin rules. If your application navigates between different subdomains, cookies set with a wildcard domain attribute will be accessible across those subdomains, exactly as they are in a standard desktop browser.

If your application architecture requires sharing authentication state between different root domains, you must configure your Trusted Web Activity to support multi-origin routing. Each domain must host its own Digital Asset Links verification file, and the native wrapper must list all target domains in its configuration. Once verified, the shared storage benefits will extend across all listed domains, providing a unified session experience across your entire web ecosystem.