Android 聯絡人權限將如何改變：MANAGE_CONTACTS 遷移指南

Android 聯絡人存取方式正在改變，這會影響應用程式開發、Google Play 政策審查，以及使用者看到的隱私選擇。Google 於 2026 年 10 月 21 日宣布，針對下一代 Android 的應用程式將不能再預設使用 WRITE_CONTACTS 直接寫入聯絡人。大多數應用程式應改用標準聯絡人 Intent，或採用權限更精準的系統介面。

這項變更很容易被誤解。它不是禁止所有聯絡人功能，也不代表現有應用程式會突然失效。核心轉變是從能在背景大量修改通訊錄的權限，改成由使用者發起並確認的操作：新增聯絡人、編輯聯絡人、讓使用者選取聯絡人，或透過系統目錄顯示應用程式內的通話與訊息能力。提早遷移可以減少權限提示，也能避免開始支援新 Android 版本時才臨時重做。

重點摘要：多數應用程式不應再直接寫入聯絡人

如果使用者要求應用程式儲存名片、加入電話號碼或編輯一位聯絡人，建議使用 ACTION_INSERT、ACTION_EDIT 或 ACTION_INSERT_OR_EDIT 等標準聯絡人 Intent。這些流程會開啟系統編輯器，在執行下一代 Android 的裝置上不需要廣泛的聯絡人寫入權限。

如果只需要使用者選取一個人，請使用 Contact Picker。如果通話或訊息應用程式想提供「使用某應用程式通話」或「使用某應用程式傳訊息」，應研究 People Directory，而不是向使用者的通訊錄新增額外項目。MANAGE_CONTACTS 應保留給真正需要廣泛直接管理聯絡人的產品，例如專用聯絡人管理器、撥號器替代品或備份還原工具。詳情可參閱 Android Developers 官方公告 與 常用 Intent 參考。

為什麼 Google 要取代廣泛的聯絡人寫入權限

舊模式把一次性的使用者要求和持續維護整本通訊錄，幾乎當成同一種權限問題。只想儲存一位聯絡人的應用程式可以申請 WRITE_CONTACTS，但這項權限也可能允許它在背景大量修改聯絡人。使用者很難從權限提示判斷應用程式究竟只需要完成一件小事，還是想長期取得高權限。

新的方式圍繞使用者當下的動作設計。當應用程式開啟系統聯絡人編輯器時，使用者可以看到即將儲存的欄位、目標帳戶和最後操作。系統保留確認界線，不必把無限制寫入能力交給應用程式。這也符合 Android 其他隱私介面的方向：只取得完成任務所需的最小能力，讓使用者掌握最後一步。

Google 同時處理可靠性問題。過去聯絡人 Intent 在不同裝置上的行為不一致，有些編輯器會遺失照片等欄位，有些裝置不容易找到新增聯絡人的入口，也有裝置對返回鍵的處理不同。下一代 Android 會標準化相關新增與編輯流程，讓建議的路徑更容易測試。

開發者應採用的遷移路徑

用 Intent 儲存或編輯一位聯絡人

名片掃描器、聊天應用程式、訂單工具和活動應用程式通常不需要廣泛聯絡人權限。新增聯絡人時使用 ACTION_INSERT；使用者可能要把電話或電子郵件加入既有項目時使用 ACTION_INSERT_OR_EDIT；已有明確聯絡人 URI 且使用者要求修改時使用 ACTION_EDIT。

不要只測試 Intent 是否能建立。還要檢查帳戶選擇、照片、電話、電子郵件、取消、旋轉，以及儲存後回傳的結果。標準 ContactsContract.CommonDataKinds 以外的自訂 MIME 類型可能被系統編輯器忽略，因此要準備清楚的降級處理。

用 Contact Picker 讓使用者選取聯絡人

如果應用程式只需要使用者選取某個人，讀取完整通訊錄就是過度存取。Android 17 起提供的 Contact Picker 讓使用者選取聯絡人，而不需要廣泛權限。邀請、付款、分享行程和共乘等功能，通常只需要一位使用者選取的人，而不是整個聯絡人資料庫。

這不只是隱私改善，也能改善體驗。選取器會在使用者做選擇的當下說明為什麼需要資料，比在功能尚未被理解前先顯示廣泛權限請求更容易建立信任。

用 People Directory 顯示應用程式內可達性

通話與訊息應用程式有時會在聯絡人中寫入額外列，讓使用者看到「使用某應用程式通話」或「使用某應用程式傳訊息」。Google 計畫在 2026 年第四季的 Android QPR2 引入 People Directory，為這類資訊提供更適合的位置。應用程式可以發布如何在應用程式內聯絡彼此，而不是修改使用者的私人通訊錄。

這種分工更清楚：聯絡人應用程式保存個人通訊錄，People Directory 描述應用程式能力。團隊應追蹤 QPR2 的可用性，在支援裝置上完成測試後再移除舊有相容方案。

什麼時候才應該使用 MANAGE_CONTACTS

MANAGE_CONTACTS 是特殊應用程式存取權，不是一般執行階段對話框。使用者要在 設定 > 特殊應用程式存取權 > 管理聯絡人 中開啟。對符合條件的應用程式，它包含讀取能力，因此不一定還要同時要求 READ_CONTACTS。

它適合核心工作就是管理聯絡人的產品，例如聯絡人管理器、撥號器替代品、會大量更新通訊錄的來電識別或垃圾電話防護工具、企業同步、批次備份還原及換機工具。單純想保留自訂編輯畫面，不足以成為申請廣泛權限的理由。

實用的遷移清單

1. 搜尋 WRITE_CONTACTS、直接 ContentResolver 寫入、自訂聯絡人列和 Play 政策聲明。
2. 將功能分類為新增、編輯、使用者選取、應用程式內可達性或廣泛聯絡人管理。
3. 用 ACTION_INSERT、ACTION_EDIT 或 ACTION_INSERT_OR_EDIT 取代單一聯絡人操作。
4. 能使用 Contact Picker 時，不要讀取完整通訊錄。
5. 用 People Directory 評估應用程式內通話與訊息入口。
6. 只有核心功能確實需要廣泛管理時才保留 MANAGE_CONTACTS，並寫明理由。
7. 在新舊 Android 版本測試取消、不完整資料和權限邊界。
8. 確認 Manifest、Play 聲明、隱私政策及應用程式內說明一致。

如果你是 Android 使用者，也可以採用相同原則：優先選擇會解釋權限用途、提供使用者主動觸發流程的應用程式。安裝工具前，可先瀏覽 BTTC 的 Android 軟體目錄，比較官方來源、權限、版本和隱私說明。

常見問題

這會立即影響所有 Android 應用程式嗎？

不會。直接寫入限制針對支援下一代 Android 的應用程式，舊目標版本維持目前行為。

應用程式能用 Intent 刪除聯絡人嗎？

不能。Android 沒有標準刪除 Intent，使用者應在聯絡人應用程式中刪除。

MANAGE_CONTACTS 會取代 READ_CONTACTS 嗎？

它對符合條件的應用程式包含讀取能力，但只讀取、不修改聯絡人的應用程式仍可能合理使用 READ_CONTACTS。

應用程式還能保留自訂聯絡人編輯器嗎？

只有核心功能需要廣泛管理時才可以。單純保留自訂介面不是申請 MANAGE_CONTACTS 的理由。

結論

Android 正把聯絡人存取變成更明確、由使用者參與的流程。多數應用程式應使用系統聯絡人 Intent、Contact Picker 和 People Directory，只有真正大規模管理通訊錄的產品才保留 MANAGE_CONTACTS。