RFC-0172：UI 活動服務

摘要

本 RFC 推出新的 UI Activity Service，取代現有版本並縮減其職責範圍。

提案服務新增了兩項 FIDL 通訊協定：

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

提振精神

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

系統中已存在「活動服務」，可做為使用者閒置狀態的資訊來源。這項提案與目前做法不同，並導入新的「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 輸入團隊進行文件審查時，我們討論了這項 RFC，並要求進行隱私權和安全性審查。

設計

活動狀態

活動是指使用者最近與裝置互動的輸入行為。

「最近」是指某個產品設定的時間門檻，例如 15 分鐘。

如果裝置最近未收到任何活動，就會視為閒置。

在初始實作階段，使用者輸入互動僅限於下列用途。

需求條件

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

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

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

• 使用者啟用或停用了螢幕閱讀器。如果使用者透過上述任一輸入模式執行這項操作，系統會隱含擷取該動作。或者，如果透過變更 SetUI 完成這項操作，建議將其視為開啟裝置螢幕。
• 使用者已開啟裝置蓋子。
• 使用者開啟裝置。

由於下列互動的對應理由已內嵌，因此不視為活躍使用者輸入活動。因此，這些事件「不得」導致服務進入「有效」狀態：

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

通訊協定和服務

我們推出了新的內部 FIDL 通訊協定 fuchsia.input.interaction.observation.Aggregator，以及新的 FIDL 通訊協定 fuchsia.input.interaction.Notifier，適用於合作夥伴 SDK。這些通訊協定將由 輸入管道元件中的新 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 定義的初始版通訊協定只會收集「離散」活動。收集持續性事件的功能最初是為了支援媒體播放，但這並非本 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 的磁碟空間，實際情況視產品和主機板設定而定。對於空間受限的產品，縮減大小可釋出空間，以便在系統中進行其他改良。

其他注意事項

在輸入管道中整合 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 會通知活動狀態
• 系統轉換為「Active」時，fuchsia.input.interaction.Notifier會收到通知
• 系統轉換為「閒置」狀態時，fuchsia.input.interaction.Notifier會收到通知

=== fuchsia.input.interaction.Notifier is available for use by clients at this point ===

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 到 Activity Service 的 FIDL 呼叫速率。

我們可以監控現有的效能測試 (例如輸入延遲測試)，判斷變更是否會導致效能回歸。

安全性考量

UI 活動服務的主要濫用向量是透過使用 fuchsia.input.interaction.observation.Aggregator 虛報活動，讓系統保持喚醒狀態。舉例來說，惡意應用程式可能會定期回報活動，讓系統保持喚醒狀態。由於 fuchsia.input.interaction.observation.Aggregator 僅適用於樹狀結構內，不會在 SDK 中提供，且只會由 UI 領域中的元件使用，因此風險較低。

這類服務可能會延遲軟體更新、讓螢幕保持解鎖狀態、耗盡電池電量，以及拒絕為裝置上的其他應用程式提供服務，因此具有風險。委派資料存取權是本 RFC 未解決的風險。如果用戶端依賴閒置狀態來提供上述功能，使用這項服務時，應視情況自行設定活動上限，例如使用者活動時間達 24 小時後，強制執行系統 OTA。

由於這項功能必須透過 CFV2 傳送，因此請注意，平台只會在平台層級授予向輸入管道和潛在 A11y 管理員回報活動的能力，產品則可進一步傳送至信任的元件。

隱私權注意事項

雖然 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 通訊協定必須遷移至建議的暫止式 GET 模式。
• WatchState 通訊協定會不必要地發布時間戳記，我們不希望用戶端在沒有具體用途或公開意圖的情況下，依據該時間戳記運作。

納入其他活動信號

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

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

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

日後，某些服務可能會想追蹤活動狀態，例如最近的觸控但不是最近的按鍵輸入，這類活動狀態是由部分使用者輸入模式決定。這會導致可能的輸入模式之間出現指數組合。

由於目前對更精細功能的需求不高，我們決定不提早推出這類複雜功能。

與 Fuchsia 的系統驗證整合

系統驗證和 UI 活動服務都關心某種使用者行為概念，但實際重疊的部分極少。舉例來說，系統驗證會考量更精細的使用者在場狀態，包括使用者與裝置的距離，以及使用者是否為帳戶擁有者。

雖然可以追蹤使用者活動，以適用於這兩種用途，但如果沒有明確的用途，可能就不需要主動整合這兩個系統。

之後的作業

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

日後，某些服務可能會想自行決定使用者輸入互動的近期程度門檻。雖然這項 RFC 並未提出解決方案，但為了簡化初始實作，省略這項功能，通訊協定提案可能會擴充，以便在出現具體用途時新增支援。

既有技術和參考資料

• chrome.idle API 支援「active」、「idle」和「locked」狀態。
• 由於未使用，Root Presenter 中的 Fuchsia 活動通知器已移除。