Google Play Permissions
The SDK contributes a handful of permissions to your merged manifest, some of which Google Play gates behind a declaration form or acceptable-use consent. This guide lists them, shows how to strip the ones you don't use, and explains what to file when you keep them.
Overview
The SDK declares its permissions in card-sdk/AndroidManifest.xml. Every app that includes the SDK inherits them via manifest merger. A few are permissions that Google Play gates behind a declaration form or acceptable-use consent — when present in your merged manifest, Play Console asks you to justify them (or rejects the release if your app category isn't eligible).
You don't fork or edit the SDK
If your build doesn't use the feature behind such a permission, strip it from the merged manifest with a tools:node="remove" override in your app's AndroidManifest.xml. The override must live in the consumer app manifest — it has higher merge priority than the SDK library manifest.
Play-gated Permissions
These four permissions trigger a Google Play declaration, consent, or eligibility check when they appear in your merged manifest.
| Permission | Play gate | SDK feature behind it | Safe to remove when… |
|---|---|---|---|
| SCHEDULE_EXACT_ALARM | Exact-alarm declaration | Fires end-of-day scheduled reconciliation at the exact configured HHmm | You don't use scheduled reconciliation, or accept it firing up to ~1 h late (falls back to inexact alarms) |
| REQUEST_IGNORE_BATTERY_OPTIMIZATIONS | Restricted — only some app categories may ship it | One-tap "ignore battery optimizations" dialog used by the battery-reliability helper | You publish on Play and aren't in an eligible category — the helper falls back to a settings deep-link |
| ACCESS_FINE_LOCATION / ACCESS_COARSE_LOCATION | Location declaration / consent | Attaches merchant geolocation to login/transactions; feeds the "suspicious geolocation" security check | Your backend doesn't require transaction location — capture is best-effort, so login/payment still work without it |
| FOREGROUND_SERVICE_DATA_SYNC | Foreground-service-type declaration (required by Play since 2024) | On API < 31, lets the reconciliation worker run as a short dataSync foreground service (expedited fallback) | You don't need scheduled reconciliation, or only target API 31+ (expedited jobs don't use a foreground service there) |
Permissions to Leave Alone
Not gated — keep these
INTERNET, ACCESS_NETWORK_STATE, NFC, POST_NOTIFICATIONS (runtime prompt, no declaration), RECEIVE_BOOT_COMPLETED, and FOREGROUND_SERVICE (base) are not Play-gated. The SDK deliberately does NOT declare the Play-restricted variants QUERY_ALL_PACKAGES, USE_EXACT_ALARM, or USE_FULL_SCREEN_INTENT.
Removing One Permission
In your app module's src/main/AndroidManifest.xml, declare the tools namespace on <manifest>, then add a matching <uses-permission> with tools:node="remove". The android:name must match exactly; the merger deletes the inherited node.
Loading...Verify the merged manifest
Confirm the permission is gone from the merged output before you ship.
Loading...Remove All Gated Permissions
Drop this into your app manifest to strip everything Play would ask about. Remove only the lines whose feature you actually want to keep.
Loading...What Breaks When You Remove Each
SCHEDULE_EXACT_ALARM
canScheduleExactAlarms() is treated as false; reconciliation falls back to setAndAllowWhileIdle(...) and fires within a ~1-hour window instead of on the second. It still runs. Don't call EdfaPayPlugin.Utils.requestExactAlarmPermission(...) after removal (it becomes a no-op path).
REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
The one-tap ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS dialog is unavailable; EdfaPayPlugin.Utils battery/autostart helpers still work but deep-link the user to system settings instead. No functional loss for card payment.
ACCESS_FINE/COARSE_LOCATION
EdfaPayPlugin.Utils.currentLocation(...) returns nothing and EP.location stays null, so login/transaction payloads carry no coordinates and the geolocation security signal is inert. Confirm your acquirer/backend doesn't require transaction location before removing. Core NFC payment is unaffected.
FOREGROUND_SERVICE_DATA_SYNC
On API < 31 the reconciliation worker can no longer run its short dataSync foreground fallback for expedited execution; WorkManager runs it as ordinary (non-expedited) background work. On API 31+ there is no effect. Reconciliation still completes.
Keeping Them — Play Declarations
If you do need a feature, keep the permission and satisfy Google Play's requirements. Each gated permission needs a different combination of a Play Console declaration form, a runtime user consent, and a privacy-policy / Data safety disclosure. Where the form asks for a video, capture the actual in-app flow. Declarations are re-reviewed on each release that keeps the permission.
SCHEDULE_EXACT_ALARM
Play Console → App content → Permissions declaration → "Exact alarm". Choose the "Tasks the app has been asked to perform at an exact time" use case.
Runtime consent
Android 14+ has this denied by default. Prompt with EdfaPayPlugin.Utils.requestExactAlarmPermission(activity) { granted -> … } (shows a rationale + deep-links to the system "Alarms & reminders" screen). Re-check canScheduleExactAlarms(context) in onResume.
Data safety
None — no user data is collected by the permission itself.
Justification (paste)
Performs end-of-day payment reconciliation against our backend at the exact time configured by the merchant terminal. Inexact scheduling would fire the reconciliation up to an hour late, producing incorrect daily totals and reconciliation reports.
FOREGROUND_SERVICE_DATA_SYNC
Play Console → App content → Foreground service permissions declaration. Declare the dataSync type. Only relevant if you support API < 31; on API 31+ you can remove it and skip this declaration.
Justification (paste)
A short (~10s) dataSync foreground task runs the merchant's scheduled end-of-day reconciliation sync with our backend on Android 11 and below, where WorkManager executes expedited work as a foreground service. It is user-visible via an ongoing notification and is not used for long-running or continuous work.
ACCESS_FINE_LOCATION / ACCESS_COARSE_LOCATION
Play Console → App content → Permissions declaration → "Location". Declare foreground (approximate/precise) use — the SDK does NOT request background location.
Runtime consent (required)
Request at runtime before use — EdfaPayPlugin.Utils.requestLocationPermission(activity) { granted -> … }. The SDK treats a denial as best-effort (no coordinates attached); do not hard-gate payment on it.
Justification + mandatory disclosure
Justification: "Captures the merchant device's location at login and at transaction time to attach geolocation to payment records for fraud/risk screening (an anti-fraud requirement of our acquirer). Location is used in the foreground only, tied to an active payment session." Location is a sensitive data type — a linked privacy policy and a Data safety disclosure (Location → Approximate/Precise) are mandatory when this permission ships.
REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
No declaration form — Play evaluates it against the acceptable-use policy. It's only permitted for a narrow set of use cases (e.g. companion-device/always-on apps); a payment app is generally not eligible, and shipping it can get the release rejected.
Recommendation
For Play distribution, remove it and rely on the settings deep-link fallback in the battery/autostart helpers. Keep it only for enterprise / sideloaded builds. If you believe your app qualifies, be ready to justify it in the review-appeal flow; there is no pre-submission form.
Quick Matrix
| Permission | Console declaration | Runtime consent | Privacy policy / Data safety |
|---|---|---|---|
| SCHEDULE_EXACT_ALARM | Exact-alarm declaration | Yes (Android 14+) | — |
| FOREGROUND_SERVICE_DATA_SYNC | Foreground-service (dataSync) | — | — |
| ACCESS_FINE/COARSE_LOCATION | Location declaration | Yes | Yes (Location) |
| REQUEST_IGNORE_BATTERY_OPTIMIZATIONS | None (policy-evaluated) | System dialog | — |
On this page
Downloads
Coming SoonSample apps, release bundles, and more content will be available here soon.