盡量減少對使用者造成的影響
- 如果您的應用程式需要已驗證使用者的電子郵件地址，而您先前已使用
profile.emails.read達成這個目的，請改用email。 - 向「
profile.emails.read」取得已核准的驗證要求。詳情請參閱「如何提交驗證申請？」一文。 - 將先前的使用者權杖撤銷在即將移除的範圍，或完全移除應用程式的存取權。例如，應撤銷具備
profile.emails.read存取權的權杖。建議您在使用者進入應用程式時套用撤銷，以便立即取得使用者同意。 - 請使用者改用
email等新範圍重新提供同意聲明，而不使用profile.emails.read。 - 移除要從 Google API OAuth 同意畫面設定中逐步停用的範圍。
如要將應用程式從 Google+ 登入遷移至 Google 登入，您需要更新登入按鈕、要求的範圍，以及如何從 Google 擷取個人資料的操作說明。如需完整操作說明，請參閱 Android 版 Google 登入說明文件。
更新登入按鈕時，請勿提到 Google+ 或改用紅色。 遵守新版品牌宣傳規範。
大部分 Google+ 登入應用程式要求以下範圍的組合：plus.login、plus.me 和 plus.profile.emails.read。將 GoogleSignInOptions.Builder 與 DEFAULT_SIGN_IN 選項搭配使用，即表示您自動要求提供使用者名稱和個人資料相片的 profile 範圍。如果您也希望取得使用者的電子郵件地址，請在建構 Google 登入選項時呼叫 .requestEmail()。
許多 Google+ 登入功能的實作者都使用程式碼流程。這表示 Android、iOS 或 JavaScript 應用程式會從 Google 取得 OAuth 授權碼，然後用戶端將該程式碼連同跨網站偽造要求防護一起傳回伺服器。然後，伺服器會驗證程式碼並取得重新整理和存取權杖，以從 people.get API 提取使用者個人資料。
Google 現在建議您索取 ID 權杖，並將 ID 權杖從用戶端傳送至伺服器。ID 權杖內建跨網站偽造保護措施，也可以在您的伺服器上以靜態方式進行驗證，可避免進行額外 API 呼叫，從 Google 伺服器取得使用者個人資料中的資訊。請按照操作說明在伺服器上驗證 ID 權杖。
如果您仍然偏好透過程式碼流程取得設定檔資訊，可以這麼做。伺服器取得存取權杖後，您必須從登入探索文件中指定的 userinfo 端點取得使用者個人資料。API 回應的格式與 Google+ 個人資料回應不同，因此您必須將剖析設定更新為新格式。
如果您使用的是 GoogleAuthUtil.getToken 或 Plus.API，請migrate至最新的 Sign-In API，以便提升安全性並打造更優質的使用者體驗。