Permissions

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.

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:

<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />

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:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">
    <uses-permission android:name="android.permission.USE_BIOMETRIC" tools:node="remove" />
    <uses-permission android:name="android.permission.USE_FINGERPRINT" tools:node="remove" />
</manifest>

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

You enable Push under Playtolia → Features and pick a strategy.
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.
PlaytoliaNotifications.GetPermission() reports Granted, DeniedAlways, or NotGranted.
If the player denied the request, PlaytoliaNotifications.OpenNotificationSettings() opens the system settings so they can change their mind.

Push Notifications

Setup and permission strategies

Installation

Platform requirements

Get Started

Features

Billing

Advanced

Three kinds of permission

Android

Declared by the SDK

Merged from SDK dependencies

Requested at runtime

Not used

Removing a permission you do not want

iOS

Push permission flow

Push Notifications

Installation

​Three kinds of permission

​Android

​Declared by the SDK

​Merged from SDK dependencies

​Requested at runtime

​Not used

​Removing a permission you do not want

​iOS

​Push permission flow

Push Notifications

Installation

Three kinds of permission

Android

Declared by the SDK

Merged from SDK dependencies

Requested at runtime

Not used

Removing a permission you do not want

iOS

Push permission flow