How TWAs Handle Missing or Outdated Chrome on Android

A Trusted Web Activity (TWA) is an elegant way to distribute a Progressive Web App (PWA) on the Google Play Store. Unlike legacy WebView wrappers, a TWA runs directly inside the system browser engine, sharing cookies, storage, and state with the user's primary browser. On the vast majority of Android devices, this rendering engine is Google Chrome.

However, Android is a highly fragmented ecosystem. Users run devices without Google Play Services, uninstall default browsers, or neglect system updates for years. Developers migrating a web application to the Google Play Store must understand how a TWA behaves when Google Chrome is missing, outdated, or disabled on the target device.

How TWA Engine Selection Works

A TWA does not package a rendering engine inside the application binary (APK or AAB). Instead, it uses the Android Custom Tabs protocol to request a browser engine from the operating system. When the application launches, the lightweight Android wrapper queries the package manager to find browsers that support the Custom Tabs protocol and can handle the specified web origin.

The Android system prioritises the user's default browser, provided that browser supports Custom Tabs. If multiple compatible browsers are installed, the system resolves the preference based on specific criteria. If Google Chrome is installed and set as the default, the TWA launches using Chrome's rendering engine. Because Chrome is updated independently via the Google Play Store, the TWA automatically gains access to the latest web APIs, JavaScript optimisations, and security patches without requiring the developer to push an application update.

The Fallback Hierarchy When Chrome Is Absent

If Google Chrome is not installed or is disabled by the user, the TWA wrapper does not crash. The Android Support Library (specifically the androidx.browser library) contains built-in fallback logic to handle these scenarios. The wrapper executes a sequence of checks to find the best available rendering engine.

First, the wrapper searches for alternative browsers that support the Custom Tabs protocol. Many modern Android browsers have implemented this support to ensure compatibility with modern web applications.

If a user has Samsung Internet or Firefox set as their default browser, and Chrome is missing, the TWA will launch within that alternative browser's Custom Tabs interface. This ensures that the application still benefits from shared cookie storage and high-performance rendering, even if the underlying engine is GeckoView rather than Blink.

The Last Resort: Falling Back to WebView

If the device has no browsers installed that support the Custom Tabs protocol, the TWA wrapper falls back to using the standard Android System WebView. In this scenario, the wrapper instantiates a WebView container to load the web application.

While this prevents the application from failing to open, falling back to a WebView has several distinct technical consequences:

• Isolated Storage: The application no longer shares cookies, Web Storage, or IndexedDB data with the user's main mobile browser.
• Feature Limitations: Advanced web APIs that are supported in modern mobile browsers may be disabled or behave differently inside a standard WebView.
• Performance Penalties: WebViews generally run with slightly lower JavaScript execution performance compared to the full Chrome rendering engine.

Handling Non-GMS and Alternative Android Devices

Developers targeting global markets or specific hardware must consider devices that do not ship with Google Mobile Services (GMS). This includes Amazon Fire tablets (running FireOS) and modern Huawei devices (running EMUI or HarmonyOS without Google services).

On Amazon Fire tablets, the default browser is Amazon Silk, which is based on Chromium. Amazon Silk supports the Custom Tabs protocol. Therefore, a TWA distributed on the Amazon Appstore will launch seamlessly using the Silk rendering engine, offering performance comparable to Google Chrome.

On Huawei devices, Huawei Browser serves as the default. Huawei Browser also supports Custom Tabs, ensuring that the TWA runs efficiently. If no compatible browser is found on these highly customised operating systems, the system falls back to the local Web Kit or WebView implementation wrapper.

Ensuring Compatibility: Best Practices for Developers

To ensure a consistent user experience across all Android devices, regardless of browser configuration, developers should adopt several defensive programming practices.

1. Define a Clear Minimum SDK Version

Ensure your Android project configuration specifies a minimum SDK level that supports modern Custom Tabs. Setting the minimum SDK to API Level 21 (Android 5.0) or higher is recommended, as this ensures the androidx.browser library can resolve dependencies correctly on almost all active Android devices.

2. Verify Your Web Manifest Capabilities

Because your TWA may run on alternative browsers like Firefox or Samsung Internet, avoid relying strictly on Chrome-only experimental flags or APIs. Ensure your web application uses feature detection rather than user-agent sniffing to determine if specific browser features are available.

For instance, instead of checking if the browser is Chrome before requesting a service worker or dynamic import, check for the presence of the API directly in the window or navigator object:

if ('serviceWorker' in navigator) { navigator.serviceWorker.register('/sw.js'); }

3. Handle Offline States Gracefully

When the TWA falls back to a WebView, the service worker must be robust enough to handle offline situations. If the WebView fallback is triggered and the user has no active network connection, the WebView will display a generic, unbranded browser error page unless your service worker has cached the offline page correctly within the local WebView cache context.

Conclusion

The Trusted Web Activity architecture is designed with resilience in mind. By relying on the Android Custom Tabs protocol, a TWA prioritises Google Chrome, seamlessly transitions to alternative modern browsers if Chrome is missing, and falls back to a standard WebView as an absolute safety net. Understanding this hierarchy allows developers to build robust web applications that look, feel, and perform like native applications across the entire fragmented Android ecosystem.