When Android asks whether an app can access your contacts, it is reasonable to pause.

Your address book can contain much more than names and phone numbers. Android’s Contacts Provider can store email addresses, postal addresses, photos, websites and other contact-related fields. The READ_CONTACTS permission allows an app to read the user’s contacts data.

But one important distinction is often lost in privacy discussions:

Permission to read contacts is not the same thing as proof that an app uploads your contacts.

Fact-checked: August 2026Android Developers · Google Play policy
The key distinction

READ_CONTACTS gives an app permission to read contact data. The permission itself does not upload anything. Network transmission happens only if the app is implemented to send data elsewhere.

PermissionWhat Android allows the app to access
ScopeWhich contact fields the app actually queries
ProcessingWhat the app does with the data after access
TransmissionA separate implementation choice, not implied by permission

A permission defines what Android allows the app to access on the device. What the app does after receiving access depends on the app’s implementation.

What does READ_CONTACTS actually allow?

Android defines READ_CONTACTS as a dangerous permission that “allows an application to read the user’s contacts data.” You can see the definition in the Android Manifest permission reference.

The data can be broader than people expect.

Android’s ContactsContract.Data and Contacts Provider documentation describe contact records that can include data types such as:

  • names;
  • phone numbers;
  • email addresses;
  • postal addresses;
  • photos;
  • websites;
  • organizations;
  • notes and other contact-related fields.

The exact data an app queries can be narrower than everything available, but broad Contacts access is still a meaningful privacy permission because the underlying provider can hold a rich address book.

Does Contacts permission mean your address book is uploaded?

No — not by itself.

READ_CONTACTS gives the app permission to query contacts data through Android. It does not automatically create a network connection or send the data anywhere.

Three apps could all request the same permission and behave very differently:

  1. One app might compare phone numbers entirely on the device.
  2. Another might read only a subset of contact fields for a specific feature.
  3. Another could be designed to transmit contact information to a server.

The permission alone does not tell you which design the developer chose.

That is why a better privacy question is:

What contact data does the app access, why does it need it, where is that data processed, and does any of it leave the device?

Why might a call-filtering app need Contacts access?

Android’s call-screening API gives a concrete example.

The platform’s CallScreeningService normally receives calls whose numbers are not in the user’s contacts. If the selected screening service has been granted READ_CONTACTS, Android can also provide calls involving contacts to the service.

That means a call-control app can have a legitimate reason to know whether an incoming visible number matches a saved contact.

A rule such as:

number is not in Contacts → apply filtering rule

requires some way to determine whether a contact match exists.

That does not mean every calling app needs broad Contacts access, and it tells you nothing by itself about whether a particular app uploads contact data.

For the call-control side of this, see how Android can block calls from numbers not in your contacts.

Google Play treats contacts as personal and sensitive data

Google Play’s User Data policy treats the phone book / contacts as personal and sensitive user data. Developers are expected to be transparent about how sensitive data is accessed, used, collected and shared.

See the current Google Play User Data policy.

There is also an important policy change coming later in 2026.

Google announced a new Contacts Permissions policy for apps targeting Android 17 (API level 37) and higher. Google says those apps may request broad READ_CONTACTS access only when the Android Contact Picker is not sufficient for core functionality, and developers in scope must justify that need in Play Console.

As of August 2026, that policy has been announced but its mandatory enforcement date is October 28, 2026.

Google’s current timeline is documented in Understanding Restricted Permissions with minimum scope alternatives.

Android 17 introduces a more granular Contact Picker

Android 17 adds a system Contact Picker that Google describes as a privacy-preserving alternative to broad READ_CONTACTS access.

Instead of handing an app the entire address book, the app can request specific data fields — such as phone numbers or email addresses — and the user chooses which contacts to share.

The app receives access only to the selected data.

See Android 17 Contact Picker.

This is a strong privacy improvement for apps that only need a few contacts.

It does not automatically make READ_CONTACTS unnecessary for every use case. A feature that continuously needs to determine whether arbitrary incoming phone numbers match the user’s saved address book is a different technical problem from a feature that needs the user to pick one recipient.

How can you review or revoke Contacts access?

On standard Android/Pixel guidance, you can review an individual app’s permissions through:

Settings → Apps → [app] → Permissions

From there, you can change a permission to Allow or Don’t allow. Google also documents a Permission Manager that lets you inspect apps by permission type.

The exact menu wording can vary by manufacturer, but Google’s current steps are documented in Change app permissions on your Android phone.

Keep in mind that revoking Contacts permission may disable features that genuinely depend on contact matching.

How to evaluate an app asking for Contacts access

Do not judge an app by the permission name alone. Judge the data flow.

Ask:

Does the permission have a clear product purpose?

A messaging app, dialer, contact manager or call-filtering app may have an obvious use for contact data. A flashlight app probably has a much harder case to make.

Does the developer explain what is read?

“Contacts access” is vague. Better disclosures explain whether the app needs names, phone numbers, selected contacts or the whole address book.

Does the privacy policy say whether the data leaves the device?

Local processing and server-side processing are materially different privacy models.

Does the app request more than it needs?

Android 17’s Contact Picker is a reminder that minimum-scope access is increasingly preferred when the feature can work that way.

Can you revoke the permission?

Android gives users control over app permissions. A trustworthy product should also explain what stops working if access is removed.

How this applies to LineLayer

Disclosure: this article is published by the makers of LineLayer.

LineLayer requests Contacts access because its contact-based call rules need to distinguish saved callers from visible numbers that are not in your contacts and to support contact-based exceptions.

The responsible claim here is the functional one: Contacts access supports contact-aware call filtering.

For the shipping app’s current data-handling details, review the site’s privacy information and LineLayer product page. We deliberately avoid treating the presence of READ_CONTACTS as proof of either good or bad data behavior; the implementation and privacy disclosures have to support the claim.

Bottom line

READ_CONTACTS matters because Android’s contact database can contain sensitive personal information.

But the permission itself does not prove that an app uploads your address book.

A trustworthy app should explain:

  • what contact data it accesses;
  • why it needs that data;
  • where the data is processed;
  • whether the data leaves the device;
  • and what happens if you revoke access.

That is a more useful privacy test than simply counting permissions.

Sources