How to Fix Google Play SMS and Call Log Permissions Rejection

Audit restricted SMS and call-log permissions, verify default-handler or exception eligibility, replace ineligible access, and prepare a release-specific declaration.

What this rejection usually means

Google Play treats SMS and Call Log permissions as highly sensitive. The normal permitted path is an app that actively serves as the user's default SMS, Phone, or Assistant handler; Google also lists narrowly defined exceptions where the permission enables critical core functionality and no alternative method exists. Eligibility is permission-specific. For example, a use case that may qualify for SEND_SMS does not automatically qualify for READ_SMS or READ_CALL_LOG. Recovery therefore starts with the exact permissions in the shipped artifact, the app's actual role, and the precise policy row—not with a broader privacy explanation.

Likely rejection signals

• READ_SMS, SEND_SMS, RECEIVE_SMS, WRITE_SMS, RECEIVE_MMS, RECEIVE_WAP_PUSH, READ_CALL_LOG, WRITE_CALL_LOG, or PROCESS_OUTGOING_CALLS appears in the merged manifest
• The app asks for an SMS or Call Log permission before the user makes it the relevant default handler
• The app keeps reading or writing protected data after it is no longer the default handler
• A secondary feature such as OTP autofill, invitations, call initiation, translation, alerts, or profiling uses broad access despite a safer alternative
• The declaration selects an exception but the requested permission is not listed for that exception
• The store listing does not prominently describe the core SMS, Phone, Assistant, or exception functionality
• A library, product flavor, dynamic feature, internal track, or older active APK contributes a restricted permission
• SMS or call-log data reaches an SDK, server, analytics system, ad system, or retention process beyond the approved purpose

Recovery plan

1. Preserve the full enforcement notice and record the package name, version code, AAB, release track, review date, rejected permission names, selected declaration use case, and any reviewer attachment.
2. Inspect the merged manifest from the exact signed AAB and every relevant active artifact. Identify the source module, SDK, library, product flavor, or older APK that contributes each SMS or Call Log permission.
3. Create a permission-to-purpose matrix. For each restricted permission, document the user action, data read or written, default-handler role, policy exception claimed, server or SDK recipients, retention, and behavior when access is denied.
4. Apply the eligibility gate separately to every permission. Confirm either that the app performs the complete default SMS, Phone, or Assistant role, or that the core function matches a named exception and has no viable alternative. Remove any permission that fails this test.
5. Replace ineligible access with the policy-recommended narrower path. Use SMS Retriever or manual entry for SMS OTP, SMS Intent to initiate a message, Share Intent for sharing or invites, and Dial Intent to open the phone app for a user-initiated call.
6. Remove the permission at its real source. Update or remove contributing libraries and manifests, rebuild each affected variant, and verify the final signed artifact rather than only the main AndroidManifest.xml file.
7. For a default-handler path, make the app capable of the complete role, explain that role prominently in the Play listing, ask the user to become the default handler before requesting associated permissions, and stop protected access as soon as the role is lost.
8. For an exception path, quote the exact eligible use internally, retain only the permissions listed for that row, prove the function is critical to the app's main purpose, and document why the safer alternatives cannot provide it.
9. Reconcile the Permissions Declaration Form, privacy policy, applicable Data safety answers, prominent disclosure and consent, reviewer instructions, and data-flow inventory with the exact behavior of the new release. Resubmit the declaration whenever the restricted-permission use changes.
10. Test a clean installation of the release build. Record role acceptance and refusal, runtime permission grant and denial, role loss, offline or backend failure, and the complete reviewer path. Confirm that no unrelated SDK receives protected SMS or Call Log data.
11. Choose the recovery route: submit a new build for manifest, SDK, code, UI, role-flow, or data-handling changes; appeal only when the exact reviewed artifact already complied or the enforcement relied on a verifiable wrong fact.
12. Plan for the announced January 27, 2027 change: Google says account verification via phone call will no longer qualify for READ_CALL_LOG. Migrate that flow to Digital Credentials, SMS Retriever, another approved provider, or manual verification before the new rule applies.

Evidence to prepare

• Full enforcement notice with package, version code, track, date, and cited permissions
• Merged-manifest output for the exact signed AAB plus the dependency or module contributing each permission
• Inventory of active artifacts showing where restricted permissions remain or have been removed
• Permission-to-purpose matrix tied to the default-handler role or exact exception row
• Before-and-after manifest and dependency diff for every removed permission
• Screenshots or recording showing default-role selection before the runtime request and access stopping after role loss
• Current Permissions Declaration Form, store listing, privacy policy, Data safety answers, and reviewer instructions
• Data-flow map covering local processing, servers, SDKs, retention, sharing, and deletion
• Clean-install test recording using the exact release build and a reviewer-accessible account or setup

Appeal or fix first?

Reviewer response framework

Your response should be factual, short, and limited to the submitted build. Cover these points:

1. Identify the package, version code, track, restricted permissions, and cited policy finding.
2. State whether each permission was removed, retained for a default-handler role, or retained under one exact exception.
3. For removals, name the replacement API and attach the signed-artifact manifest diff.
4. For retained access, show the role sequence or exception eligibility, core-function necessity, approved data flow, and declaration.
5. Request review of the corrected build or reconsideration of the documented artifact without making unsupported approval claims.

Frequently asked questions

Source: Google Play — Use of SMS or Call Log permission groups. Platform policies change. Verify the official rule before submitting. Resubmit AI provides technical and editorial decision support, not an approval guarantee or legal advice.