Location Delegation

[david-buck]

Describe the bug
In our production build of the TWA (installed via the Play Store), geolocation delegation fails on certain devices—even when location permission is set to "ask every time." Although the app works correctly when installed via ADB (using Bubblewrap), the production version never shows the location prompt, and the geolocation lookup fails. Logcat indicates that the "ask every time" setting is being misinterpreted, leading to Chrome blocking the launch of the PermissionRequestActivity.
Steps to reproduce the behavior:

Install the production build of the TWA from the Play Store on a device (e.g., Samsung S25).

Set the location permission for the app to "ask every time" in the device settings.

Navigate to a URL that triggers a geolocation request.

Observe that the location prompt does not appear, and the geolocation lookup fails.

Check Logcat for the following error logs related to the delegation process.

Expected behavior
When the location permission is set to "ask every time," the TWA should trigger a native prompt via the DelegationService (PermissionRequestActivity), allowing the user to grant geolocation access. Once granted, geolocation (e.g., through Mapbox's GeolocateControl) should work as expected.

Did this ever used to work
Yes—when installing the app via ADB (using Bubblewrap install), geolocation delegation works correctly. This issue appears to be specific to the production builds (Play Store installation) and affects only some devices.

Emulated Pixel device logcat with "Ask every time" set

2025-04-01 11:12:35.247   633-2436  ActivityTaskManager     system_server                        E  Background activity launch blocked! goo.gle/android-bal [callingPackage: nz.catchy.twa; callingPackageTargetSdk: 35; callingUid: 10213; callingPid: 30072; appSwitchState: 2; callingUidHasVisibleActivity: false; callingUidHasNonAppVisibleWindow: false; callingUidProcState: BOUND_TOP; isCallingUidPersistentSystemProcess: false; allowBalExemptionForSystemProcess: false; intent: Intent { flg=0x10000000 xflg=0x4 cmp=nz.catchy.twa/com.google.androidbrowserhelper.locationdelegation.PermissionRequestActivity (has extras) }; callerApp: ProcessRecord{16f78d3 30072:nz.catchy.twa/u0a213}; inVisibleTask: false; balAllowedByPiCreator: BSP.ALLOW_BAL; balAllowedByPiCreatorWithHardening: BSP.ALLOW_BAL; resultIfPiCreatorAllowsBal: BAL_BLOCK; callerStartMode: MODE_BACKGROUND_ACTIVITY_START_SYSTEM_DEFINED; hasRealCaller: true; isCallForResult: false; isPendingIntent: false; autoOptInReason: notPendingIntent; realCallingPackage: nz.catchy.twa; realCallingPackageTargetSdk: 35; realCallingUid: 10213; realCallingPid: 30072; realCallingUidHasVisibleActivity: false; realCallingUidHasNonAppVisibleWindow: false; realCallingUidProcState: BOUND_TOP; isRealCallingUidPersistentSystemProcess: false; originatingPendingIntent: null; realCallerApp: ProcessRecord{16f78d3 30072:nz.catchy.twa/u0a213}; realInVisibleTask: false; balAllowedByPiSender: BSP.ALLOW_BAL; resultIfPiSenderAllowsBal: BAL_BLOCK; realCallerStartMode: MODE_BACKGROUND_ACTIVITY_START_SYSTEM_DEFINED; balRequireOptInByPendingIntentCreator: true; balDontBringExistingBackgroundTaskStackToFg: true]
2025-04-01 11:12:35.254   633-2436  ActivityTaskManager     system_server                        I  START u0 {flg=0x10000000 xflg=0x4 cmp=nz.catchy.twa/com.google.androidbrowserhelper.locationdelegation.PermissionRequestActivity (has extras)} with LAUNCH_MULTIPLE from uid 10213 (BAL_BLOCK) result code=102

With permission changed to "allow":

2025-04-01 11:15:30.254   633-692   ActivityManager         system_server                        I  Start proc 30758:nz.catchy.twa/u0a213 for service {nz.catchy.twa/nz.catchy.twa.DelegationService}
2025-04-01 11:15:30.289 30758-30758 nz.catchy.twa           pid-30758                            I  Using CollectorTypeCMC GC.

On the device where the delegation never works, there is never even a note in the logcat that the delegation has been requested.

As a secondary thing, changing the setting away from "allow" seems to crash the delegation server

2025-04-01 11:18:30.876  1339-1339  AppPermissionViewModel  com....android.permissioncontroller  I  Permission changed via UI with sessionId=-1809598749459670823 changeId=4150078943389565315 uid=10213 packageName=nz.catchy.twa permission=android.permission.ACCESS_COARSE_LOCATION isGranted=false permissionFlags=66304 buttonPressed=3
2025-04-01 11:18:30.879   633-717   ActivityManager         system_server                        W  Scheduling restart of crashed service nz.catchy.twa/.DelegationService in 1000ms for connection
2025-04-01 11:18:30.888   633-2436  ActivityManager         system_server                        V  Got obituary of 30758:nz.catchy.twa

Smartphone (please complete the following information):

Device: Samsung S25 (example)
OS: Android 13
Browsers Installed: Chrome, Brave, Samsung Internet
Browser Versions: Chrome 134.0.6998.135

android-browser-helper library version: Whatever bubblewrap uses

Additional context
Even when location permission is pre-granted or set to "ask every time," the delegation mechanism in ABH (used by our TWA) never triggers the PermissionRequestActivity. This seems to be a bug where, in production builds (from the Play Store), Chrome fails to properly invoke the DelegationService for geolocation requests, causing Mapbox’s geolocation (or any geolocation API call) to silently fail. This bug can be reproduced more predictably by forcing the location permission prompt setting to "ask every time."

[david-buck]

Updating to Chrome 134.0.6998.136 seems to fix at least some of this issue.