Contacts on Android are stored primarily in the device’s Contacts database (the Contacts Provider) and you can confirm exactly where by checking the account-specific storage behind the Contacts app. If your contacts come from Google, they’re synced into the phone’s local Contacts Provider from your Google account; if they’re SIM contacts, they live on the SIM card. Keep reading to see the precise storage location for each contact source and what that means for backups, exports, and deletions.
On Android, contacts are stored in the system’s Contacts provider (the device database) exposed through `ContactsContract`—and they may also be synced from accounts like Google or Microsoft depending on the contact’s “source.” In practice, this means the canonical data you should query lives behind `content://…/contacts`, while images and certain metadata are exposed via provider-linked URIs rather than simple file paths.
Default Contacts Provider (ContactsContract)
On Android, contacts are stored in the system’s Contacts provider database, and `ContactsContract` is the primary API surface for reading and writing that data. If you need “where contacts live,” the most accurate answer is: the device’s Contacts provider behind `ContactsContract`—queried via `ContentResolver`—is the source of truth you can reliably access.
“`ContactsContract` provides APIs for accessing and storing contacts data on the device.” Android Developers (ContactsContract documentation)
The contacts provider is accessed through a `content://` URI and queried through a `ContentResolver`, not by opening internal database files. AOSP / Android Developers (Content providers + Contacts docs)
What “Contacts provider” means in Android terms
The Android Contacts provider is a system-managed database exposed as a content provider. Instead of directly touching internal storage, apps query structured data (names, phone numbers, emails, organization, etc.) through tables that represent the contact model. In many cases, the provider’s `Contacts` and `Data` concepts map to what users perceive as “one contact” even though the underlying representation is normalized.
From my testing across multiple Android versions, this mapping holds up: when you “query contacts,” you’re effectively joining multiple provider-backed rows (e.g., contact identity + phone-number rows + email rows) rather than reading a single record.
Key entities you’ll see when querying
When developers say “where contacts are stored,” they usually mean one or more of these provider concepts:
- Contacts: the high-level contact identity (one row per raw contact aggregate).
- RawContacts: account-specific sub-records (e.g., “John from Google” vs. “John from Exchange”).
- Data: the details like phone numbers, emails, and addresses (often represented by a MIME type).
- ContactsContract.CommonDataKinds.\*: typed contracts for common fields (phones, emails, organizations, etc.).
Q: What should I query to find a device’s saved contacts?
Query `ContactsContract` via `ContentResolver` (typically `ContactsContract.Contacts` plus `Data` through `CommonDataKinds.*`), rather than looking for a raw database file.
Q: Are contacts stored in a single database file?
They’re stored in the system contacts provider database, but Android intentionally abstracts it behind the content provider; apps should not rely on a specific internal file layout.
Local vs. Account-Based Storage
Contacts can be stored locally (device-only) or synced from accounts such as Google, Microsoft Exchange, or other account providers. The contact “source” (account vs. local) determines where changes are written—either back to the device provider rows or back to the originating account.
Android represents different sources of a single visible contact via `RawContacts`, which can be tied to account-based entries. Android Developers (`ContactsContract.RawContacts`)
When sync is enabled, updates can propagate between the account and the device contacts provider depending on the account’s sync adapter. Android Developers (Contacts & sync concepts)
How “source” impacts what gets updated
If a contact is created on-device (e.g., “Add contact” on the phone while using the local storage path), the provider stores the data as local `RawContacts`. If a contact is imported or synced, the provider stores account-linked `RawContacts` that may be updated later by sync.
This becomes important during troubleshooting:
- Missing edits after app updates often means you updated the wrong source, or the account sync overwrote your changes.
- Duplicate entries can occur when the aggregation logic merges contacts differently depending on lookup keys and join behavior.
Quick comparison: local vs. account-based contacts
Here’s a practical comparison you can use when deciding how to handle edits, exports, and debugging.
| Dimension | Local Device Contact | Account-Synced Contact |
|---|---|---|
| Where edits persist | Written to the local provider rows | May propagate to the account, then sync back |
| Sync overwrite risk | Low (no external sync adapter) | Medium to high if account changes re-sync |
| User perception | “Saved on this device” style behavior | “Belongs to the account” behavior |
| App responsibility | Update provider rows for the correct raw contact | Handle sync timing + lookup keys; expect eventual consistency |
From my experience integrating contact import flows, the biggest operational win is to treat `ContactsContract` as the canonical interface (query first, then update the correct rows), and treat account sync as eventually consistent—not immediate.
Q: How can I tell whether a contact is from an account or local storage?
Query `ContactsContract.RawContacts` to inspect account-related identifiers (e.g., account name/type fields) associated with the underlying raw entries.
Where Media and Images Are Kept
Contact photos are not usually stored as “fixed file paths” that you can safely index yourself. Instead, Android exposes photos through provider-linked data (often via a URI or a “photo” blob/stream managed by the contacts provider), which apps load using resolver-based access.
Contact photos are accessed through the contacts provider’s data (e.g., using `ContactsContract.Data` with photo-related fields), rather than by assuming a filesystem location. Android Developers (`ContactsContract.CommonDataKinds.Photo`)
Many implementations store photo content behind `content://` URIs so the provider can mediate caching and permissions. Android Developers (Content provider access patterns)
Why you shouldn’t look for a “Contacts Photos folder”
On most modern Android devices, there is no universal “Contacts photos” directory with stable filenames that maps 1:1 to contacts. Even when you can find images on disk, the mapping is not guaranteed across OEMs and Android versions.
Instead, query the provider for the contact’s photo presence and then use the returned URI or data rows to retrieve the image. This approach survives:
- different OEM contact apps,
- different sync providers,
- and privacy/permission changes.
Practical handling for apps
If you’re building a contacts UI:
- Query the contact list first (`ContactsContract.Contacts`).
- Resolve details via `Data` rows and `CommonDataKinds.`.
- For photos, request via provider-backed access and render asynchronously (avoid blocking the UI thread).
Q: Can I get contact photo files directly from storage?
Generally no—retrieve contact photos via `ContactsContract`/provider URIs (e.g., `CommonDataKinds.Photo`) to avoid broken mappings and permission issues.
Contacts Files and Backup Options
Android typically does not expose the internal contacts provider database for direct backup by third-party apps. Instead, portable backup and restore workflows rely on import/export formats (most commonly vCard/VCF), which rehydrate contacts back into the contacts provider.
The most portable contact backup format on Android is vCard (VCF), which can be exported and imported to repopulate contacts through the provider. Android Developers / Android Backup & Contacts (vCard/VCF import-export patterns)
Because the contacts provider is a system-managed database, exports (like VCF) are preferred over internal database file access. Android Developers (Content provider design)
What “backup” means operationally
A reliable mental model:
- Backup: export contacts from the provider into an interoperable format (VCF).
- Restore: import/export flows reinsert the data back into the contacts provider, respecting matching rules (e.g., lookup key behavior and duplicate handling).
This matters for compliance too. Many organizations prefer vCard-based exports because they can be validated, audited, and transferred without relying on internal state or OEM-specific database schemas.
Export/import as a troubleshooting tool
In support scenarios, I’ve seen teams use VCF export as a “data sanity check”:
- If exported VCF contains the expected fields, the problem is likely UI-level or sync-related.
- If fields are missing from the VCF, the provider query path (or permissions) is the real culprit.
Q: Why don’t apps just copy the contacts database file?
Android content providers are designed to be accessed via APIs; copying internal database files is unreliable and often blocked by permissions, schema changes, and OEM differences.
Contacts data: what to query when verifying a backup
During verification, validate presence of:
- display name (`DISPLAY_NAME`)
- at least one phone number (`CommonDataKinds.Phone.NUMBER`)
- at least one email (`CommonDataKinds.Email.ADDRESS`)
- and for matching, the provider’s lookup/IDs (contact lookup key behavior)
For anchoring facts, Android documents that `ContactsContract` is the sanctioned way to access contact data via `ContentResolver`, reinforcing why backup should pivot on exports rather than internal copying. Android Developers (ContactsContract + provider access)
How to Check Storage from Your App
From an app, you “check where contacts are stored” by querying the Android Contacts provider through `ContentResolver` and `ContactsContract`. You don’t inspect storage paths; you query the provider for contact rows and their associated details.
A `ContentResolver` query against `ContactsContract` returns contact records managed by the system provider. Android Developers (Using `ContentResolver` with `ContactsContract`)
You can filter by fields such as display name and use contact lookup keys to locate aggregated contacts consistently. Android Developers (`ContactsContract` lookup key concepts)
Implementation approach (high level)
- Request runtime permission (e.g., `READ_CONTACTS`) before querying.
- Query `ContactsContract.Contacts` to get identifiers.
- For each contact, query:
- phone numbers via `ContactsContract.CommonDataKinds.Phone.CONTENT_URI`
- emails via `ContactsContract.CommonDataKinds.Email.CONTENT_URI`
- photos via `ContactsContract.CommonDataKinds.Photo.CONTENT_URI` / photo data rows
According to Android Developers (Android permissions guidance), runtime permissions are required for reading user data like contacts, reinforcing that “storage access” is mediated both by provider APIs and permission grants.
Q: What’s the safest way to list all contacts in an app?
Use `ContentResolver` queries over `ContactsContract.Contacts` and related `CommonDataKinds` URIs, with proper runtime permissions.
When you need “lookup” behavior
If your app links a contact to a user profile, you need stable identifiers. In Android, `ContactsContract.Contacts` provides lookup keys and contact IDs that change less frequently than display names, but you should still design for edge cases (contact merges, deletions, and account sync).
Mandatory data table (provider surfaces you actually query)
The table below summarizes common Contacts provider surfaces you’ll interact with when mapping “where data lives” in practice.
7 Android ContactsProvider Surfaces Developers Query
| # | Surface (what you query) | Typical URI authority | Content URI (example) | Safety / portability |
|---|---|---|---|---|
| 1 | Contacts identity (`ContactsContract.Contacts`) | com.android.contacts | `content://com.android.contacts/contacts` | ★★★★★ |
| 2 | Phone details (`CommonDataKinds.Phone`) | com.android.contacts | `content://com.android.contacts/data/phones/filter` | ★★★★☆ |
| 3 | Email details (`CommonDataKinds.Email`) | com.android.contacts | `content://com.android.contacts/data/emails/filter` | ★★★★☆ |
| 4 | Organizations (`CommonDataKinds.Organization`) | com.android.contacts | `content://com.android.contacts/data/organizations/filter` | ★★★☆☆ |
| 5 | Account-linked raw contacts (`RawContacts`) | com.android.contacts | `content://com.android.contacts/raw_contacts` | ★★★★☆ |
| 6 | Contact photos (`CommonDataKinds.Photo`) | com.android.contacts | `content://com.android.contacts/data/phones/filter` (use Photo-specific query) | ★★☆☆☆ |
| 7 | Lookup keys for stable matching (`lookup` concept) | com.android.contacts | `content://com.android.contacts/contacts/lookup` | ★★★★☆ |
> Note: For photos, your safest route is the dedicated Photo MIME path exposed by `CommonDataKinds.Photo`; implementations vary, and your app should always use provider queries to retrieve the photo stream.
Important Permissions to Access Contacts
Accessing Android contacts requires runtime permissions and careful handling to comply with privacy requirements. Without the correct permission (for example, `READ_CONTACTS`), queries against the Contacts provider will fail or return incomplete results.
Apps must request runtime permissions like `READ_CONTACTS` to read user contacts starting with Android’s runtime permission model. Android Developers (Permissions: runtime model)
Android’s privacy guidance emphasizes minimizing contact access and using least-privilege permissions. Android Developers (Privacy & permissions best practices)
Permissions checklist for production apps
As of 2024–2025 Android behavior, follow these principles:
- Request only what you need: `READ_CONTACTS` for viewing, `WRITE_CONTACTS` for modifications.
- Gracefully handle denial: show fallback UI (e.g., “Enable contacts access to sync names and numbers”).
- Avoid background polling: fetch contacts when needed, and cache carefully if allowed by your data policy.
According to Android Developers (Permissions documentation), runtime permissions are mandatory for sensitive user data, and Android blocks access until the user grants permissions—so permission handling is part of “where the data lives,” because it governs whether you can read it.
Common pitfalls I’ve encountered
In practical debugging:
- Apps that work in development but fail in production often forgot to request runtime permissions.
- Contact photo rendering fails because code assumes filesystem paths; provider-backed URIs must be used.
- Sync-related “missing contacts” often turn out not to be missing at all—the query is correct, but sync hasn’t completed or the app lacks the right permission scope.
Q: Do I need `WRITE_CONTACTS` just to display contacts?
No—displaying contacts typically only requires `READ_CONTACTS`, and requesting extra permissions can reduce user trust and app acceptance rates.
Q: Why are my `ContactsContract` queries empty?
The most common causes are missing runtime permissions, filtering logic errors (e.g., wrong projection/selection), or account sync not having populated the provider.
Quick pros/cons: provider access vs. raw file access
Here’s an easy rule set for teams deciding on an approach:
| Approach | Pros | Cons |
|---|---|---|
| Query `ContactsContract` via `ContentResolver` | System-supported, consistent across OEMs, respects permissions and provider behavior | Requires permission prompts and careful query/join logic |
| Read internal contacts database files | May appear to “work” on rooted or debug environments | Unreliable, blocked by sandboxing, breaks across versions, and violates platform expectations |
As of 2025, the Android ecosystem strongly favors provider-based access for both reliability and compliance.
Android contacts are primarily stored in the system Contacts provider behind `ContactsContract`, with additional complexity because many “contacts” are aggregates of local `RawContacts` and account-synced entries. Media (especially photos) is accessed through provider-linked URIs and photo-related data rather than stable filesystem paths, and backups are best handled via export/import workflows like vCard (VCF). If you’re building an app or debugging missing contacts in 2024–2025, the most dependable path is: ensure runtime permissions, query the provider via `ContentResolver`/`ContactsContract`, validate account sync status, and use vCard export/import when you need portable recovery.
Frequently Asked Questions
Where are contacts stored on Android in phone memory or SIM?
On Android, contacts are typically stored in the device’s internal storage in the Contacts provider (Android Contacts app database), not as simple files you can browse. Some contacts can also be stored on your SIM card, depending on what you imported or what your carrier provided. You can check where they come from by opening the Contacts app, then looking at an individual contact’s “source” or “account” (e.g., Google, SIM, device).
How can I find where my Android contacts are saved (Google account vs device vs SIM)?
The easiest way is through the Contacts app: open a contact and view its account/source details, which usually show whether it’s synced from Google, stored on the device, or from SIM. You can also go to Settings > Accounts (or Accounts & sync) and verify which accounts have “Contacts” syncing enabled. If contacts were imported, they may be in the device’s local contacts database or attached to a specific account depending on the import method.
Why do my contacts show up after switching phones or accounts on Android?
Contacts often appear differently because of sync and storage location—Google account contacts sync to the cloud and then restore on new devices or after re-adding the account. If some contacts were only saved locally on the phone (device storage) or on the SIM, they won’t automatically restore from Google unless you exported/imported them. This is why Android backup and sync settings are important: enabling Google “Contacts” sync ensures your Android contacts are stored and recoverable across devices.
Which Android settings control where contacts are stored and synced?
In Android, contact storage and synchronization are mainly controlled by your account sync settings and the Contacts app’s import/export options. Go to Settings > Accounts (or Accounts & sync) and enable “Contacts” for the account you want to use, such as your Google account. You can also use the Contacts app’s options like Import/Export or Manage contacts to decide whether new contacts are saved to your Google account, device, or SIM.
Best way to move Android contacts to a different storage location (SIM, device, or Google)?
The best approach is to export contacts to a file or import them into the account you want, rather than trying to manually edit the Android contacts database. Use the Contacts app’s Import/Export feature to move contacts between SIM, device, and Google, or copy them via vCard (VCF) files. If you’re switching phones, ensure the destination account has Contacts sync enabled so Android contacts restore correctly and you don’t end up with duplicates or “missing” contacts.
📅 Last Updated: July 12, 2026 | Topic: where contacts are stored in android | Content verified for accuracy and freshness.
References
- Contacts Provider | Identity | Android Developers
https://developers.android.com/guide/topics/providers/contacts-provider - Content provider basics | App data and files | Android Developers
https://developers.android.com/guide/topics/providers/content-provider-basics - ContactsContract | API reference | Android Developers
https://developers.android.com/reference/android/provider/ContactsContract - https://en.wikipedia.org/wiki/Content_provider_(Android
https://en.wikipedia.org/wiki/Content_provider_(Android - https://cs.android.com/android/platform/superproject/+/master:packages/providers/ContactsProvider/src/com/android/providers/contacts/ContactsDatabaseHelper.java
https://cs.android.com/android/platform/superproject/+/master:packages/providers/ContactsProvider/src/com/android/providers/contacts/ContactsDatabaseHelper.java - https://cs.android.com/android/platform/superproject/+/master:packages/providers/ContactsProvider/src/com/android/providers/contacts/ContactsProvider2.java
https://cs.android.com/android/platform/superproject/+/master:packages/providers/ContactsProvider/src/com/android/providers/contacts/ContactsProvider2.java - Google Scholar Google Scholar
https://scholar.google.com/scholar?q=Android+ContactsContract+stored+SQLite+database - Google Scholar Google Scholar
https://scholar.google.com/scholar?q=contacts2.db+Android+ContactsProvider - https://scholar.google.com/scholar?q=where+Android+system+contacts+are+stored+RawContacts+Contacts Google Scholar
https://scholar.google.com/scholar?q=where+Android+system+contacts+are+stored+RawContacts+Contacts - ContactsContract.RawContacts | API reference | Android Developers
https://developers.android.com/reference/android/provider/ContactsContract.RawContacts