RFC-0172：UI 活動服務

RFC-0172：UI 活動服務
狀態已接受
區域
  • HCI
  • 圖像
說明

判斷使用者輸入是否有效或閒置狀態，並通知客戶的服務提案。
問題
  • 86773
變更
作者
審查人員
提交日期 (年/月)2022-06-02
審查日期 (年/月)2022-06-30

編輯此 RFC

編輯 RFC 中繼資料

摘要

這個 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

社群媒體化：

與 Fuchsia Input 團隊在文件審核期間討論了這項 RFC，並要求審查隱私權和安全性。

設計

活動狀態

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

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

如果裝置最近沒有收到活動，即視為「閒置」。

使用者輸入互動僅限於初次實作時採用下列用途。

相關規定

下列使用者互動「必須」導致服務進入或更新「有效」狀態：

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

下列使用者互動「應」導致服務進入或續訂「有效」狀態：

  • 使用者啟用或停用螢幕閱讀器。如果使用者採用上述其中一種輸入模式執行這項操作，系統就會以隱含方式擷取動作。或者，如果是透過變更 SetUI 執行此操作，建議將其視為打開裝置機蓋的外觀。
  • 使用者打開裝置蓋。
  • 使用者開啟了裝置。

下列互動因內嵌的對應原因而不屬於主動的使用者輸入活動。因此，這些執行個體「不得」讓服務進入 active 狀態：

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

通訊協定與服務

我們在合作夥伴 SDK 引進了新的內部 FIDL 通訊協定 fuchsia.input.interaction.observation.Aggregator 和新的 FIDL 通訊協定 fuchsia.input.interaction.Notifier。這些通訊協定將會由「Input Pipeline」元件中的新的 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;
    }) -> ();
};

與同時收集離散和持續事件的前版本不同 (即具有開始和結束時間的活動)，這個通訊協定的初始版本只會收集「Discrete」活動。最初導入收集進行中事件的功能，是為了支援媒體播放，而這明確不是這個 RFC 的用途。

fuchsia.input.interaction.Notifier

這個 API 的用戶端應訂閱使用者互動「有效」和「閒置」狀態 (與 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 通訊協定不同，因為這個通訊協定會使用等待的 get 模式，完全不再需要 Listener 通訊協定。也不會傳送時間戳記。

蓋子感應器

UI 活動服務可以使用 fuchsia.hardware.input FIDL 監看固件感應器驅動程式庫程式報告，並在收到打開的報告開啟時轉換至使用中狀態。

與輸入管道整合

空間注意事項

在輸入管道 (IP) 元件中實作 UI 活動服務 (A) 而非將其當做自己的元件，視產品和主面板的設定而定，可將約 172 KB 的磁碟空間節省約 172 KB。如果是空間受限的產品，您可以縮減大小來釋放空間，以改善系統中的其他方面。

建構 A IP IP + 兩個 FIDL
工作站_pro.chromebook-x64 196 KB 1364 KB 1388 KB
Core.astro 184 KB 688 KB 700 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. 透過 fuchsia.input.interaction.observation.Aggregator 產生相關 InputHandlers 報告活動。注意：建議您在這個階段 (而非繫結階段) 回報活動，因為 InputHandlers 負責將資訊從 InputEvents 分派至其他元件或服務。受影響的處理常式包括：
  • 媒體按鈕處理常式
  • MouseInjectorHandler
  • TouchInjectorHandler
  • KeypressHandler (新推出)
  1. 針對以下情況新增整合測試：
  • fuchsia.input.interaction.observation.Aggregator 會告知活動狀態
  • 系統轉換為使用中時，fuchsia.input.interaction.Notifier 會收到通知
  • 當系統轉換至 IdP 時，系統會通知 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 呼叫設下頻率限制至 Activity Service。

我們可以監控現有的效能測試 (例如輸入延遲測試)，藉此判斷變更是否會降低迴歸效能。

安全性考量

UI 活動服務的主要濫用向量是使用 fuchsia.input.interaction.observation.Aggregator 明確回報活動來維持系統喚醒狀態。舉例來說，惡意應用程式可能會定期回報活動，藉此維持系統的喚醒狀態。由於 fuchsia.input.interaction.observation.Aggregator 只能在樹狀結構內使用，而非在 SDK 中提供，而且只會供 UI 領域中的元件使用，因此這種風險相當低。

這類服務可能會延遲軟體更新、讓螢幕保持解鎖狀態、耗電電力，甚至拒絕在裝置上透過其他應用程式提供服務。委派資料存取權並非由此 RFC 解決，使用這項服務時，如果用戶端需要閒置狀態的功能 (如上述功能)，應實作自己的活動上限，例如在使用者活躍 24 小時後，強制執行強制系統 OTA。

由於這項能力必須透過 CFV2 轉送，因此平台只授予向輸入管道回報活動報告的權限，以及可能的 A11y Manager 在平台層級回報活動，而且產品可進一步轉送至受信任的元件。

隱私權注意事項

雖然 UI 活動服務不會公開使用者活動性質的任何資訊，但會透過 fuchsia.input.interaction.Notifier 分享活動最近是否發生在預設時間門檻內。

使用者是否在特定時間使用裝置或在特定時間使用裝置，這都會影響隱私權及敏感度，因此我們不希望不受信任的元件存取這些內容。由於這項功能必須透過 CFV2 轉送，因此平台應只授予平台層級受信任活動的能力，且產品可進一步轉送至受信任的元件。

請注意，系統不會向訂閱者提供時間戳記。

測試

我們的測試策略包括

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

說明文件

這項服務將提供 README 總覽，新的 FIDL 通訊協定也會以內嵌註解的形式提供。

缺點

輸入管道失敗

如果輸入管道恐慌或死結，UI 活動服務也會失敗。在這種情況下，使用者變更閒置狀態的變更，可能會想將他們預設為活動狀態而非閒置狀態行為，而應採用其他緩解措施，例如活動逾時時間上限，確保關鍵程序仍可發生。如果輸入管道無法接收或回應輸入報表，代表系統中的問題可能更大。

替代選項

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

這個方法偏好建立新的 fuchsia.input.interaction.observation.Aggregator 通訊協定。

  • 目前的通訊協定位於合作夥伴 SDK 中，且無法限定為使用私人 SDK 使用。加入合作夥伴 SDK 將要求額外的 CTS 測試要求。
  • 集結網站可以更清楚指出通訊協定的行為。
  • 目前的用途組合不需要使用 StartOngoingActivity 或 EndOngoingActivity，未來需求也可以重新評估目前的模式。

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

這個方法偏好建立新的 fuchsia.input.interaction.Notifier 通訊協定。

  • 目前的通訊協定可透過 fuchsia.ui.activity.control.Control 通訊協定控管。
  • WatchState 通訊協定必須遷移至提議的 hanging-get 模式。
  • WatchState 通訊協定會不必要地發布時間戳記，我們不希望用戶端在沒有具體用途或意圖公開的情況下依賴該時間戳記。

納入其他活動信號

某些信號可能將部分使用者流程中的活動視為活動，其他信號則不屬於其他信號。因此，解讀信號的正確性會因特定板型規格或服務的需求而異。

建議您使用 fuchsia.input.interaction.Notifier 通訊協定來取用 UI 活動狀態，並可與其他形式的活動 (例如音訊、麥克風或相機) 進行參照，依個別情況判斷相關的最終使用者或系統狀態。舉例來說，螢幕保護程式功能可能只會查詢使用者輸入活動，而螢幕鎖定功能可能會同時參考使用者輸入活動和使用者驗證狀態。

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

日後，某些服務可能會想遵循由使用者輸入模式組合所決定的活動狀態，例如近期觸控，而非最近的按鍵動作。這會在可能的輸入模式之間引進指數組合。

由於目前缺乏對於更精細功能的需求，我們決定不要提早導入這種複雜性。

整合 Fuchsia 的系統驗證

系統驗證和 UI 活動服務都重視使用者行為的概念，但幾乎不會實際重疊。舉例來說，系統驗證關注的是更精細的使用者狀態狀態，包括使用者與裝置之間的距離，以及使用者是否為帳戶擁有者。

雖然追蹤使用者活動的方式可能同時兼顧兩種用途，但不需要在沒有駕駛用途的情況下主動整合這兩個系統。

未來的工作

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

某些服務日後可能會想自行決定使用者輸入互動的回訪率門檻。雖然這個 RFC 不提供解決方案，但為了簡化初始實作，省略這項功能；建議的通訊協定可在出現具體用途時擴充以增加支援。

先前的圖片和參考資料

  • chrome.idle API 支援「有效」、「閒置」和「已鎖定」狀態。
  • 由於 Root 簡報者的 Fuchsia 活動通知器遭到取消，因此已遭移除。