1. Who may touch these permissions at all. Google Play classifies SMS and Call Log Permissions as "personal and sensitive user data subject to the Personal and Sensitive Information policy" and binds each group to a device role: the Call Log group (READ_CALL_LOG, WRITE_CALL_LOG, PROCESS_OUTGOING_CALLS) requires that the app "must be actively registered as the default Phone or Assistant handler on the device", while the SMS group (READ_SMS, SEND_SMS, WRITE_SMS, RECEIVE_SMS, RECEIVE_WAP_PUSH, RECEIVE_MMS) requires that it "must be actively registered as the default SMS or Assistant handler". The same policy is explicit that "Apps lacking default SMS, Phone, or Assistant handler capability may not declare use of the above permissions in the manifest. This includes placeholder text in the manifest" - so a non-handler cannot use the declaration form to buy eligibility, and leaving the permission in as a placeholder is itself a violation. The app must be the registered handler before it prompts the user, and must "immediately stop using the permission when they're no longer the default handler" (https://support.google.com/googleplay/android-developer/answer/16558241).
2. If you are the handler, this is the exact permission matrix reviewers check. Google publishes three permitted roles with the permissions each may hold: Default SMS handler - READ_SMS, RECEIVE_MMS, RECEIVE_SMS, RECEIVE_WAP_PUSH, SEND_SMS, WRITE_SMS; Default Phone handler - SEND_SMS, PROCESS_OUTGOING_CALLS, READ_CALL_LOG, WRITE_CALL_LOG; Default Assistant handler - READ_SMS, RECEIVE_MMS, RECEIVE_SMS, RECEIVE_WAP_PUSH, SEND_SMS, WRITE_SMS, READ_CALL_LOG. All of these are "subject to Google Play review and approval", and the app's description must prominently document and promote the core feature that needs them. The one extra allowance for genuine default handlers is contact prioritization - surfacing a user's most important contacts using recency, frequency and duration to enable user-initiated calls, texts and actions - and even that is fenced: "Uses beyond contact prioritization, including using data from one user to directly influence another user's product experiences, are disallowed" (https://support.google.com/googleplay/android-developer/answer/10208820).
3. Non-handler apps live on the exception table only. Google may grant a temporary exception where the use enables a listed core function and "there's currently no alternative method to provide the core functionality". The published table (with the eligible permissions) is: account verification via phone call - READ_CALL_LOG; anti-SMS phishing / smishing - READ_SMS, RECEIVE_MMS, RECEIVE_SMS, RECEIVE_WAP_PUSH, WRITE_SMS (this one requires "a track record of significant protection for users - as reflected in analyst reports, benchmark test results, industry publications, and other credible sources of information"); backup and restore for users - SMS read/receive/write group plus READ_CALL_LOG, WRITE_CALL_LOG; caller ID, spam detection and/or spam blocking - SMS group plus SEND_SMS, READ_CALL_LOG, PROCESS_OUTGOING_CALLS; connected device companion apps (smartwatch, automotive, smart home) - SMS group plus PROCESS_OUTGOING_CALLS, READ_CALL_LOG, WRITE_CALL_LOG; cross-device synchronisation or transfer of SMS or calls - SMS group plus SEND_SMS, READ_CALL_LOG; device automation - SMS group plus READ_CALL_LOG, WRITE_CALL_LOG, PROCESS_OUTGOING_CALLS; enterprise archive, business/enterprise CRM and enterprise device management - SMS group plus READ_CALL_LOG, PROCESS_OUTGOING_CALLS, WRITE_CALL_LOG (for CRM only the starred READ_CALL_LOG and PROCESS_OUTGOING_CALLS are allowed); in-vehicle hands-free use and projected display - RECEIVE_SMS, SEND_SMS, RECEIVE_MMS, RECEIVE_WAP_PUSH, WRITE_SMS, PROCESS_OUTGOING_CALLS, WRITE_CALL_LOG, READ_CALL_LOG; physical safety/emergency alerts to send SMS - SEND_SMS; proxy calls - PROCESS_OUTGOING_CALLS, READ_CALL_LOG, WRITE_CALL_LOG; SMS Cell Broadcast - RECEIVE_SMS; SMS-based financial transactions such as UPI - SMS group plus SEND_SMS; call-based authentication and authorization in banking or brokerage apps - READ_CALL_LOG, PROCESS_OUTGOING_CALLS; SMS-based money management - READ_SMS, RECEIVE_MMS, RECEIVE_SMS, RECEIVE_WAP_PUSH; write and show call history in a default dialer app - WRITE_CALL_LOG; System Services that actively hold the SYSTEM_UI_INTELLIGENCE role - READ_SMS, READ_CALL_LOG (https://support.google.com/googleplay/android-developer/answer/10208820).
4. The banned list is longer, and Google says it is not exhaustive. Common use cases that will not be permitted to access SMS/Call Log data: account or device authentication via broad access to these permissions; content sharing or invites; contact prioritization where the app is not the default handler (or the system-level default contacts handler); social graph and personality profiling; call recorder; device performance booster; device space or data management; family or device locator; smart or predictive keyboard; SMS or calls appearing in wallpaper, launcher and other tools; SMS translation; text-to-voice or speech/voice-to-text; SMS and contacts management; SMS or phone notification enhancement and alerts; research such as market research based on SMS; remote control of a user's phone or other devices; and "any transfer that results in a sale of this data (including SDKs that sell this data)" (https://support.google.com/googleplay/android-developer/answer/10208820).
5. A granted exception still has to satisfy the whole policy stack. Google's own reminder: approved SMS/Call Log exceptions must also comply with the Spyware policy - "personal loans or budgeting apps may not exfiltrate or share non-financial or personal SMS history of a user" - with the sensitive-permissions policy, under which "you may not use permissions or APIs that access sensitive information that give access to user or device data for undisclosed, unimplemented, or disallowed features or purposes", and with the User Data policy including its Prominent Disclosure and Consent requirements (https://support.google.com/googleplay/android-developer/answer/10144311). Use is confined to the declared core feature - not advertising, marketing, or improving unrelated products - the data may not be sold or shared for a purpose facilitating sale, and "you may not use alternative methods (including other permissions, APIs, or third-party sources) to derive data attributed to Call Log or SMS related permissions". If the way you use these permissions changes, the declaration must be filed again; "deceptive and non-declared uses of permissions may result in a suspension of your app and/or termination of your developer account" (https://support.google.com/googleplay/android-developer/answer/16558241).
6. What Google tells you to use instead - and the 2027 deadline. The policy article pairs each common use with a permission-free path: SMS OTP and account verification via the SMS Retriever API, "which performs SMS-based user verification in your app automatically, without requiring the user to manually type verification codes and without requiring any extra app permissions" (with manual code entry as the fallback when the API is not an option); initiating a text message via the SMS Intent; sharing content or sending invites via the Share Intent; and initiating a phone call via the Dial Intent, which "doesn't require the CALL_PHONE permission". The forward-looking change matters most: Google has announced that the SMS and Call Log Permissions policy "will no longer permit account verification via phone call as a use case for the READ_CALL_LOG permission" effective January 27, 2027, directing developers to the Digital Credentials API (directly or through a verification provider built on it) or the SMS Retriever API (https://support.google.com/googleplay/android-developer/answer/10208820).
7. Legacy APKs have a narrow, dated exception. If you still ship old APKs carrying SMS/Call Log permissions and can no longer change their code, you can request a policy exception in the APK Exceptions field of the declaration form - but only if you declare the specific APKs, those APKs "must have been published before January 1, 2019", you serve compliant alternative APKs to users on Android Oreo (API level 26) or higher, and the excepted APKs represent "no more than a low single-digit percentage" of your total install base. Exceptions are granted case by case; the alternative is to unpublish the offending APKs. Separately: "Apps that fail to meet policy requirements or lack a Permissions Declaration Form may be removed from Google Play" (https://support.google.com/googleplay/android-developer/answer/10208820).
8. Filing the declaration itself. The end-to-end mechanics - the seven form steps, the required video demonstration with a YouTube link preferred, test credentials for login-gated features, the multi-APK field, the extended review that can run "up to several weeks" and hold the release in pending publication, and the urgent-release path that strips the permission so the update can publish "within several hours" - are covered in our FAQ 'Restricted Permissions Declaration on Google Play - Completing the High-Risk Permissions Form' (https://kapps.store/faq/restricted-permissions-declaration-on-google-play-completing-the-high-risk-permi.html). What is specific to SMS and Call Log is the input the form must carry: the declared use case has to match the handler role the device actually grants, the permission set on every active track (including SDK-injected uses) must match the declaration exactly, and any permission you are not declaring has to come out of the bundle rather than sit in the manifest as a placeholder (https://support.google.com/googleplay/android-developer/answer/9214102).