RFC-0172：界面 Activity 服务

摘要

此 RFC 引入了一项新的 UI Activity Service，用于替换和缩小镜 现有版本的责任。

所提议的服务添加了两个新的 FIDL 协议：

• 私有 FIDL 协议 fuchsia.input.interaction.observation.Aggregator 至 收集用户输入活动的证据，以及
• 要通知的合作伙伴 FIDL 协议 fuchsia.input.interaction.Notifier 用户输入 activity 状态变化的客户端。

设计初衷

我们希望提供一项服务，通知系统的其他部分 近期是否发生用户输入活动。该服务对于 通知其他系统服务，例如省电协议或屏保 功能

“活动服务”自已自建成 系统中用户空闲状态的可信来源。此提案是 弃用了当前方法，引入了新的“界面 Activity 服务” 以缩小责任范围，即仅涵盖用户输入活动 从而实现某些新功能 同时减少其他人的技术债务。

利益相关方

教员：

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， 并请求审核隐私权和安全性。

设计

activity 状态

活动是指最近发生的用户与设备的输入互动。

最近定义为某些产品配置的时间阈值，例如15 分钟。

如果设备最近未收到活动，则被视为空闲。

用户输入互动仅限于下列针对 初始实现。

要求

以下用户互动必须导致服务进入或续订 活动状态：

• 用户轻触了屏幕。
• 用户与鼠标或键盘互动。
• 用户按下了媒体按钮，例如音量调高或音量调低按钮。

以下用户互动应导致服务进入或 续期 active 状态：

• 用户启用或停用了屏幕阅读器。如果用户使用 上述输入模式，则系统将隐式捕获该操作。 或者，如果通过更改 SetUI 来实现，则建议 视为类似于打开设备盖子
• 用户打开了设备盖。
• 用户开启了设备。

以下互动不会被视为有效的用户输入活动，因为 与其以内嵌方式给出的相应理由进行比较。因此，它们不得导致 在服务进入 active 状态：

• 用户观看视频或收听音频文件： 应使用 fuchsia.media.ActivityReporter 而非 activity 服务。

协议和服务

我们引入了一个新的内部 FIDL 协议， fuchsia.input.interaction.observation.Aggregator 和新的 FIDL 协议 将 fuchsia.input.interaction.Notifier 添加到合作伙伴 SDK。这些协议 由 Input 中的新 Activity 类实现和提供 流水线组件。

fuchsia.input.interaction.observation.Aggregator

此 API 的客户报告称，他们认为自己有证据表明 并且我们会直接对其信息进行处理。因此，访问权限 仅限通过 capability 路由实现的树内组件。请参阅 安全注意事项。

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;
    }) -> ();
};

与其前身不同，后两者同时收集离散事件和持续事件（即 具有开始和结束时间的活动）、此协议的初始版本 仅收集“离散”类型的数据activity。能够 收集持续性事件最初是为了支持媒体播放， 这显然不是此 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 协议，因为它将使用 挂起 get 模式，完全不再需要 Listener 协议。它 也不会发送时间戳。

盖子传感器

界面 Activity Service 可以使用 fuchsia.hardware.input FIDL 来监控 盖子传感器驱动程序报告，并在收到 合盖后打开的报告。

与输入流水线集成

空间注意事项

在输入流水线 (IP) 中实现界面 Activity 服务 (A) （而非作为其自身的组件）可以节省大约 172 KB 的磁盘空间， 具体取决于产品和板级配置空间有限 产品，从而缩减应用大小，从而为系统的其他改进腾出空间。

其他注意事项

在输入流水线中集成界面活动服务包括： 以下：

• 该服务应为单线程服务，因为它没有必要； 对多线程有利此外，输入流水线 以及对库进行转换，以支持多线程处理 会造成不必要的复杂性。
• 该服务应在 Rust 中实现，以避免增加复杂性 在一个库中管理多种语言。
• 该服务在恢复模式下不可用，因为恢复模式 不使用输入管道或场景管理器。缺少活动 恢复模式服务就不会成为问题了 使用单个高度集成的组件来最大限度地减少依赖关系。
• 服务不应通过将事件标记为已处理或InputReport来处理 并将它们发送到其他组件 为确定客户是否负责提供更多信息， 近期发生的一些活动
• 服务不应对输入事件的来源有特别的了解 （因为这些内容应通过 fuchsia.input.interaction.observation.Aggregator）。
• 因此，该服务不应实现为 InputHandler。

可配置的空闲阈值

空闲阈值是指距离用户上一次活动已经过去多长时间 进入空闲状态。这可以使用结构化配置 输入管道或 Scene Manager 组件中的 API，并将 设置为 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 会通知 activity 状态
• 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

性能

界面 Activity 服务不得增加输入事件的处理延迟时间 。

虽然所提议的协议不会引入异步或计算密集型 逻辑，我们可能需要对高频输入事件进行节流。对于 例如，老鼠通常每秒发送大约 1000 个事件，因此， 可对从 MouseInjectorHandler 到 Activity 服务。

我们可以监控已存在的性能测试（例如输入延迟测试）， 可辨别是否改变了回归性能。

安全注意事项

界面 Activity 服务的主要滥用途径是使系统保持唤醒状态 通过使用以下代码不真实地报告活动 fuchsia.input.interaction.observation.Aggregator。例如， 应用可以定期报告活动，使系统保持唤醒状态。这是 被认为是低风险 fuchsia.input.interaction.observation.Aggregator 仅在树内可用， 且只能由界面领域中的组件使用。

像这样的服务都存在延迟软件更新的风险， 屏幕解锁、耗尽电池电量，并且可能拒绝提供服务 和设备上的其他应用委托数据访问机制 此 RFC。客户端依赖空闲状态来实现上述功能 在使用此应用时应实现自己的活动数上限（如果相关） 服务，例如在用户活跃 24 小时后强制执行系统 OTA。

由于此功能必须通过 CFV2 路由，因此需要注意， 平台仅授予将活动报告给输入流水线和 例如在平台层面设置无障碍经理 路由到受信任的组件

隐私注意事项

虽然界面 Activity Service 不会公开任何有关应用 但也会分享用户活动近期内是否发生 通过 fuchsia.input.interaction.Notifier 预设时间阈值。

无论某人在特定时间在身边或使用其设备，都属于保护隐私 因此，我们不希望它变得不受信任 哪些组件可以使用由于此功能必须通过 CFV2，需要注意的是，平台应仅授予观察权限 在平台层面上可信赖的活动，并且产品可以进一步 路由到受信任的组件

具体而言，订阅者无法查看时间戳。

测试

我们的测试策略包括

• 单元测试
• 使用现有工具进行集成测试

文档

该服务将包含 README 概览，而新的 FIDL 协议将 并附上注释。

缺点

输入流水线故障

如果输入流水线紧急警报或死锁，UI Activity Service 也会 失败。在这种情况下，空闲状态变化的订阅者可能希望默认为 活动状态行为而非空闲状态行为， 缓解措施（如最长活动超时）， 仍然可以正常进行如果输入流水线无法接收 或响应输入报告，则系统中可能存在更广泛的问题。

替代方案

使用现有的 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 协议 用于使用界面 activity 状态，并且可与 其他形式的活动（例如音频、麦克风或摄像头）来确定 视具体情况而定。对于 例如，屏保功能可能只查询用户输入 activity，而 锁屏功能可能会同时查询用户输入 activity 和用户 身份验证状态。

支持配置部分需要考虑的活动类型

将来，某些服务可能希望跟踪 activity 状态， 由部分用户输入模式决定，例如最近接触过，但不是近期 键。这会在可能出现的 输入法。

考虑到人们目前对更复杂的功能缺乏兴趣，我们决定不 过早引入这种复杂性。

与适用于 Fuchsia 的系统身份验证集成

系统身份验证和界面活动服务都关注 同时尽量减少实际重叠。例如，系统 身份验证关注一组更精细的用户在线状态， 包括用户与设备的距离以及用户是否为账号所有者。

尽管可以通过一种适合 但可能没必要主动将二者集成 而无需考虑驾驶用例。

未来工作

允许订阅方配置空闲时间阈值

今后，某些服务可能需要确定自己的新近度 用户输入互动的阈值虽然此 RFC 没有建议 解决方案，为了简化初始实现，省略了这一功能， 可以扩展建议的协议，以便在具体用例时增加支持 出现了。

先验技术和参考资料

• chrome.idle API 支持“活动”“空闲”和“锁定”状态。
• 由于未使用，Fucsia 在 Root Presenter 中的 activity 通知程序已被移除。