> ## Documentation Index
> Fetch the complete documentation index at: https://docs.playtolia.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Permissions
> What the Playtolia SDK declares, what it asks the player for, and what it leaves to your game.
The SDK keeps its permission footprint small on purpose. It declares one Android permission of its
own, asks the player for exactly one runtime permission (notifications), and never requests
restricted permissions that trigger a Google Play or App Store policy declaration. Everything
else comes from your game or from Firebase.
### Three kinds of permission
* **Declared permissions** live in the Android manifest. They merge into your game's APK at build
time. iOS has no equivalent: capabilities are set on the Xcode project and privacy prompts are
configured with `Info.plist` keys.
* **Runtime permissions** are the dialogs the operating system shows to the player. The SDK only
ever asks for notification permission, and only when you enable Push.
* **Restricted permissions** are the ones the stores ask you to justify (exact alarms, location,
all-packages queries, and so on). The SDK uses none.
### Android
#### Declared by the SDK
| Permission | Purpose |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `RECEIVE_BOOT_COMPLETED` | Android drops every pending alarm on reboot. The SDK listens for boot and re-arms the local notifications it scheduled, so reminders still fire after a restart. This is a normal permission with no store policy attached. |
#### Merged from SDK dependencies
These are not in the SDK manifest, but the Android manifest merger pulls them in from the
libraries the SDK depends on. They appear in your APK whether or not you use the feature.
| Permission | Source | Purpose |
| ------------------------------------------------------------------------ | -------------------- | -------------------------------------------------------------------------------------------------- |
| `INTERNET` | Network libraries | All API calls |
| `ACCESS_NETWORK_STATE` | Network libraries | Pausing sync while offline |
| `USE_BIOMETRIC`, `USE_FINGERPRINT` | AndroidX Credentials | Google sign-in and passkeys pull in the biometric library. The SDK does not use biometrics itself. |
| `com.android.vending.BILLING` | Google Play Billing | In-app purchases |
| `com.google.android.finsky.permission.BIND_GET_INSTALL_REFERRER_SERVICE` | Install Referrer | Install attribution |
None of these require a declaration form in the Play Console.
#### Requested at runtime
| Permission | When |
| ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| `POST_NOTIFICATIONS` (Android 13+) | When Push is enabled, at the moment set by your permission strategy. See [Push Notifications](/for-unity/push-notifications). |
The SDK requests this permission but does not declare it. Your game's merged manifest must
contain it, or Android 13+ denies the request without showing a dialog. The Firebase Cloud
Messaging Unity package declares it. If the prompt never appears, add this line to
`Assets/Plugins/Android/AndroidManifest.xml`:
```xml theme={null}
```
#### Not used
The SDK does not declare or request camera, location, contacts, storage, `QUERY_ALL_PACKAGES`,
`SCHEDULE_EXACT_ALARM`, or `USE_EXACT_ALARM`. Image attachments (support tickets, avatars) use
the system photo picker, which needs no permission.
**Exact alarms.** Local notifications scheduled by the SDK use inexact alarms, so delivery can
drift by a few minutes while the device is in Doze. This is deliberate: Google Play restricts
`USE_EXACT_ALARM` to alarm, clock, and calendar apps, and declaring it would force an exact-alarm
policy declaration on every game. If your game qualifies, declare `SCHEDULE_EXACT_ALARM` in your
own manifest and the SDK uses exact alarms automatically once the permission is granted.
#### Removing a permission you do not want
Because permissions merge, you can strip any of them from your APK with a `tools:node="remove"`
entry in your game's manifest. For example, if you do not use Google sign-in and want the
biometric permissions gone:
```xml theme={null}
```
Removing `INTERNET`, `ACCESS_NETWORK_STATE`, or `BILLING` breaks the corresponding features.
### iOS
The SDK needs no `Info.plist` usage-description keys. It does not access the camera, photo
library, location, contacts, or tracking APIs. Image attachments use the system photo picker,
which requires no key.
| Item | Where it is set | Purpose |
| --------------------------------------------------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------------ |
| Notification permission | Runtime prompt from the SDK | Same strategy setting as Android. iOS shows the system dialog once; later requests return the stored answer. |
| Push Notifications capability and `aps-environment` entitlement | Your Xcode project | Required for remote push. The Firebase setup for iOS covers this. |
| Background Modes: Remote notifications | Your Xcode project | Optional. Lets Firebase deliver data-only messages in the background. |
### Push permission flow
1. You enable Push under **Playtolia → Features** and pick a strategy.
2. At the chosen moment the SDK asks the operating system. On Android 13+ this is
`POST_NOTIFICATIONS`; on iOS it is the standard notification prompt. Older Android versions
need no prompt.
3. `PlaytoliaNotifications.GetPermission()` reports `Granted`, `DeniedAlways`, or `NotGranted`.
4. If the player denied the request, `PlaytoliaNotifications.OpenNotificationSettings()` opens
the system settings so they can change their mind.
Setup and permission strategies
Platform requirements