Apps that read full contact lists now need an explanation

Apps that read an entire contact list now have an explanation requirement

Google Play (구글 플레이) began telling apps that include READ_CONTACTS to submit a declaration or remove the permission from September 2026. READ_CONTACTS is a setting that asks to read the entire contact list on a phone.

Compliance becomes mandatory from January 27, 2027, for apps built for Android 17 or later. Apps short on time can request a 30-day extension through the Google Play management console, but it is not a permanent exception.

Google’s recommended default is the Contacts Picker (연락처 선택 창). Instead of letting an app see the whole contact list, it sends only the phone number or email address of people the user selects directly. It fits features that need only specific people, such as invitations, sharing, or choosing a transaction counterpart.

Apps that want to keep reading an entire contact list must state which user feature needs it and why the Contacts Picker cannot implement that feature. A declaration may be worth considering for features that continually compare information across many people, such as contact management, backups, customer management based on a full contact list, or caller identification. It does not mean automatic approval.

Review of a newly declared version can take several weeks, and releases or updates may wait for approval. Google treats contacts as sensitive information, so the app description, permission-request screen, and actual behavior must match.

Why a small tool for one permission is needed

Tools such as Privado AI and AppSweep cover a broad range of issues: permissions, external functionality, information flows, communications, and storage.

Consider the service owner at a 12-person group-buying app team. The app reads contacts when a user invites an acquaintance to a group-buying room, then shows people who have joined in its own list.

Today, a developer checks the permission in the app settings, a product planner explains the invitation screen, and an operations person separately updates the privacy policy and Google submission form. The same explanation is copied into the screen specification, policy document, review response, and change record. But the team still has to ask the developer what the app actually reads.

The new rule narrows this complicated work to one question: “Do we truly need the entire contact list, or do we only need contacts selected by the user?” Once that decision is made, the work splits into removing the permission or preparing a declaration.

If the team chooses removal, a standalone tool could ask about the current invitation flow and produce a list of screens to change for the new Contacts Picker flow, along with a development request. An operator selects “Invite friends” and uploads images of the current screens; the developer receives a structured document showing what data should be received.

If the team keeps the permission, the same tool could gather the feature name, data read, user-facing screens, reason the full contact list is necessary, and the status of review-account and video preparation in one place. It could flag answers that changed with each app version, reducing the risk of copying an old declaration unchanged.

Some judgment still belongs to people. Developers and operators need to check together whether the Contacts Picker truly cannot implement the feature, whether the feature is central to the app, and whether the explanation matches the real behavior. A standalone tool should not promise approval. Its job is to turn scattered checks and records into one piece of work.

Overseas tools started with broad inspection

Privado AI

US-based Privado AI provides free tools for small development teams and public projects. It scans an app’s source files to find permissions, user inputs, external functionality, and paths through which information moves, then creates a report aligned with Google Play’s data-disclosure fields.

Its starting point is inspecting privacy flows across the whole app, not a service dedicated to contact declarations. A small team focused only on contact permissions still has to select the relevant findings and move them into declaration evidence and screen records.

Guardsquare AppSweep

AppSweep, operated by Belgium-based Guardsquare, scans permissions, external functionality, communications, and storage issues when a completed Android app file is uploaded. Its listed starting price is about KRW 5.35 million per app, and it is aimed at organizations that want to repeatedly inspect release versions and connect checks to their development process.

This service also starts by finding app-wide security and privacy issues rather than writing contact-declaration text. There is room for a product for small operations teams if it separates the work broad inspection tools already do: finding contact permissions, connecting them to the actual feature, and storing submission materials.

What could emerge from this

1. A contact-permission locator

• What it does: Upload a release app file to find whether it includes a contact-reading setting, and distinguish whether it was added by the app itself or came through external functionality.
• Who uses it: A three-person team that operates a group-buying or community app while outsourcing development.
• Why now: Declaration guidance began in September 2026, so operators also need to know whether the permission remains in the latest app.
• First screen: An app-file upload field and a result showing “contact permission present,” “not present,” or “source needs checking.”

2. A permission-free invitation-screen designer

• What it does: Takes the current invitation or sharing screen and produces a screen sequence and development request that replace full-contact-list access with a user-selected-contact flow.
• Who uses it: An operator of a local sports-club app that loads contacts to let users choose people to invite.
• Why now: Google clearly directs apps that use full contact-list access only for invitations and sharing to switch to the Contacts Picker.
• First screen: Choose the current feature from “Invite,” “Share,” or “Choose a payment counterpart,” then upload screen images.

3. A contact-declaration evidence repository

• What it does: Stores, by app version, descriptions of features that need the entire contact list, screens, review accounts, reproduction steps, and videos.
• Who uses it: An operations team for a field-sales app that attaches notes and consultation records to every customer phone number.
• Why now: Apps that retain the permission must explain why the Contacts Picker is insufficient, and review can take several weeks.
• First screen: Shows readiness for three items: “Feature description,” “Why the full contact list is needed,” and “How reviewers can access the feature.”

4. A deadline board for multiple client apps

• What it does: Tracks each app’s target Android version, contact-permission status, decision to remove or declare, submission date, and change history.
• Who uses it: A small app studio that has delivered food-ordering, academy-notification, and membership-management apps to multiple clients.
• Why now: Even apps managed by the same studio have different reasons for using contacts, so one answer cannot simply be copied into every submission.
• First screen: Groups client apps into four columns: “Remove permission,” “Prepare declaration,” “Decision pending,” and “Complete.”

What to check today

Ask your developer or production agency to answer, in one sentence, whether the latest release file contains READ_CONTACTS and, if it does, which user-facing screen uses it. If you can identify the screen and purpose within 30 minutes, and that purpose is only inviting, sharing, or choosing a counterpart, a permission-removal tool may be worth testing. If the app must keep comparing an entire contact list, a declaration-material management tool may be worth testing.

Why this matters where you are

Check whether your app reads an entire contact list and whether the feature really needs more than contacts explicitly selected by users. The review process and platform rules in your market may differ, but the practical work is the same: connect a permission to a user-facing feature, document the reason for it, and keep that explanation aligned with the app as it changes.