All articles

Guide

Managing Geolocation Permissions in Android TWA Apps

November 3, 2026 · 7 min read

For location-based web applications, such as delivery tracking services, real estate portals, or local directory platforms, access to geolocation is a core functional requirement. When running your web application inside a Trusted Web Activity, managing these permissions requires a clear understanding of how the Android operating system and the web browser coordinate to grant or deny access to the device GPS.

The Permission Delegation Model in TWAs

In a standard web browser, when a website calls the geolocation API, the browser displays a prompt asking the user for permission. In a standard Android app, the operating system manages permission prompts. A Trusted Web Activity bridges these two worlds using a mechanism called permission delegation.

When your TWA is correctly configured with verified Digital Asset Links, Chrome recognises that the native Android application shell and the web origin belong to the same entity. Because of this trust relationship, Chrome delegates the browser-level geolocation permission to the Android operating system. If the user has already granted location permissions to the native Android app, the web application running inside the TWA receives the location data instantly without displaying an additional browser prompt. This creates a native-feeling experience without double prompting the user.

Configuring the Android Manifest for Location Access

To enable geolocation delegation, you must first declare that your native Android application shell requires access to the device location. This is achieved by adding the appropriate permissions to your Android Manifest file. Without these declarations, the Android system will block the application from accessing the hardware GPS sensors.

You must include the following permissions in your manifest file: android.permission.ACCESS_COARSE_LOCATION for approximate location tracking via mobile tower and Wi-Fi data, and android.permission.ACCESS_FINE_LOCATION for precise hardware GPS tracking. In modern TWA configurations, these are declared as user permissions in the main XML structure.

Handling the Permission Request Flow

The permission request flow in a TWA follows a distinct sequence. When your web application invokes the standard geolocation API, the TWA wrapper checks if the Android app has been granted the system-level location permission. If it has not, the native wrapper initiates an Android system permission request dialog.

If the user grants the permission on the system dialog, the native app stores this preference, and Chrome passes the location data back to your JavaScript code. If the user denies the permission, the standard JavaScript error handler for geolocation is triggered. Your web code must be prepared to handle this denial gracefully, just as it would on a desktop browser.

Google Play Policies Regarding Location Access

When publishing an app that accesses geolocation to the Google Play Store, you must comply with strict developer policies. Google closely scrutinises applications that request access to sensitive data, and location tracking is one of the most protected categories. You must ensure your app complies with the following guidelines:

  • Prominent Disclosure: If your application accesses location data, you must provide a clear in-app disclosure explaining how the data is used. This disclosure must be displayed before the permission request is triggered.
  • Foreground vs Background: You should only request foreground location access. Background location tracking, which tracks the user when the app is closed, is rarely approved for TWA apps and requires completing a detailed declaration form in the Google Play Console.
  • Minimum Access: Only request precise location if your application cannot function with coarse location. For example, a weather app only needs coarse location, while a turn-by-turn navigation app requires fine location.

Implementing JavaScript Fallbacks for Location Request

Your web application should use the standard Geolocation API. To ensure a robust user experience, always check the permission status using the Permissions API before invoking the location finder. This allows you to show a custom, user-friendly UI explaining why your application needs location access before triggering the native system prompt.

The following table outlines the different permission states you must handle in your JavaScript codebase:

Permission StateUser Experience ImplicationRequired Web App Action
grantedThe user has approved location access at the system and browser level.Immediately invoke navigator.geolocation.getCurrentPosition() to retrieve coordinates.
promptThe user has not yet been asked, or permissions have been reset.Show an explanatory UI, then call the geolocation API to trigger the native prompt.
deniedThe user has blocked access either at the system level or within Chrome.Disable location-dependent features and show a message explaining how to enable permissions in Android settings.

Troubleshooting Location Issues in TWAs

If your TWA is failing to retrieve coordinates, the issue is almost always related to Digital Asset Links or system settings. First, verify that Digital Asset Links are properly configured and verified. If the asset links fail verification, the TWA will fallback to running as a standard Custom Tab without permission delegation. In this state, Chrome will display a browser-level address bar and will not share the system location with the web origin.

Second, ensure that location services are active on the test device. If the device GPS is turned off globally, or if Chrome has had its location permissions manually revoked in the Android system settings, the TWA will not be able to fetch coordinates, regardless of your manifest configuration or app permissions.

Ready to ship your Android app?

Paste your PWA URL, get a signed APK and a Google Play ready AAB in minutes.

Build my app