RFC-0172：UI 活動服務

摘要

這個 RFC 導入了全新的 UI 活動服務，用來取代和降低範圍 新版本的作用

提議的服務會新增兩個新的 FIDL 通訊協定：

• 私人 FIDL 通訊協定 fuchsia.input.interaction.observation.Aggregator 至 收集使用者輸入活動的證據；以及
• 合作夥伴的 FIDL 通訊協定 fuchsia.input.interaction.Notifier，以通知 使用者輸入活動狀態變化的用戶端。

提振精神

我們希望提供的服務能通知系統其他部分 指出近期是否發生使用者輸入活動這項服務非常實用 告知其他系統服務，例如電源保護通訊協定或螢幕保護程式 功能。

有一個現有的「Activity Service」 有關系統使用者閒置狀態的可靠資料來源。這項提案是一種 從目前做法起，並導入新的「UI 活動服務」 表明責任範圍較小，單靠使用者輸入活動 而非完全系統活動，這也讓某些功能會啟用新功能， 並減少其他產品的技術債

相關人員

講師：

leannogasawara@google.com

審查者：

• jsankey@google.com
• neelsa@google.com
• sanjayc@google.com
• quiche@google.com
• wittrock@google.com

諮詢：

• anwilson@google.com
• comfoltey@google.com
• fmil@google.com
• kpozin@google.com
• palmer@google.com
• yaar@google.com

社交功能：

此 RFC 是在與 Fuchsia Input 團隊進行文件審查時討論的， 要求審查隱私權和安全性。

設計

活動狀態

「活動」是指使用者輸入與近期裝置的互動。

最近的定義為產品設定的時間門檻，例如15 人 分鐘。

如果裝置最近並未收到活動，即屬於「閒置」狀態。

使用者輸入內容互動僅限於下列用途 導入。

需求條件

下列使用者互動行為「必須」會導致使用者進入或更新服務 active 狀態：

• 使用者輕觸了螢幕。
• 使用者與滑鼠或鍵盤互動。
• 使用者按下媒體按鈕，例如調高或調低音量。

下列使用者互動行為「應」使服務進入或 續訂狀態為「啟用」的狀態：

• 使用者啟用或停用螢幕閱讀器。如果使用者透過 上述輸入模式，系統會以隱含方式擷取動作。 另外，如果是透過變更 SetUI 的方式執行此操作，建議您 就會視為開啟裝置蓋子時類似
• 使用者已打開裝置機蓋。
• 使用者開著裝置。

因下列互動不算是活躍使用者輸入活動 以內嵌方式提供相應的理由。因此也「不得」出現 服務進入 active 狀態：

• 使用者正在觀看影片或聆聽音訊檔案： 應使用 fuchsia.media.ActivityReporter，而非活動 所討論的服務

通訊協定和服務

我們推出了全新的內部 FIDL 通訊協定 fuchsia.input.interaction.observation.Aggregator 和新的 FIDL 通訊協定 fuchsia.input.interaction.Notifier 加入合作夥伴 SDK。這些通訊協定 而是由 Input 中的新的 Activity 類別實作及公開 管線元件。

fuchsia.input.interaction.observation.Aggregator

這份 API 報告的客戶認為自己有使用者的證據 輸入活動，而我們會處理這些資訊因此存取權 透過能力轉送限制為樹狀結構內元件。詳情請見 安全性考量。

library fuchsia.input.interaction.observation;

using zx;

/// The Aggregator protocol collects evidence of user activity and uses this
/// evidence to set the system's activity state.
@discoverable
protocol Aggregator {
    /// Reports a discrete activity such as a keystroke.
    ReportDiscreteActivity(struct {
        activity DiscreteActivity;
        event_time zx.time;
    }) -> ();
};

但與前身不同，後者同時收集離散事件與持續性事件 (即 包含開始和結束時間的活動)，也就是這個通訊協定的初始版本 此 RFC 定義的僅收集「Discrete」活動。Google Cloud 可以 收集持續性事件起初是為了支援媒體播放 這類網址明確「不是」此 RFC 的用途。

fuchsia.input.interaction.Notifier

這個 API 的用戶端希望能夠訂閱使用者之間的變更 互動「啟用」和「idle」定義方式類似 fuchsia.ui.activity.State。這個 RFC 計劃在 fuchsia.input.interaction 程式庫將是 flexible 。存取權不需要限制，詳情請參閱 隱私權注意事項。例如：

• 在樹狀圖中：無障礙管理員將螢幕閱讀器設為靜音 發生變化時 (例如顯示時鐘，則為每分鐘) 裝置就會進入閒置狀態。
• 樹狀結構外：裝置進入閒置狀態時，用戶端返回主畫面 時間。

library fuchsia.input.interaction;

/// The Notifier protocol offers a subscription interface through
/// which clients can watch for changes in the system's activity state.
@discoverable
protocol Notifier {
    /// Subscribe to changes in the system's state.
    /// The server will always respond immediately with the initial state,
    /// and after that whenever the system's state changes.
    WatchState(table {}) -> (resource struct {
        state State;
    });
};

提議的通訊協定將與現有通訊協定不同 fuchsia.ui.activity.Notifier.WatchState 通訊協定，因為它會使用 懸掛取得模式，完全不再需要使用 Listener 通訊協定。這項服務 也不會傳送時間戳記

蓋子感應器

UI 活動服務可以使用 fuchsia.hardware.input FIDL 監控 上蓋感應器驅動程式庫程式，並在收到 開啟報告

與輸入管道整合

空間注意事項

在輸入管道 (IP) 中實作 UI 活動服務 (A) 而不是單獨的元件，可節省約 172 KB 磁碟空間， 則視產品和主機板設定而定適用於空間受限的情況 縮減產品尺寸可釋出空間，進而改善系統的其他方面。

其他注意事項

在輸入管道中整合 UI 活動服務，包括 包括：

• 服務「必須」採用單一執行緒，因為這並非必要或 支援多執行緒此外，輸入管道為 ，並將程式庫轉換為支援多執行緒 也可能造成不必要的複雜
• 服務「必須」在 Rust 中實作，以免增加複雜度 在單一程式庫中管理多種語言
• 復原模式下無法使用這項服務，因為復原模式確實是 而非使用輸入管道或場景管理工具缺少活動 從設計到復原模式來看 使用單一高度整合的元件將依附元件降到最低。
• 本服務「不應」InputReport處理已處理的事件； 傳送至其他元件 讓服務知道 提供更多資訊，以判定是否 最近發生了活動。
• 服務「不需」具備輸入事件來源的特殊知識 (因為他們應透過 fuchsia.input.interaction.observation.Aggregator)。
• 因此，「不應」以 InputHandler 的形式實作服務。

可設定的閒置閾值

閒置閾值是指自上次使用者活動以來，已經過多久 系統處於閒置狀態時您可以使用結構化設定進行設置 用於產品層級的輸入管道或場景管理工具元件 將目前的產品設為 15 分鐘。

實作

這項服務的實作方式如下：

1. 定義新的 fuchsia.input.interaction.observation.Aggregator 並 fuchsia.input.interaction.Notifier FIDL 通訊協定。
2. 實作在以下位置初始化的新 Activity 服務並進行單元測試 用於服務這兩種通訊協定的輸入管道。
3. 透過以下方式的相關「InputHandlers」報告活動： fuchsia.input.interaction.observation.Aggregator。注意：檢舉活動 請避免在繫結階段進行 InputHandlers 負責從 InputEvents 傳給其他元件或服務。 受影響的處理常式包括：

• MediaButtonsHandler
• MouseInjectorHandler
• TouchInjectorHandler
• KeypressHandler (新版)

1. 針對以下情況新增整合測試：

• fuchsia.input.interaction.observation.Aggregator 會通知活動狀態
• 系統轉換至 fuchsia.input.interaction.Notifier 時，會收到通知 有效
• 系統轉換至 fuchsia.input.interaction.Notifier 時，會收到通知 放置型遊戲

=== fuchsia.input.interaction.Notifier 可由位於以下位置的客戶使用 這點 ===

1. 淘汰並移除 fuchsia.ui.activity.Tracker， 「fuchsia.ui.activity.Provider」和「fuchsia.ui.activity.control.Control」

• 將 FIDL 通訊協定標示為已淘汰，並按照操作說明使用新版 通訊協定
• 將現有的 fuchsia.ui.activity.Provider 使用方式遷移至 fuchsia.input.interaction.Notifier [Cobalt、Omaha 和 PowerManager]
• 移除 fuchsia.ui.activity.Tracker 的用法 (無法運作)
• 刪除「//src/sys/activity」

成效

UI 活動服務「不得」增加處理輸入事件的延遲時間 系統中的功能

雖然提議的通訊協定並未引入非同步或耗用大量運算資源 邏輯，我們可能會想對高頻率輸入事件實施節流。適用對象 舉例來說，滑鼠每秒傳送約 1000 個事件， 偏好將 MouseInjectorHandler 的 FIDL 呼叫頻率限制為 活動服務。

我們可以監控既有的效能測試，例如輸入延遲測試 判斷迴歸效能的變化情形。

安全性考量

UI 活動服務的主要濫用媒介是讓系統保持啟用狀態 產生的錯誤報表 fuchsia.input.interaction.observation.Aggregator。舉例來說 應用程式可以定期報告活動以保持系統啟用狀態。這是 風險是低風險 「fuchsia.input.interaction.observation.Aggregator」只能在樹狀結構內使用。 未在 SDK 中提供，且只會由 UI 領域中的元件使用。

這些服務可能會造成延遲軟體更新， 螢幕解鎖、耗盡電池電量，並可能會拒絕服務 裝置上的其他應用程式。委派資料存取權的風險是由 墨西哥的 RFC。用戶端在提供上述等功能時，會依賴閒置狀態 使用以下內容時，應自行設定活動上限 服務 (例如在使用者啟用 24 小時之後，強制執行強制系統 OTA。

由於這項能力必須透過 CFV2 轉送，因此必須注意 平台只會授予向輸入管道回報活動的權限， 可能擔任平台層級的 A11y Manager 經理 可轉送到信任元件

隱私權注意事項

雖然 UI 活動服務不會公開任何性質的相關資訊 會顯示使用者活動中的最近活動， 已透過 fuchsia.input.interaction.Notifier 預設時間門檻。

隱私權保護 也因此具有敏感性和敏感性，因此我們不希望 元件具有存取權由於這項能力必須經由 請注意，平台應只授予觀測能力 平台層級信任的活動，而產品可以進一步 可轉送到信任元件

系統不會向訂閱者顯示特定時間戳記。

測試

我們的測試策略包括

• 單元測試
• 使用現有工具進行整合測試

說明文件

這項服務會提供 README 總覽，並納入新的 FIDL 通訊協定 以及內嵌註解。

缺點

輸入管道失敗

如果輸入管道發生恐慌或死結，那麼 UI 活動服務也會 失敗。在這種情況下，閒置狀態的訂閱者應預設為 主動狀態行為而非閒置狀態行為，並應 以及降低活動逾時時間等措施 仍持續發生如果輸入管道無法接收 或回覆輸入報表，可能會發生更廣泛的問題。

替代方案

使用現有的 fuchsia.ui.activity.Tracker 通訊協定

這個方法傾向於 fuchsia.input.interaction.observation.Aggregator 通訊協定。

• 目前的通訊協定在合作夥伴 SDK 中，不得將該通訊協定設為 和私人 SDK納入合作夥伴 SDK 後，將有額外的 CTS 測試 Google Cloud 就是最佳選擇
• 匯總器可更清楚地說明通訊協定正在執行的作業。
• 目前的用途組合不需要使用 StartOngoingActivity 或 EndOngoingActivity，以及日後的需求，您可能需要重新評估目前的 。

修改現有的 fuchsia.ui.activity.Provider 通訊協定

這個方法傾向建立新的 fuchsia.input.interaction.Notifier 因此效能相當卓越

• 目前的通訊協定可以由 fuchsia.ui.activity.control.Control 通訊協定。
• WatchState 通訊協定必須遷移至提議的通訊協定 懸掛模式
• WatchState 通訊協定會不必要的釋出時間戳記 希望客戶能依賴 基礎架構

整合其他活動信號

某些信號可能屬於某些使用者流程中的活動，其他信號則不在此限。 因此，每種信號的正確解讀方式 特定板型規格或服務的需求

建議將 fuchsia.input.interaction.Notifier 通訊協定設為 用於取用 UI 活動狀態，可與 以判斷其他形式的活動 (例如音訊、麥克風或攝影機) 視個案情況而定，特定的最終使用者或系統狀態。適用對象 例如，螢幕保護程式功能可能只會參考使用者輸入活動，而 螢幕鎖定功能可能會參考使用者輸入活動和使用者 驗證狀態

支援：設定應考量的活動類型子集

某些服務未來可能會想追蹤 取決於使用者輸入模式的子集，例如近期觸控，但不是最近的接觸 按鍵。這會在可能性總和 輸入模式

由於使用者目前尚無意願使用更複雜的功能，因此我們決定 早就變得複雜

整合 Fuchsia 系統驗證

系統驗證和 UI 活動服務都重視 使用者行為，但幾乎不會重疊。例如「系統」 驗證功能著重在更精細的使用者線上狀態組合 包括使用者與裝置間的距離，以及使用者是否為帳戶擁有者。

雖說追蹤使用者活動也是可行的做法， 兩種情況下可能不需要主動整合這兩個 沒有駕駛系統的用途

日後的工作

允許訂閱者設定閒置時間門檻

某些服務未來可能會想自行判斷近期回訪率 使用者輸入內容互動的門檻雖然這個 RFC 並未建議 為方便初始實作，省略這項功能 可延伸協定提議的具體用途 發生的機率。

既有藝術品和參考資料

• chrome.idle API 支援「active」、「idle」和「已鎖定」州。
• 由於未使用，因此 Fuchsia 根簡報者中的活動通知器已遭移除。