Publish to Google Play with Shernova

Who needs this guide

This guide applies when you use shernova_ui (^2.2.0+) with verifyPhone() on Android. shernova_core alone (headless, no auto-return) does not merge the native permissions below — you still need a privacy policy and Data safety form, but Play Console may not ask for foreground-service declarations.

Shernova's optional UI uses official Android APIs to monitor the verification call and restore your app automatically after the user hangs up. Google Play may require you to declare these capabilities before your app is approved. This is normal for production apps and does not mean Shernova violates Play policies when used as documented.

Why Google Play asks for a declaration

Google restricts sensitive permissions and foreground services (FGS) to reduce background abuse. When your APK or AAB merges permissions such as FOREGROUND_SERVICE, READ_PHONE_STATE, or CALL_PHONE, Play Console prompts you to explain why your app needs them and when they are used.

Foreground service — Android requires apps to show a visible notification while a service runs in the foreground. Shernova starts this service only during an active phone verification session.
Phone state — Shernova listens for call-state changes to detect when the verification call ends so the user can return to your app without manual steps.
Call phone (optional) — If the user grants it, Shernova can place the verification call directly (ACTION_CALL) instead of opening the dialer. If denied, the dialer opens instead (ACTION_DIAL).

When the request appears

First upload of a build that includes shernova_ui 2.2.0+ (permissions are merged from the plugin manifest).
App content → Sensitive app permissions — Phone / SMS permissions form and Foreground service permissions.
Policy review — Google may open a manual review thread and ask for a short video demonstrating the verification flow (this happened with production apps using Shernova and was accepted).
Updates — Usually no re-declaration unless you add new permission types or change FGS type.

Permissions merged by shernova_ui

Permission	Purpose	Play Console action
READ_PHONE_STATE	Detect verification call end	Declare in Phone permissions / Data safety
FOREGROUND_SERVICE + DATA_SYNC type	Keep call monitoring alive while dialer is open	Foreground service declaration
CALL_PHONE	Optional direct call (fallback: dialer)	Sensitive permission declaration if used
POST_NOTIFICATIONS	FGS notification channel (Android 13+)	Runtime prompt; usually no special form
REORDER_TASKS	Bring your app back to foreground after call	Normal permission — no declaration
WAKE_LOCK	Short wake during return transition	Normal permission — no declaration

Tablets and devices without telephony

From shernova_ui 2.3.1+, android.hardware.telephony is required=false, so your Play listing is not limited to phones only. Phone verification still requires a device that can place a call.

Why Shernova is compatible with Google Play policies

User-initiated verification — The user explicitly starts phone verification in your app; Shernova does not run continuous background processing.
Time-limited FGS — VerificationListenService starts when verification begins and stops when the session completes, is cancelled, or the user leaves the flow.
Official APIs only — Telephony callbacks, polling, ACTION_CALL / ACTION_DIAL, and task reordering. No call-log scraping, no hidden SMS, no full-screen intent abuse (removed in 2.3.1).
No call recording — Shernova does not record or store call audio. Only the gateway matches the caller number to the session.
Legitimate use case — Phone number verification is a standard app feature; declarations explain the narrow scope to reviewers.

How to complete the declaration

Foreground service declaration

In Play Console → App content → Foreground service permissions, select the type that matches your merged manifest (Data sync / FOREGROUND_SERVICE_DATA_SYNC). Use the declaration text below (already accepted by Google Play for a production Shernova integrator).

Ready-made declaration (English — accepted template)

The app uses a foreground service only during phone number verification. The service monitors the verification call state and automatically returns the user to the app after the call ends. It starts immediately when verification begins and stops as soon as the verification process is completed. The service is not used for continuous background processing.

Accuracy check (shernova_ui 2.3.1)

This text matches the current SDK: FGS runs only during verifyPhone(), monitors call state via telephony + short polling, attempts silent auto-return (no heads-up “returning” notification since 2.2.1), and stops the service when verification finishes. No change required unless you customize native behavior.

Phone / READ_PHONE_STATE

State that phone state is read only during active verification to detect when the user ends the verification call. Shernova does not read the user's call history or contacts.

Optional addition for phone permissions form

READ_PHONE_STATE is used only during phone number verification to detect when the verification call ends. The app does not access call logs or contacts.

CALL_PHONE (if prompted separately)

Optional CALL_PHONE declaration

CALL_PHONE is used only when the user taps "Call to verify" during phone number verification, to place a single outbound call to the verification gateway number. If permission is denied, the system dialer opens instead.

Demo video (strongly recommended)

Record 30–90 seconds on a real device (not emulator).
Show: open app → start verification → grant permissions when prompted → tap call → brief call → automatic return to app → “verified” success state.
Upload in the Play review reply or App content attachment when Google requests proof.
Production apps using Shernova have been approved with this flow and the FGS declaration above.

Tips to reduce review delays or rejection

Privacy policy — Link a policy that mentions phone verification, permissions used, and that calls are not recorded. Required on Play regardless of Shernova.
Data safety form — Declare phone number collection and that call state is processed for verification (not sold). Align answers with your actual backend storage.
In-app disclosure — Before the first verification, briefly explain why Phone / Notifications permissions are needed (Play expects user-facing context).
Do not remove merged permissions without understanding impact — stripping READ_PHONE_STATE breaks auto-return on many devices.
Test on a release build signed with the same certificate you registered in Shernova Dashboard (SHA256).
Reply promptly to Play review messages with the declaration text + video rather than arguing policy.
OEM battery settings — Not a Play issue, but document for support: some Xiaomi/OPPO devices may need autostart/battery exceptions for the smoothest return (optional user setting).

Alternative: avoid FGS declarations

If you cannot accept Play declarations, integrate shernova_core only (headless): open the gateway number with your own UI (url_launcher or dialer intent) and poll Shernova.watch() when the user returns manually. Trade-off: no automatic return on Android and weaker UX on MIUI. Most production apps prefer shernova_ui with declarations.

iOS / App Store

Shernova on iOS uses the same Flutter SDK without native auto-return. See iOS verification guide for App Store notes and UX expectations.