[Bug]: requestPermission() resolves before the Android location-settings dialog is answered
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 52/100
Research direction
Start by tracing BackgroundGeolocation.requestPermission(Permission.location) and the Android TSLocationManagerActivity flow described in the issue, especially when the location-settings dialog is launched after the permission callback. Compare that behavior with the requestPermission documentation and GeoConfig.disableLocationAuthorizationAlert. Done means the caller can determine whether the user accepted or declined the settings dialog, or the issue has a documented recommended way to do so.
Written by the indexing model from the issue text.
Description
Required Reading
- Confirmed
Plugin Version
5.9.0
Flutter Doctor
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 3.47.8, on Microsoft Windows [Version 10.0.26300.9711], locale en-GB)
[√] Windows Version (Windows 11 or higher, 26H2, 2009)
[√] Android toolchain - develop for Android devices (Android SDK version 36.0.0)
[√] Chrome - develop for the web
[√] Visual Studio - develop Windows apps (Visual Studio Build Tools 2026 18.10.3)
[√] Connected device (3 available)
[√] Network resources
• No issues found!
Mobile operating-system(s)
- iOS
- Android
Device Manufacturer(s) and Model(s)
NA
Device operating-systems(s)
NA
What happened?
When requestPermission(Permission.location) triggers the Android location-settings resolution dialog ("Turn on device location?"), the app has no way to know the user's answer.
Actual: the Future resolves with the authorization status as soon as the permission is granted (or immediately if already granted). The location-settings dialog is launched only afterwards (TSLocationManagerActivity, action "locationsettings", started after the permission callback's onSuccess). The requestPermission docs don't mention this dialog; it's only listed under GeoConfig.disableLocationAuthorizationAlert.
Expected: either the Future settles only after the settings dialog is answered (rejecting or reporting when the user declines), or a dedicated method (e.g. requestLocationSettings()) returns whether location services were enabled.
Steps to reproduce:
- Turn off device location services.
- Call
await BackgroundGeolocation.requestPermission(Permission.location). - The Future resolves with AUTHORIZATION_STATUS_WHEN_IN_USE, then the "Turn on device location?" dialog appears.
- Decline the dialog: nothing reports it to the caller.
Context: we replaced the location package (whose requestService() returns a bool) with this plugin. Our "show my location" toggle used to require location services before turning on, and showed a message when the user declined. onProviderChange can't be correlated with a specific request, and doesn't fire on decline since nothing changes. Is there a recommended way to await the location-settings resolution result?
Plugin Code and/or Config
await BackgroundGeolocation.ready(Config(
geolocation: GeoConfig(
desiredAccuracy: DesiredAccuracy.high,
locationAuthorizationRequest: 'WhenInUse',
),
app: AppConfig(stopOnTerminate: true, startOnBoot: false),
activity: ActivityConfig(disableMotionActivityUpdates: true),
logger: LoggerConfig(logLevel: LogLevel.info),
));
// Later, when the user enables "show my location":
try {
await BackgroundGeolocation.requestPermission(Permission.location);
// Resolves here, before the location-settings dialog is answered
} on int catch (status) {
// Denied
}
Relevant log output
- Dominant language
- Dart
- Stars
- 732
- Forks
- 287
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from transistorsoft/flutter_background_geolocation
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
transistorsoft/flutter_background_geolocation#1724 · 2 comments ·
-
[Bug]: tslocationmanager still depends on bcprov-jdk15to18 1.84 (CVE-2026-8763, CVE-2026-13506)Openbug
Difficulty 3/5 1-2 days Newbie friendliness 54/100
transistorsoft/flutter_background_geolocation#1725 · 1 comment ·
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 55/100
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
transistorsoft/flutter_background_geolocation#1721 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 8/100
transistorsoft/flutter_background_geolocation#1719 · 8 comments ·
All issues in transistorsoft/flutter_background_geolocation
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
google/skills_lint.dart#165 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
good first issue help wanted translation
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
blankframe-tech/ThrottleIQ#23 ·
Maintainers usually reply within 5 days
-
good first issue mobile P0 size:S
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 69/100
trufi-association/trufi-core#1024 ·
Maintainers usually reply within 14 days