requestPermission() hangs indefinitely - no promise resolution/rejection, no popup, no error (Expo + New Architecture)

[Gui-Dev86]

Environment

• Plugin version: 5.5.0
• Platform: Android
• Expo SDK with newArchEnabled: true (required, since react-native-reanimated and react-native-worklets both fail the build with assertNewArchitectureEnabledTask if disabled)
• Device: Samsung Galaxy S23+, Android 16
• Dev client build (npx expo run:android)

Issue

Calling BackgroundGeolocation.requestPermission(Permission.Location) hangs indefinitely — the returned promise never resolves nor rejects. No system permission popup ever appears. No error, warning, or log is emitted (with logLevel set to Verbose).

Execution simply stops at this call and never proceeds to .ready().

What I've tried (all with no effect on the hang)

• Installed and confirmed expo-gradle-ext-vars is correctly applied (googlePlayServicesLocationVersion visible in generated android/build.gradle)
• Tried different plugin ordering in app.config.js
• Manually revoked all location permissions via adb shell pm revoke before testing
• Fully uninstalled the app (adb uninstall) and rebuilt from scratch
• Temporarily removed the expo-location plugin entirely to rule out a conflict between the two location SDKs — same hang
• Tested .ready() with a minimal config (only logger.logLevel) after skipping requestPermission() entirely — .ready() itself also hangs the same way, with no popup and no log output

Config

plugins: [
  ...
  ['expo-gradle-ext-vars', { googlePlayServicesLocationVersion: '21.1.0' }],
  ['react-native-background-geolocation', {}],
],

BackgroundGeolocation.onLocation(...);
await BackgroundGeolocation.requestPermission(Permission.Location); // ← hangs here
await BackgroundGeolocation.ready({ ... });

Question

Is this a known issue with the v5 TurboModule (New Architecture) implementation? Since RN 0.82+ / Expo SDK 55 no longer allow disabling the New Architecture, I can't test against the legacy bridge to confirm.

[christocracy]

await BackgroundGeolocation.requestPermission(Permission.Location);

I didn't think people would discover the new requestPermission api so quickly, which has been modified to accept a Permission.Location / Permission.Motion as an argument. The plugin release that supports this has not yet been released (due for release today in 5.6.0).

You should remove Permission from your imports and usage for now.

[christocracy]

I just generated a fresh RN demo app using the AI Prompt. Everything functions as expected.

chris@studio:BGGeoDemo % cat package.json
{
  "name": "BGGeoDemo",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "android": "react-native run-android",
    "ios": "react-native run-ios",
    "lint": "eslint .",
    "start": "react-native start",
    "test": "jest"
  },
  "dependencies": {
    "@react-native/new-app-screen": "0.87.1",
    "react": "19.2.3",
    "react-native": "0.87.1",
    "react-native-background-geolocation": "^5.5.0",
    "react-native-safe-area-context": "^5.5.2"
  },
  "devDependencies": {
    "@babel/core": "^7.25.2",
    "@babel/preset-env": "^7.25.3",
    "@babel/runtime": "^7.25.0",
    "@react-native-community/cli": "20.2.0",
    "@react-native-community/cli-platform-android": "20.2.0",
    "@react-native-community/cli-platform-ios": "20.2.0",
    "@react-native/babel-preset": "0.87.1",
    "@react-native/eslint-config": "0.87.1",
    "@react-native/jest-preset": "0.87.1",
    "@react-native/metro-config": "0.87.1",
    "@react-native/typescript-config": "0.87.1",
    "@types/jest": "^29.5.13",
    "@types/react": "^19.2.0",
    "@types/react-test-renderer": "^19.1.0",
    "eslint": "^8.19.0",
    "jest": "^29.6.3",
    "prettier": "2.8.8",
    "react-test-renderer": "19.2.3",
    "typescript": "^6.0.3"
  },
  "engines": {
    "node": ">= 22.11.0"
  }
}

[christocracy]

Is this a known issue with the v5 TurboModule (New Architecture) implementation? Since RN 0.82+ / Expo SDK 55 no longer allow disabling the New Architecture, I can't test against the legacy bridge to confirm.

No. the plugin v5 fully supports TurboModules.

[Gui-Dev86]

Thanks for the quick clarification — removed the requestPermission argument as suggested.

That unblocked things, but now .ready() itself hangs the same way (no resolve/reject, no popup, no log output even with logLevel Verbose). Still investigating on my end to see if it's another config option issue, will update here once I've narrowed it down.

[christocracy]

show me the result of $ adb logcat "*:S" TSLocationManager:V of your app launching and .ready(config) being called.

[christocracy]

btw, I just released v5.6.0 with the new requestPermission(Permission) api.

[Gui-Dev86]

Thanks — will grab those logs now. In the meantime, I think I found the specific cause on my end: passing desiredAccuracy: DesiredAccuracy.High (the constant, -1) to .ready() causes the same silent hang as requestPermission. Using the raw numeric value -1 directly instead of the constant works fine. Might be another types/native desync like the Permission one?

Also, great timing on 5.6.0 — will update and retest with the proper requestPermission(Permission) API once I confirm the desiredAccuracy issue.

[christocracy]

Show the code you're using.

[christocracy]

This works for me:

import BackgroundGeolocation, {DesiredAccuracy} from 'react-native-background-geolocation';

.
.
.
const App = () => {
  
  React.useEffect(() => {
    alert('DesiredAccuracy: ' + DesiredAccuracy.High);
    .
    .
    .
}

[Gui-Dev86]

Sure — here's the exact code that hangs:

await BackgroundGeolocation.ready({
  geolocation: {
    desiredAccuracy: DesiredAccuracy.High,
    distanceFilter: 5,
    locationUpdateInterval: 5000,
  },
  app: {
    stopOnTerminate: false,
    startOnBoot: true,
    heartbeatInterval: 30,
    notification: {
      title: 'Tracking actif',
      text: 'Sharing location in real-time',
    },
  },
  logger: {
    logLevel: LogLevel.Off,
  },
});

Confirmed DesiredAccuracy.High resolves to -1 (logged it before the call). Replacing just that one line with a raw desiredAccuracy: -1 makes .ready() resolve immediately. Everything else in the config stays identical between the two tests.

[christocracy]

show me your import statement

[Gui-Dev86]

import BackgroundGeolocation, { DesiredAccuracy, LogLevel } from 'react-native-background-geolocation';

[Gui-Dev86]

Separately, regarding the background persistence issue I mentioned earlier: I found the root cause in logcat — it's Samsung's proprietary "Freecess" (Freeze Process) mechanism specific to One UI, not standard Android Doze. It freezes the process (ActivityManager: freezing <pid> com.guidev86.Sparo) even with the foreground service correctly typed as location, causing FusedLocationProvider registration to fail shortly after. This seems to be a Samsung OEM-level restriction rather than an SDK issue on your end — just flagging it here in case it's useful to others hitting the same wall on Samsung devices.

[christocracy]

I have no explanation for that hanging. I've never heard of that before.

Your code works for me.

[christocracy]

One of my many test devices is a Samsung S25 @ Android 16 (OneUI 8.5).

It works reliably.