You Can Build Customer-Connection Apps Without Reading Every Contact

Reading an entire contact list is no longer the default

Google announced its contacts permission policy on April 15, 2026, and plans to apply it from January 27, 2027. The schedule is close enough that teams should prepare while making one or two app updates.

Not every app is covered. It applies to Google Play apps built as new versions targeting Android 17 or later that request READ_CONTACTS, the permission to read an entire contact list. Android 17 is a new version of the operating system, and Google Play checks whether an app was built to this standard.

If an app needs only a few people, such as for invitations or recipient selection, it must use the system contact picker. The app requests the data fields it needs, and the user directly chooses which contacts to share. The app gets temporary access only to that information. Search, multi-person selection, and separation of personal and work contacts are also supported.

Google says that reading an entire contact list solely to invite people to join a service, share files, choose collaborators, or choose transaction partners is generally not appropriate. Having an app’s own contact-selection screen is not, by itself, a reason to retain full access.

Apps whose contact-management or customer-management features genuinely require an entire address book must explain that need in the Google Play Console. From September 2026, guidance on removing the permission or submitting an explanation will begin. After enforcement starts, apps can request a 30-day extension. Korea’s Personal Information Protection Act (개인정보보호법), which requires organisations to collect only the minimum personal data needed for their purpose, points in the same direction.

A day changes for a care provider with 12 employees

Imagine a home-visit care provider with 12 employees. An operator writes down a service user’s name and phone number after a phone consultation, copies a guardian’s number into a schedule, then sends it to the assigned caregiver through a group chat.

When the same guardian looks after two parents, the customer may be registered twice. If a number has changed, or the guardian and service user have different surnames, staff call again to confirm who is connected to whom. When an app reads the whole phone address book to make contact search easier, it also gains access to information unrelated to work, including family and friends.

Under the new approach, the operator selects only the service user and guardian from the system screen during first registration. The app receives only the necessary fields from the selected names and phone numbers, then asks whether each person is a guardian, service user, or emergency contact. It can also show the collection purpose and retention period at that point.

Duplicate checks happen within the provider’s existing customer list, not across the whole phone address book. Since the same number can have different roles, the system asks whether to merge records and logs who confirmed the relationship and when. This record is more useful in real work than a simple list of phone numbers.

The new contact picker is available on Android 17 and later. For older phones, teams should also provide direct entry, a texted link for entering details, and an existing system selection screen. Whatever the operating-system version, full address-book access should not be treated as the automatic starting point.

This example assumes a product in which staff verify whether a guardian is the actual legal representative, who should be contacted first in an emergency, and whether an old number can be deleted.

The hard thing to copy is not the contact picker itself. It is the accumulated record of which relationship was verified through which process, a workflow trusted by frontline staff, relationships with local care organisations, and the trust created by collecting less personal data. Even if the technology is similar, these four things are difficult to replicate quickly.

Elsewhere, services change the way people connect instead of taking contacts

Chrome and Chromium in the United States have operated browser features that help websites receive contacts selected by the user. On July 30, 2026, a change was reflected in the actual programme for Android 17 and later: it uses the system picker without requesting permission to read an entire contact list.

The browser and this feature do not charge users separately. User churn and revenue changes after the switch have not been disclosed, but this shows that browsers used by many web services can also move to a model that receives only selected contacts rather than an entire address book.

Blinq in Australia is a digital business-card service. Sales representatives and event participants share only the information they choose to disclose through a QR code or link, and the other person can view the card without installing the app.

Its individual paid plan is about KRW 13,500 a month, while its team plan is about KRW 9,400 per person a month. The company states that it has 4 million users and about 500,000 business customers as of 2026, but those are self-reported figures and need independent verification. As the service expanded from simple business-card sharing into team management and customer connection, its business distribution network became an asset.

Eight in Japan is a service for managing relationships based on business cards and profiles. It hides most profile information before people connect, then creates a relationship through QR-code exchange or nearby exchange and updates connected people about changes such as job moves and promotions.

Its individual paid plan is about KRW 5,500 a month, and it also operates a business service. The company states that it has more than 4 million users worldwide and more than 5,000 business-service customers in Japan, but these are also self-reported figures. The difficult part to copy is not business-card scanning technology but the relationship network built between Japanese companies and users.

Things you can build now

1. Contact permission review board

• What it does: When teams register an app’s invitation, sharing, and customer-connection screens, it creates a work list showing whether the full address book is necessary and whether the screen can switch to a picker.
• Who uses it: A planning lead at an app operator with fewer than 20 employees that outsources development.
• Why now: Before enforcement in January 2027, teams need to decide whether to remove existing permissions or explain their necessity. Review cases and screen-by-screen response records collected early become trust assets.
• First screen: For each app feature, show whether it needs the full contact list, only selected people, or no contacts, then show the next action in one line.

2. Home-care relationship card

• What it does: Connects service users, guardians, emergency contacts, and assigned staff around selected contacts and roles, while recording when consent was confirmed.
• Who uses it: A home-visit care provider with around 12 employees that uses both phone calls and paper schedules.
• Why now: It can record only the relationships needed without importing an entire address book. Relationship-verification records accumulated by each provider are difficult for another service to copy.
• First screen: Put today’s service users and guardian phone numbers that have not yet been confirmed first.

3. Gift-delivery details request link

• What it does: Instead of handing over an address book, a buyer sends the recipient a link, and the recipient enters their own name, phone number, and address.
• Who uses it: A neighbourhood side-dish shop or rice-cake shop that has begun taking courier gift orders.
• Why now: A method that reads an entire contact list just to choose a transaction partner is difficult to maintain under the policy. Each shop’s order flow and regular-customer relationships can become distribution assets.
• First screen: Show completed payment, recipient details pending, and delivery preparation complete in that order.

4. Field exchange card

• What it does: Only two people who scan each other’s QR codes at an event exchange their names, work contact details, and meeting location, then set a disclosure period.
• Who uses it: An operator of a local construction-industry association or freelancer gathering who manages attendee lists in spreadsheets.
• Why now: People can connect without synchronising entire phone address books. Distribution access secured through associations and event organisers is the asset that is hardest to copy.
• First screen: Make the day’s event name, my exchange card, and the QR-scan button prominent.

Why this matters where you are

Check whether your platform’s contact permissions distinguish between an entire address book and contacts a person actively selects. The policy dates, system tools, and privacy rules may differ in your market, but the operational question is the same: can an invitation, recipient, or customer connection be completed with only the information needed? If it can, build the relationship-confirmation and information-request flow around that smaller exchange.

What to check today

For 30 minutes, turn off contact permission in an app you operate and run its invitation, recipient-selection, and customer-connection functions once each. If the core task can still be completed through direct entry or selecting just a few people, it may be worth building a contact-picker transition or a service that helps with that process.