request Permission
Backwards-compat API: request and ignore status (logs it)
Requests the specified permission.
This function will suspend until the user grants or denies the permission. If the permission is already granted, this function will return immediately.
Platform behavior
iOS: Throws IllegalStateException when the consumer app's
Info.plistis missing the required usage description key for the requested permission (e.g.NSLocationWhenInUseUsageDescriptionforFINE_LOCATION, plusNSLocationAlwaysAndWhenInUseUsageDescriptionforBACKGROUND_LOCATION). iOS silently ignores requests with missing keys, so the SDK surfaces the misconfiguration immediately rather than as a phantom "denied" status with no system prompt.iOS — "Allow Once" (iOS 14+): when the user picks "Allow Once" on the location prompt, the granted state lasts only for the current app session. iOS reverts the status to
NOT_DETERMINEDon the next launch with no callback or notification. Re-check permission status on every launch andviewWillAppearrather than caching across sessions; calling requestPermission again will re-prompt as expected.iOS — Reduced Accuracy (iOS 14+): when the user grants location with "Precise Location" off, iOS fuzzes the device location to ~1–5 km. For a
FINE_LOCATIONrequest this is reported as PermissionStatus.REDUCED_ACCURACY (notGRANTED) so consumers can prompt the user to enable Precise Location in Settings. Geofencing with small radii is unreliable in this state;isLocationAccuracyReduced()reports the same condition as a boolean.Android — Approximate location (Android 12+): when the user downgrades a
FINE_LOCATIONrequest to "Approximate", the OS grantsACCESS_COARSE_LOCATIONbut notACCESS_FINE_LOCATION; this is reported as PermissionStatus.REDUCED_ACCURACY (notDENIED) — the Android counterpart to iOS reduced accuracy.Android: Does not throw on missing
<uses-permission>declarations inAndroidManifest.xml— the underlying request is simply rejected by the OS, and the result returns asDENIED(or staysNOT_DETERMINED). Verify your manifest contains the required permissions before calling this method.
Return
The resulting PermissionStatus after the user responds (or the current status if the permission was already granted).
Parameters
The permission to request.
Throws
if an error occurs during the permission request process. This could be due to various reasons, such as the permission being permanently denied by the user or an issue with the underlying platform's permission system.
Requests the specified permission.
This function will suspend until the user grants or denies the permission. If the permission is already granted, this function will return immediately.
Platform behavior
iOS: Throws IllegalStateException when the consumer app's
Info.plistis missing the required usage description key for the requested permission (e.g.NSLocationWhenInUseUsageDescriptionforFINE_LOCATION, plusNSLocationAlwaysAndWhenInUseUsageDescriptionforBACKGROUND_LOCATION). iOS silently ignores requests with missing keys, so the SDK surfaces the misconfiguration immediately rather than as a phantom "denied" status with no system prompt.iOS — "Allow Once" (iOS 14+): when the user picks "Allow Once" on the location prompt, the granted state lasts only for the current app session. iOS reverts the status to
NOT_DETERMINEDon the next launch with no callback or notification. Re-check permission status on every launch andviewWillAppearrather than caching across sessions; calling requestPermission again will re-prompt as expected.iOS — Reduced Accuracy (iOS 14+): when the user grants location with "Precise Location" off, iOS fuzzes the device location to ~1–5 km. For a
FINE_LOCATIONrequest this is reported as PermissionStatus.REDUCED_ACCURACY (notGRANTED) so consumers can prompt the user to enable Precise Location in Settings. Geofencing with small radii is unreliable in this state;isLocationAccuracyReduced()reports the same condition as a boolean.Android — Approximate location (Android 12+): when the user downgrades a
FINE_LOCATIONrequest to "Approximate", the OS grantsACCESS_COARSE_LOCATIONbut notACCESS_FINE_LOCATION; this is reported as PermissionStatus.REDUCED_ACCURACY (notDENIED) — the Android counterpart to iOS reduced accuracy.Android: Does not throw on missing
<uses-permission>declarations inAndroidManifest.xml— the underlying request is simply rejected by the OS, and the result returns asDENIED(or staysNOT_DETERMINED). Verify your manifest contains the required permissions before calling this method.
Return
The resulting PermissionStatus after the user responds (or the current status if the permission was already granted).
Parameters
The permission to request.
Throws
if an error occurs during the permission request process. This could be due to various reasons, such as the permission being permanently denied by the user or an issue with the underlying platform's permission system.