A more reliable way to add and edit contacts on Android | Android Developers’ Blog

The shift marks a significant evolution in Android’s security and privacy model. Historically, applications requesting the WRITE_CONTACTS permission gained sweeping capabilities to create, modify, and delete contact entries across a device in the background, often entirely independent of user interaction. While this level of access was necessary for certain deep-integration utilities, the vast majority of apps only needed to perform routine, user-driven tasks, such as saving a single phone number or adding a new connection generated within a chat or social interface.

Google’s decision to restrict direct contact writing stems from a dual focus on enhanced user privacy and ecosystem consistency. In the past, relying on standard contact intents presented a fragmented experience for developers and users alike. Depending on the device manufacturer and the specific OS build, contact intents behaved unpredictably. Certain editors stripped away crucial data payloads like contact photos, while others suffered from unintuitive UI navigation where the hardware back button might inadvertently save an incomplete contact without the user’s explicit intent. Because of these inconsistencies, developers frequently opted to request the broader WRITE_CONTACTS permission to implement custom, reliable UI workflows inside their own applications.

The upcoming Android release addresses these fragmentation issues by standardizing contact intents across the ecosystem. On devices running the new software, contact intents will operate uniformly, requiring zero special permissions from the host application. Apps attempting to bypass these changes by writing directly to the contacts provider while targeting the new Android release will find their requests rejected, resulting in a SecurityException or a standard permission denial.

To accommodate this transition, developers are being directed to rely on standard Android intents such as ACTION_INSERT, ACTION_EDIT, and ACTION_INSERT_OR_EDIT. When these intents are invoked, the operating system manages the heavy lifting by presenting a clean, standardized contact editor interface to the user. For new entries, the system opens a streamlined half-sheet form, while updates to existing contacts allow users to easily search and append information. Users can seamlessly expand these interactions into full-page editors if they need to input more extensive details. All of this is accomplished securely without requiring the calling application to hold direct write permissions to the underlying database.

Developers can also streamline the data entry process by passing optional data payloads, known as Extras, alongside their intents. For instance, creating a new contact can include pre-filled parameters for names, phone numbers, designated storage accounts, and even contact photos by leveraging URIs alongside appropriate read permissions. Similar streamlined workflows apply to updating existing records, where applications can launch an edit intent pointing directly to a specific contact URI or allow the user to select which record to update.

Beyond basic contact insertion and editing, Google is introducing alternative pathways for specific application categories that previously relied on contact modifications for specialized features. For applications that only need to read specific contacts selected directly by the user, the Contact Picker—available since Android 17—remains the recommended, permission-free solution. Meanwhile, calling and messaging applications that historically injected custom "Call with" or "Message with" action rows directly into the user’s address book must transition to the People Directory, arriving in Android QPR2 in the final quarter of 2026. People Directory functions as a system-level registry where apps can publish communication reachability metadata without altering the user’s personal contacts database.

While standard user-driven interactions will rely entirely on intents and specialized directories, Google recognizes that a small subset of applications requires continuous, broad access to create and modify contacts in the background. To support these use cases, Android 17 QPR2 introduces a new special app access permission known as MANAGE_CONTACTS. Google Play has published updated policy guidelines regarding contact access to help developers determine whether their applications qualify for this elevated permission tier.

The MANAGE_CONTACTS permission is strictly intended for applications whose core functionality revolves around comprehensive contact management, where standard system intents are insufficient. Typical candidates for this special access include dedicated contact managers, dialer replacement apps, caller ID and spam protection services that mass-update address book entries, enterprise CRM applications, cloud sync tools performing continuous two-way background synchronization, and bulk contact backup or device-to-device transfer utilities. Conversely, applications that merely save a contact from a chat interface, scan a business card, let users pick contacts for payments or sharing, or use custom branded editing screens do not qualify for MANAGE_CONTACTS and must migrate to the intent-based model.

The transition timeline spans several milestones leading up to the enforcement of the new policies. Google Play announced the initial MANAGE_CONTACTS policy framework in October 2026, paving the way for the permission to become available in Android 17 Quarterly Platform Release 2 later that year. The enforcement phase arrives with the upcoming Android release in 2027, at which point WRITE_CONTACTS will officially cease to grant write access for apps targeting the new platform, and contact intents will be strictly standardized across all compatible devices. Following this rollout, the Play Console will require applications utilizing MANAGE_CONTACTS to submit formal policy declarations to ensure compliance across the ecosystem.