RFC-0172：UI 活動服務

摘要

這份 RFC 會引入新的 UI 活動服務，取代現有版本的職責並縮小範圍。

建議的服務會新增兩個新的 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

社會化：

這個 RFC 是在與 Fuchsia Input 團隊討論文件審查時討論過，並要求審查隱私權和安全性。

設計

活動狀態

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

「最近」是指產品設定的時間門檻，例如 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;
    }) -> ();
};

與前一代收集離散和持續性事件 (即有開始和結束時間的活動) 不同，這個通訊協定初期版本 (由本 RFC 定義) 只會收集「離散」活動。收集目前事件的功能最初是為了支援媒體播放，這顯然不是本 RFC 的用途。

fuchsia.input.interaction.Notifier

這個 API 的用戶端應訂閱使用者互動「active」和「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 通訊協定不同，因為它會使用掛起的 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. 透過 fuchsia.input.interaction.observation.Aggregator 回報相關的 InputHandlers 活動。注意：建議您在這個階段而不是繫結階段回報活動，因為 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 目前可供客戶使用 ===

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 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 通訊協定必須遷移至建議的掛起取得模式。
• WatchState 通訊協定不必要釋出時間戳記，我們不希望用戶端在沒有具體用途或意圖公開時間戳記的情況下依賴這項資訊。

納入其他活動信號

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

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

支援設定可考慮的活動類型子集

日後，某些服務可能會根據部分使用者輸入模式 (例如最近的觸控，但不是最近的按鍵輸入) 決定活動狀態。這會在可能的輸入模式之間引入指數組合。

由於目前使用者對更複雜的功能不感興趣，我們決定不急著推出這項複雜功能。

與 Fuchsia 的系統驗證整合

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

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

日後的作業

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

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

既有技術與參考資料

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