Restricting TWA App Installation by Android Version

Why Web Apps Need Native Installation Restrictions

Progressive Web Apps (PWAs) are designed to be universally accessible, running on any operating system that possesses a modern web browser. However, when you convert a PWA into a native Android app using a Trusted Web Activity (TWA), you are packaging that web experience inside a native Android wrapper. This wrapper interacts directly with the Google Play Store and the underlying Android operating system.

While a web browser can easily degrade features gracefully on unsupported devices, a native app that crashes or fails to perform due to outdated system components will receive negative reviews on the Google Play Store. To protect your brand reputation and ensure a smooth user experience, you must configure your TWA to restrict installations. By defining minimum software versions and hardware capabilities, you prevent incompatible devices from downloading your application.

Configuring minSdkVersion for Modern Web Capabilities

The minSdkVersion parameter in your Android build configuration determines the oldest version of the Android operating system on which your application is allowed to run. If a device has an OS version lower than this limit, the Google Play Store will hide your app from the user entirely.

For a standard TWA, the physical baseline is dictated by Custom Tabs compatibility, which requires Android 4.1 (API Level 16) or higher. However, setting your minSdkVersion to API 16 is rarely advisable for modern web applications. Modern web APIs (such as the Origin Private File System, WebAssembly, WebAuthn, or advanced CSS specifications) require modern browser engines. On Android, the TWA depends on the system's default browser provider (typically Google Chrome, Samsung Internet, or Android System WebView).

If you set your minSdkVersion too low, users running old Android devices with outdated Chrome versions will experience slow performance, rendering bugs, or broken layouts. Setting the minSdkVersion to API 21 (Android 5.0) or API 24 (Android 7.0) ensures your application runs only on devices capable of running modern Chromium versions.

Managing targetSdkVersion and Google Play Compliance

While minSdkVersion establishes the floor, targetSdkVersion specifies the API level against which your app's native code was tested. Google Play enforces strict policies regarding targetSdkVersion. To submit or update an app on the Google Play Store, developers must target a recent Android version (usually within one year of the latest major Android release).

Failing to keep your TWA wrapper updated to the required targetSdkVersion will prevent you from uploading new builds or releasing patches. Fortunately, updating the targetSdkVersion inside your TWA wrapper does not alter your web code. It simply tells the Android system that your wrapper is fully compliant with modern security frameworks, permission models, and background execution limits enforced by the latest Android OS.

Filtering Devices via Hardware Feature Declarations

Some PWAs rely heavily on native device capabilities that are exposed through advanced web APIs, such as the Web NFC API, WebUSB, Web Bluetooth, or the Gamepad API. If your PWA depends on these features to provide its core value, allowing users to install your app on devices that lack the physical hardware will lead to frustration.

You can restrict installation to devices with specific hardware capabilities by adding the uses-feature tag to your TWA's AndroidManifest.xml. For example, if your app requires a physical camera for a web-based barcode scanner, you can declare this dependency natively:

<uses-feature android:name="android.hardware.camera" android:required="true" />

If your web application can fall back to manual input when a camera is missing, you should set the required attribute to false. This informs the Google Play Store that the feature is used but is not mandatory for installation:

<uses-feature android:name="android.hardware.camera" android:required="false" />

TWA Compatibility and Capabilities by Android Version

To help select the optimal baseline for your TWA, consult this breakdown of Android API levels and their corresponding web engine support:

Addressing RAM and System Performance Constraints

If your PWA is resource-intensive—for example, a 3D canvas game built with WebGL or a data-heavy dashboard running heavy WebAssembly modules—low-end devices with 1GB or 2GB of RAM will struggle to run your TWA smoothly. Chrome may repeatedly terminate the background service worker or crash the main page context due to out-of-memory errors.

While you cannot directly specify a RAM minimum via a simple manifest property, you can use the Google Play Console's Device Catalog. Once you have uploaded your TWA Android App Bundle (AAB), you can filter out specific device profiles, low-RAM devices, or specific system-on-chip architectures. Combining native manifest limits (minSdkVersion) with manual device exclusions in the Google Play Console provides the ultimate control over your target demographic, ensuring that only users with capable hardware can discover and install your app.