--- title: Permissions description: Understanding and Checking Android notification permissions next: /react-native/docs/android/progress-indicators previous: /react-native/docs/android/interaction --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.page/marcocrupi/react-native-notify-kit/llms.txt > Use this file to discover all available pages before exploring further. ## Understanding permissions On Android 13+, notifications are blocked by default and you will need to present a runtime permission dialog to the user. You have to target at least SDK 33 to perform a runtime request on Android 13+. The permission is always granted for prior versions. A user may revoke the permissions later through various means. In addition, a user may manage or revoke permissions at any of three levels; application-wide, channel groups and channels. ## Requesting permissions To get started and request notification permission from your users, call the [`requestPermission`](/react-native/reference/requestpermission) method. If the user declines the permission, Android prevents the permission dialog from being displayed again. This allows the users of your application full control of how notifications are handled: - If the user declines the runtime permission dialog, they must manually allow notifications via the device Settings UI for your application. - If the user accepts the runtime permission dialog, notifications will be shown using the settings requested (e.g. with or without sound). If `POST_NOTIFICATIONS` is not granted on Android 13+, calls that post notifications, such as `displayNotification()` and trigger-display paths, can fail safely before Android's `notify()` call. In that case Notify Kit does not emit a `DELIVERED` event, because no notification was posted. The following example shows how to trigger a permission dialog: ```js import notifee, { AuthorizationStatus } from 'react-native-notify-kit'; async function requestUserPermission() { const settings = await notifee.requestPermission(); if (settings.authorizationStatus >= AuthorizationStatus.AUTHORIZED) { console.log('Permission settings:', settings); } else { console.log('User declined permissions'); } } ``` ## Checking permissions For each level, you can check whether notifications are permitted through a direct Notify Kit API call, or listen for changes with event listeners. ### Application wide To check whether the user has enabled notifications for your app, call [`getNotificationSettings`](/react-native/reference/getnotificationsettings). The `authorizationStatus` attribute returns `AUTHORIZED` when notifications are enabled and `DENIED` when the permission is not granted after the permission request flow has run. On Android 13+ (`POST_NOTIFICATIONS` runtime permission), a fresh install can return `AuthorizationStatus.NOT_DETERMINED` before `requestPermission()` has been called. After the permission request flow has run, a non-granted permission is reported as `AuthorizationStatus.DENIED`. This existing distinction uses Notify Kit's persistent request history, rather than Android permission flags. It does not prove the user saw or denied a dialog, or that a future dialog is impossible; interrupted requests, permission resets and settings changes can differ from that history. ```js import notifee, { AuthorizationStatus } from 'react-native-notify-kit'; async function checkNotificationPermission() { const settings = await notifee.getNotificationSettings(); if (settings.authorizationStatus == AuthorizationStatus.AUTHORIZED) { console.log('Notification permissions has been authorized'); } else if (settings.authorizationStatus == AuthorizationStatus.DENIED) { console.log('Notification permissions has been denied'); } } ``` If you determine notifications are disabled, you may want to offer the user the ability to open notification settings to enable it. The [`openNotificationSettings`](/react-native/reference/opennotificationsettings) API may be used to implement this feature. ### Explaining a permission request [`shouldShowRequestPermissionRationale`](/react-native/reference/Interface.ModuleWithStatics#shouldshowrequestpermissionrationale) queries whether Android currently recommends showing explanatory UI before requesting `POST_NOTIFICATIONS`. It does not request permission, open settings or update request history. Each call reads current platform state. - On Android 13+ (API 33+) with a current Activity, it returns the Activity's platform recommendation. - On Android 13+ without a current Activity, it rejects with `ERR_NO_ACTIVITY`. Retry when the app has an Activity. Other native query failures also reject, rather than becoming `false`. - On Android below API 33 and on other platforms, it resolves `false` because this query is not applicable. `true` means Android recommends an explanation. `false` does **not** prove permanent denial or predict whether another permission dialog will appear: it can occur before an initial request, when permission is granted, or when rationale is not recommended after denial. Combining it with `DENIED`, `NOT_DETERMINED` or local request history does not establish dialog eligibility. For example, in a user-initiated notification opt-in flow on Android 13+: ```js async function requestNotificationsFromActivity(showExplanation) { const settings = await notifee.getNotificationSettings(); if (settings.authorizationStatus === AuthorizationStatus.AUTHORIZED) return settings; if (await notifee.shouldShowRequestPermissionRationale()) { // Your UI should let the user continue or decline. if (!(await showExplanation())) return settings; } // A false rationale result is not a reason to skip this user-initiated request. // Android controls whether a system dialog is shown. return notifee.requestPermission(); } ``` Handle rejected queries in the calling UI; an unavailable Activity is not a negative platform recommendation. Recheck settings and rationale after returning from Settings. Offer `openNotificationSettings()` as a user choice when appropriate, without treating `false` as proof that Settings is the only option. Android's [rationale API]() provides a UI recommendation, not a dialog counter. The [notification permission rules](https://developer.android.com/develop/ui/views/notifications/notification-permission) depend on the OS, target SDK, manifest declarations and system policy. In particular, apps targeting API 32 or lower have system-controlled prompt timing and different denial behavior; there is no universal two-dialog guarantee. The query forwards Android's result even if `POST_NOTIFICATIONS` is missing from the merged manifest; it neither validates nor adds the declaration. A negative result does not prove the app is configured correctly. ### Channels & Channels Groups To check whether the user has enabled notifications for specific channels or channel groups, call either [`getChannel`](/react-native/reference/getchannel) or [`getChannelGroups`](/react-native/reference/getchannelgroups). Both of these functions will return a respective object with `blocked` attributes in it. ```js import notifee from 'react-native-notify-kit'; async function checkChannelPermission() { const channel = await notifee.getChannel(); if (channel.blocked) { console.log('Channel is disabled'); } else { console.log('Channel is enabled'); } } ``` > For more understanding on channels, you can refer to the [Channels & Groups](/react-native/android/channels) documentation. ### Permission events For listening to permission change events, refer to the [Listening to channel events](/react-native/android/channels#listening-to-channel-events) documentation.