YZHLX/ THE OPEN LAB
未完成的实验档案
全部项目
PROJECT FILE / 03Android
开发中2026

Android 屏幕分身与自动化

在另一块屏幕里,把动作做对

基于开源 VirtualDisplay、Shizuku 与 scrcpy 的二次开发。我探索无预览抓帧、定向输入、状态识别,以及可停止、可核对的 QQ 宠物自动化。

我负责
自动化层二次开发、流程约束、设备联调与验收组织
协作方式
基于第三方开源项目的个人探索 · AI 辅助
技术与工具
Kotlin / Android / Shizuku / scrcpy / 模板匹配 / ML Kit
源码
GitHub

验证与边界

有依据的进展

  • 基础虚拟显示工具具备创建、应用启动、预览与触摸能力,属于上游基础
  • 我的扩展有无预览抓帧与指定 displayId 单次输入的设备验证记录
  • 浮动预览 MVP 已合并;后续功能分支记录了护理与冒险方案的真机闭环

还没验证,或需要留意

  • 上游 Ynkcc/VirtualDisplay 的原有能力不属于我的原创成果
  • PR #3、#4 尚未合并;不能将分支验收等同于默认分支正式交付
  • 课程扫描、设备兼容性、长期稳定性仍有边界;不是成熟商业托管产品

开发记录问题、取舍与过程

先分清“屏幕分身”和我的扩展

这个仓库建立在 Ynkcc/VirtualDisplay 上。创建虚拟显示、自定义分辨率与 DPI、启动应用、预览与触摸,来自上游工具;Shizuku 与 scrcpy 也各自提供了重要基础。我的探索主要发生在这些能力之上的自动化链路。

我想弄清楚:不打开预览窗口时,能不能可靠地拿到虚拟屏画面?一次触摸能否只送进目标显示,而不落到物理屏幕?如果页面状态不确定,执行流程该怎样停下来?

从抓到画面,到确认动作落在哪里

仓库中的早期 Gate 验证使用了无害测试页面:先在没有预览的情况下抓帧,再向非零 displayId 注入一次触摸,同时确认物理屏测试页面的计数没有增加。这证明了当时设备和 APK 下的短时路径,不能据此推断所有手机、锁屏状态或长期运行都稳定。

后续扩展围绕画面识别、护理、学习和打工状态推进。相比固定坐标连续点击,我更关心页面身份、读数来源、停止条件和执行回执是否能对应起来。

共享画面,不抢占 Surface

已合并的浮动体验 MVP 让自动化链路保持唯一画面来源,预览只订阅缩略副本。没有订阅者时跳过缩放,并限制刷新频率,避免预览和执行链路争抢画面。部分浮动交互参考并改写自 Mika,仓库保留 Apache-2.0 第三方声明。

分支有进展,不代表产品完成

后续未合并分支已把应用命名为“蟹啦”,并留下特定设备上护理、冒险等方案通过的记录。较早的记录也包含学习成功路径,但新版的每个分支、课程和设备仍需独立验收。

我会把这些当作有边界的工程证据,而不是无限挂机、全流程自动化或普遍兼容的承诺。当前首页展示的是技术结构示意,不是假造的产品运行截图。

这份记录从哪里来

资料核对于 2026-11-12。以下是整理时阅读的文件与记录,不代表本次重新执行了源项目的硬件、部署或完整回归。

下一个项目Personal Ledger Hub