自 2 月的首次公告以來，我們已經收到 Android 生態系統合作夥伴的意見回饋。我們十分重視您的意見，並邀請您繼續分享您的意見回饋和問題。
這些進度更新將針對設計提案、我們收到的重要問題和意見回饋，以及開發人員預覽版更新提供最新開發摘要和更新。
上次更新時間：2022 年 11 月 3 日
最新發布內容
發布開發人員預覽版 6
這個最新版本是主要版本，為即將推出的 Privacy Sandbox Beta 版本奠下基礎。這個版本包含主題預覽、歸因報表偵錯金鑰和 API 簽名變更的其他功能。
隨著在未來幾個月推出新功能，我們將會繼續更新開發人員預覽版資源。我們在此邀請您分享意見回饋或提出問題，並註冊收取計畫更新內容。
開發人員預覽版時間表更新
所有日期和詳細資料可能隨時會有變動
每個開發人員預覽版都會隨附詳細的版本資訊和指南，說明各版本分別提供哪些功能。
現已推出：
- 開發人員預覽版 6 - 提供可使用以下相關 API 設計整合的功能，包括：SDK Runtime API、Topics API、FLEDGE API 和 Attribution Reporting API
2022 年 9 月起：
- 定期更新開發人員預覽版的所有 API 和 SDK 執行階段
2022 年底前：
- 消費者行動裝置 Android 版 Privacy Sandbox Beta 1 版本
提醒：在 2 月宣布 Android 版 Privacy Sandbox 時，我們強調在設計、打造及測試這些新解決方案的同時，將打算繼續支援現有廣告平台功能至少兩年。未來如有任何異動，我們會事先發布重大公告。
設計提案更新
本部分將說明設計提案的幾項重大更新。
反射 API
我們在最初的 SDK 執行階段設計提案中，提出了有關如何防止反射和叫用 API 的建議，目的是協助 SDK 開發人員防止其他 SDK 遭到竄改。
我們收到有關受影響用途的寶貴意見，且進一步調查公用程式和風險後，允許在 SDK 執行階段中使用反射和叫用 API，並依據此更新了我們的設計提案。
但是，SDK 無法在其他已啟用 Runtime 的 SDK 上使用反射或叫用 API。而是針對 SDK 執行階段中的 SDK 對 SDK 通訊，設計另一個用於 SDK 探索的 API，我們會在日後的更新中詳細說明。
我們正在持續研究如何降低其他 SDK 遭到竄改的風險，因此我們仍建議避免在 SDK 執行階段內使用 JNI 程式碼，並正積極考慮其他 API。我們會在日後的更新中分享完整 API 禁止事項的提案。
Attribution Reporting API
- 我們已根據意見回饋新增範例，顯示瀏覽、點擊和轉換事件如何由多個參與方登錄。我們新增了未來考量與開放式問題來徵求意見回饋。
Topics API
- Topics API 會傳回最多包含 3 個主題的清單，過去 3 個週期各 1 個 (例如過去 3 個禮拜間)。我們更新了 Topics API 技術提案，以澄清說明傳回的主題代表使用者的興趣喜好，且傳回的任一或所有主題都可以用於廣告個人化。
其他問題和意見回饋摘要
本部分將列出我們收到的部分問題和意見回饋，以及我們的回應。
一般問題
- Android 版 Privacy Sandbox 是否適用於連網電視裝置？
- 我們現有的設計提案著重於支援行動裝置和應用程式的使用情境，預計日後會提供更多 Android 板型規格的相關資訊。
- Android 版 Privacy Sandbox 將如何對裝置推出 Beta 版？
- 為了持續向使用者靈活發布更新，關鍵元件會以主系列模組的形式發布給支援的 Android 行動裝置。這樣一來，我們能夠在 Android 平台的正常發布週期外，以無縫方式改進支援的裝置。
- 對於 Kotlin 支援的計畫為何？
- 我們正著手疊代 Privacy Sandbox API 設計，並打算讓開發人員編寫慣用的 Kotlin 程式碼。相關的開發人員資源也支援 Kotlin (為 Java 以外提供替代選項)，例如開發人員預覽版中的範例應用程式。
- Privacy Sandbox 提供哪些使用者層級的控制項？這些控制項預計何時推出？
最終設計仍處於開發階段，不過我們計畫在 Beta 版的裝置設定提供以下使用者控制項：
- 退出或重新加入 Privacy Sandbox 解決方案
- 從 Topics API 移除特定的推論主題
- 並非 Google Play 的應用程式商店環境可以使用 Privacy Sandbox 解決方案嗎？
Privacy Sandbox 解決方案所有內容皆屬於 Android 開放原始碼計畫 (AOSP)，其他應用程式商店如有需要也可採用。請聯絡您使用的應用程式商店瞭解對方是否有相關規劃。
SDK 執行階段
- 這些 SDK 版本在提案中如何受到管理？如果廠商可以獨立更新 SDK，應用程式是否能控管 SDK 版本依附元件？
這目前還在設計階段。現在考慮採取的方式為，SDK 開發人員透過支援 SDK 執行階段的應用程式商店，為自己發布的任何 SDK 指定
major.minor.patch版本。這樣應用程式開發人員就可以在應用程式資訊清單中宣告想要依附的
major.minor版本。系統會安裝該major.minor版本的最新修補程式版本，直到下一個修補程式發布 (修補程式會自行自動安裝)，或是應用程式開發人員重新建構應用程式，並指定不同的major.minor版本依附元件為止。- 哪些 SDK 適用 SDK 執行階段？
SDK 執行階段初始版本的設計目的是支援廣告相關 SDK 使用情境，包括啟用廣告放送、廣告評估、廣告詐欺和濫用行為偵測的 SDK。
雖然我們一開始將重心放在廣告相關 SDK 上，但如果非廣告相關 SDK 的開發人員想協助維護使用者隱私，並認為自己的 SDK 能在上述條件下運作，那麼也歡迎向我們提供意見，說明自己的 SDK 在 SDK 執行階段中的運作情形。
- 針對使用情境，目前我們使用的是提案中指定之外的權限。可以要求額外的權限嗎？
我們很樂意瞭解需要特定存取權限，而這些權限不在我們初始設計提案內的廣告相關用途。我們在此邀請您對受影響的功能分享意見回饋。
- 將 SDK 移入 SDK 執行階段程序，可以節省下載大小或空間嗎？
如果多個應用程式都整合到單一相同版本且支援執行階段的 SDK，就能節省下載大小和磁碟空間。
- SDK 的 AAID (AD_ID) 存取權限是否需要依附應用程式的權限？
RE SDK 的 AAID 存取功能必須視應用程式和 SDK 在應用程式資訊清單內宣告的權限而定。我們將在未來提案中詳細說明 SDK 在擁有相關權限時可以使用並取得 AAID 的 API。
- IP 位址、OS 版本及替代資料：廣告相關 SDK 會提供這些內容嗎？
我們正在開發廣告相關 SDK 可以存取的系統屬性，並會在之後的設計提案中分享相關資訊。目前我們尚未發布任何有關使用這些屬性的政策。
- 我們的 SDK 取得的應用程式組 ID 是否在許多應用程式中都相同，即使這些應用程式都屬於不同的 Google Play 開發人員帳戶所有？如何在不使用 AAID 的情況下橫跨多個應用程式封鎖有詐欺行為的使用者？
任何應用程式或該應用程式的所有 SDK 都只能存取和主應用程式 Google Play 開發人員帳戶相關的應用程式組 ID 值。Android 版 Privacy Sandbox 不會為了解決詐欺問題而提供跨發布商的 ID。開發人員現在可以考慮使用 IP 做為較無法保持一致的替代方案。
主題
- 我可以查看 API 傳回的所有可能主題清單嗎？
- 為了進行測試，開發人員預覽版 1 使用這個分類中的主題，因此可能隨時會有變動。我們希望能根據這個生態系統的意見回饋，逐步改善這項功能。
- 如果主題分類隨時會有變動，我們如何在下游買方模型中運用這些變更內容？
- Topics API 回應內含版本編號，可做為分類器和分類使用。
Android 版 FLEDGE
- FLEDGE 是否支援排除指定目標？
目前的設計提案不支援根據 FLEDGE 自訂目標對象的排除指定。
針對應用程式安裝廣告活動，我們將提供篩選廣告功能，方便廣告技術供應商篩選出已安裝的應用程式。我們也正在探索如何支援展示頻率上限型廣告活動的排除篩選需求。在設計提案的近期更新中將會提供更多詳細資訊。
- 賣方廣告聯播網如何建立自訂目標對象？還是只有買方廣告聯播網才能建立自訂目標對象？
我們目前提出的自訂目標對象以買方用途為主，此功能的設計用意為支援買方在保護隱私的情況下，為再行銷用途建立出價。
歸因報表
- 會搭配使用 Privacy Sandbox API，以支援應用程式和網站之間的使用情境嗎？
- 我們正在進一步瞭解使用情境，其中行動瀏覽器應用程式會呼叫 Android Attribution Reporting API，以便在相同裝置上同時啟用應用程式和網站的歸因功能。如果您選擇啟用應用程式到網站功能，Android Privacy Sandbox API 就會用於儲存和歸因，並會簡化應用程式和網站之間的歸因資料，但需要整合的 API 可能仍會向您分別傳送應用程式報表和網路報表。
- 除了最終點擊外，API 是否支援其他歸因模式？
- 這個 API 支援來源優先的最終接觸歸因模式。 此外，提案也支援將安裝後轉換的選用歸因邏輯，歸因於促成安裝的點擊或瀏覽。
- Privacy Sandbox 是否會影響 Play 安裝參照網址？
根據目前的設計與計畫，Privacy Sandbox API 不會影響 Play 安裝參照網址提供的功能。
部分開發人員已辨識出廣告格式，使用者只要完成特定點擊後事件，就能獲得獎勵。如果沒有使用者層級歸因，要依靠目前提案做到這件事將會是一大挑戰。
我們正在調查這個問題，以判斷可能的解決方案。對於這個用途以及其他可能發生的用途，我們希望收到更多意見回饋。
- 為什麼廣告技術平台會分開各自發生歸因？
現今有許多廣告客戶相當重視是否可以橫跨多個聯播網檢視簡化過的轉換事件資料，也很常仰賴行動裝置評估服務合作夥伴 (MMP) 的服務。這樣做可以讓新的 API 與往常一樣容易使用，而各個技術平台或廣告客戶也能更方便直接決定是否要使用新的 API。
透過重新導向，您不需要在每個應用程式中實際加入 SDK，但是重新導向程序需要能和廣告技術 SDK 產生關聯。
這個方法的主要好處是，所有使用者自己的商業邏輯都能有專用的中繼資料和匯總鍵，並能自行定義優先順序。
- 從 Play 商店安裝的內容會通過任何驗證嗎？
只有選用的安裝後轉換歸因邏輯才會驗證安裝內容。這些驗證安裝內容不會由 API 傳送。API 只會根據登錄完成的轉換發送報表，不會回傳任何和使用者之前是否有安裝應用程式相關的信號。
- 您們會驗證任何點選或檢視嗎？如果驗證檢視操作，有最低時間的規定嗎？
目前的 API 提案使用 InputEvent 支援基本的點選驗證功能。我們還在尋找更有效的方法，以便驗證點選和檢視。我們邀請您對這些用途提供更多意見回饋，尤其是關於哪些類型的檢視定義對本環境特別實用，歡迎提出寶貴意見。