[android] 明确移动端能力边界：裁撤计划项并开放贡献入口

[HKLHaoBin]

现象

Android 端与桌面端能力边界此前未在 issue 层统一收口，存在以下问题：

1. 概览页录音按钮：supportsInAppDictation 与文案暗示存在应用内录音入口，但概览页从未实现该按钮，实际听写入口为悬浮窗。
2. IME v2：docs/android-mobile-apk-overlay-plan.md 将其列为跨 App 输入主路径，但尚未落地，需明确由社区贡献推进。
3. 提供商选择器：Android 端百炼等 provider 的配置体验弱于桌面（如无统一模型下拉），缺少明确的贡献引导。
4. 录音反馈（AudioCue）：Android 端已禁用，与麦克风路由存在冲突，不宜继续保留为计划项。
5. 本地 ASR：计划文档将 Foundry / Sherpa / Qwen 等桌面本地引擎排除在 Android 首版之外，但缺少对外说明与 PR 入口。
6. 远程输入：桌面端已有局域网 HTTPS+WS 远程输入服务；在 Android 端重复实现「手机录音 → 电脑输入」成本高且易造轮子。
7. 误导文案：设置页 androidReadOnly 写「请在概览页使用录音按钮」，与真实入口（悬浮窗）不一致。

影响

• 贡献者与用户无法判断哪些 Android 能力是「官方会做」还是「欢迎 PR」还是「明确不做」。
• 误导文案增加支持成本，削弱悬浮窗作为唯一听写入口的产品语义。
• 重复投入远程输入 / 本地 ASR / 录音按钮会分散 Android 主线（悬浮窗 + 云端 ASR/LLM + 无障碍插入）的维护精力。

建议接受标准

明确不做 / 移除计划

• 概览页录音按钮：不再开发；从路线图与相关文档中移除该入口预期。
• 录音反馈（AudioCue）：因与 Android 麦克风路由冲突，不再保留为计划功能；清理相关 TODO / 文案中对「后续恢复」的暗示（若存在）。
• Android 本地 ASR（官方实现）：官方不纳入实现计划；设置与文档不再暗示「即将支持桌面同款本地引擎」。
• Android 端远程输入（自研）：不在本仓库重复实现手机端远程录音客户端；桌面端现有远程输入能力保持现状即可，Android 侧不新增对等模块。
• 误导文案：移除 settings.shortcuts.androidReadOnly 等「请在概览页使用录音按钮」类提示；Android 听写入口统一表述为悬浮窗。

欢迎社区贡献（开放 PR）

• IME v2 键盘模式：在 issue 中明确招募贡献者，欢迎提交 PR 实现 OpenLessImeService 跨 App 文本输入（参见 docs/android-mobile-apk-overlay-plan.md § IME v2）。
• 提供商选择器 / 配置引导：欢迎 PR 补齐 Android 端 ASR/LLM 提供商的配置引导（例如百炼统一模型选择器、ElevenLabs / StepFun 等 preset 的说明与校验流程），对齐桌面体验但不阻塞主线发布。
• Android 离线 ASR（贡献者主导）：官方不做，但保留贡献入口——有能力的贡献者可提交 PR 为 Android 新增独立离线 ASR provider（不要求与桌面 Foundry/Sherpa/Qwen 同实现）；需在 PR 中说明包体、性能与权限影响。

远程输入：探索外部集成而非自研

• 在 issue 中探讨是否可将**已有的 Android 端远程输入（手机录音 → 电脑光标）**能力以集成方式接入 OpenLess，而非在本仓库重写客户端。
• 若集成不可行，在文档中一句话说明：Android 用户可使用桌面端「远程输入」+ 手机浏览器，或第三方工具，本仓库不提供独立 Android 远程输入 App。

协作邀请

欢迎以下与 OpenLess Android / 移动端语音输入相关的贡献者参与讨论集成或 PR 方向：

• @HKLHaoBin — Android 移植与移动端流水线
• @appergb — Android 运行时维护
• @H-Chris233 — ccbili30-collab/openless-andriod 相关贡献

若你正在维护独立的 Android 远程听写 / 手机录音推送到电脑工具，也欢迎在下方留言，探讨与 OpenLess 桌面端远程输入或听写链路的集成可能性。

TODO / 不确定项

• IME v2 PR 的验收标准（权限引导、与现有 android_insert_strategy 的关系）需维护者补充。
• 离线 ASR 贡献 PR 是否要求与 PlatformCapabilities.supportsLocalAsr 挂钩，或作为独立 experimental provider 存在。
• 远程输入外部集成：待被 @ 的开发者回复前，不预设集成方案（插件 / 深链 / 共用协议等）。

[HKLHaoBin]

补充协作邀请：

注意到 @BurgerK1ng16 维护的开源 Android 输入法项目 Vertick-IME，其能力与 OpenLess 在移动端的目标高度相近，包括但不限于：

• 语音听写 + AI 润色 / 结构化表达（与 OpenLess 听写 → 润色流水线类似）
• Smart Q&A 模式（语音提问 → 文本模型回答）
• 自带 IME 键盘框架（Android InputMethodService，可直接向任意 App 上屏）
• BYOK 云端 ASR/LLM（用户自配 MiMo ASR、OpenAI 兼容文本模型等）
• 离线拼音输入（Rime-Ice / librime，本地优先）

这与本 issue 中「IME v2 招募贡献者」「探索外部集成而非自研远程输入/插入链路」的方向非常契合。若能在 OpenLess Android 侧与 Vertick 的 IME 能力做协议层或体验层集成（而非重复造轮子），可能是一条值得探讨的路径。

@BurgerK1ng16 如有兴趣，欢迎在此 issue 下讨论：

1. Vertick IME 的文本提交接口能否作为 OpenLess Android 的跨 App 输入方案之一；
2. 语音听写 + 润色链路是否有可复用的设计或合作空间；
3. 对「OpenLess 不做概览页录音按钮、以悬浮窗为主入口」这一产品边界是否有建议。

相关仓库：https://github.com/BurgerK1ng16/Vertick-IME

[BurgerK1ng16]

感谢关注 Vertick IME。

我认可 Android 端的方向：相比单独做一个录音转录应用，系统输入法更适合作为跨 App 文本输入入口。Vertick 目前的重点也是把语音听写、润色、离线拼音等内容收敛到输入法内，并尽量保持本地优先。

关于你提到的几个方向：

1. Vertick 的最终文本提交能力可以作为 OpenLess Android 端的输入基础之一，但 Android 的 InputMethodService 受系统输入法生命周期和用户主动启用/切换约束，具体集成方式需要先明确权限、输入焦点、失败回退和隐私边界。

2. 语音听写与润色链路存在明显的合作空间。我更倾向于先讨论可复用的协议与设计原则，例如 ASR 输出格式、流式增量、专业词、润色模式、取消机制和 OpenAI 兼容接口，而不是直接复制彼此实现。涉及代码复用时也需要先确认许可证和署名要求。

3. 我赞同 Android 端不必再做一个以录音按钮为中心的概览页。更合理的形态是：输入法作为主要入口，管理页只承担配置、词典、历史和测试；悬浮窗可以作为横屏或特定场景，可让用户自行选择的补充。

我愿意继续在这个 issue 里讨论。建议先从接口边界和一个最小 Android 集成流程开始，避免两个项目在底层能力上重复建设。

[HKLHaoBin]

已单独开 issue 以多轮 QA 方式澄清 Vertick 键盘集成工程计划；全部轮次回复后再输出可执行方案与接口文档。\n\n→ #845 [android][ime] Vertick 键盘集成 — 多轮 QA 澄清工程计划\n\n当前 Round 1 已发布（许可证 / MVP 范围 / 分工），请 @BurgerK1ng16 按模板回复。

[HKLHaoBin]

已简化 #845：不再分 Round 1–4 逐轮回复，所有问题合并为一条回复即可。收到全部答复后，再据此输出具体工程方案。