butubb/auto_control
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
251 Commits 2 Branches 6 Tags
main
Commit Graph
9 Commits
Author SHA1 Message Date
butubb b98e6deac1 feat(发布计划): 视频发布计划（批量上传配对 → 时间线 → 推送到手机 → 发布任务 → 分享链接） 
一、平台侧（账号 → 发布计划页）
- 新表 video_plan（schema v9→v10）：账号×发布日期×编号 → 素材 + 标题 + 发布状态 + 分享链接；
  状态机 pending/ready/pushing/publishing/done/failed/unknown/skipped（**failed 与 unknown 必须分开**：
  推送阶段的失败可安全重试；碰过抖音之后的岔子只能算"结果未知"，绝不自动重发）
- 素材上传：文件名 `手机号_日期_编号`（编号可省）解析配对；标题 txt `标题内容_手机号_日期_编号`；
  内容寻址落盘 data/videos/YYYY-MM/（sha1 分块算，同名不存两份），**不进整库备份**但进 manifest 反查
- 新蓝图 web/video_plan_api.py：上传/时间线/统计/单条增删改/推送到手机/标记结果/裁决/链接导出 CSV/
  任务列表与一键新建、**就地编辑**（GET/PUT /tasks/<id>）、**一键推送**（POST /push_all，按设备分组、设备内串行）
- 账号页拆子分栏（台账 / 发布计划）+ static/admin/release.js；清理 job（04:41 僵尸回收+过期行、04:47 素材文件）
- 上传体积：MAX_CONTENT_LENGTH（默认 2GiB）+ 413 JSON + nginx client_max_body_size（修现有 APK 上传隐患）

二、任务侧（平台推素材，抖音流程你自己写）
- 新步骤 push_release「推送发布视频」：原子占位 → adb push → **touch 改成"现在"** → 清旧目录同名副本 →
  触发扫描并**按路径**校验相册索引 → 标题写进剪贴板；默认目录 /sdcard/DCIM/Camera
- 新步骤 mark_release「标记发布结果」：回写 done/failed/unknown，成功时抓作品分享链接、删手机素材
- input_text 支持 text_source=release_title（自动取计划标题 + 回读校验）；
  if_el 的候选值来源新增 release（**本机当前发布计划**的抖音号/昵称，发布前校验"登的是不是要发的号"）
- build_release_steps 骨架 15 步：⓪ 亮屏 → ① 打开抖音(等首页) → ② 点「我」→ ③ 等抖音号出现 →
  ④ 条件判断(账号) → then ⑤ 推送 ⑥⑦⑧⑨⑩⑪⑫ 抖音点击/填标题 → ⑬ 标记 / else 发通知跳过

三、修（推送这一路的检测机制）
- **uiautomator2 3.x 的 d.shell() 返回 ShellResponse（tuple 子类）不是 str**：`'x' in resp` 恒 False、
  `.strip()` 不存在 → "推上去的文件大小不对"每次都判失败（文件其实推上去了）、相册校验永远报没进、
  删除确认永远判没删掉。新增 publish_flow._sh() 统一取 .output；大小改成解析 ls -l 的大小列
- **adb push 保留本地 mtime** → 推 3 天前上传的素材在按时间排序的相册里排不到最前，
  "点第一个 = 刚推的那个"不成立 → 推完 touch
- 相册校验**按路径**比（MediaStore 的 _data 会把目录小写、/storage/emulated/0 ≡ /sdcard），
  只比文件名会被老目录的同名残留骗过去
- 屏幕没亮就启动抖音会永远停在启动页（UI 树为空）→ 后面"点我/等抖音号"必然 miss，
  最后报成误导人的"账号不符" → 骨架第一步固定加「亮屏」，open_app 等「首页」出现

四、其它
- core/ledger.serial_of()：设备名 → 当前地址（设备换 IP 后快照是错的）
- 通知事件 task.video.published / task.video.failed；备份清单加 video_plan 与素材统计
- 文档同步：DATA_MODEL §2.11 + schema v10、API（新接口与语义）、TASK_DEV §4.7 专章、
  ARCHITECTURE（账号页子分栏/release.js/两个 job）、DEPLOY（表数/nginx）、NOTIFY、DEVELOPMENT、README
 2026-09-28 15:59:09 +08:00
butubb bf432b4f56 Merge branch 'fix/device-name-display'——选择设备与所有通知显示设备名（不再显示 IP）+ 修 /locate 500/XSS 2026-09-24 09:17:15 +08:00
butubb 8fdde978ea fix(设备名): 选择设备与所有通知都显示名称而不是 IP 
用户反馈：① 元素抓取的选择设备列表显示的是 IP；② 所有 webhook 通知里都是 IP；
要都显示设备名。

- 通知链路统一补名字（调用点不用动）：`core/notifier.py`
  · 新增 `set_device_name_resolver()` + `fill_device_names()`，在 `notify()` 与
    `build_message()`（预览/测试发送也走它）里把 `serial` 补成 `device_name`、
    把 `serials`/`devices` 列表逐项换成名字。
  · 补一处就全带名字了——标题主体、字段表、聚合样本认的都是 `device_name`。
  · **做成"纯内存回调"是刻意的**：notify() 的硬红线是零 DB，不能为了取个名字去查库
    （那等于在业务线程里加一次阻塞查询）。
  · 降级规则：调用点自己传了 device_name 就用它的；查不到名字（没命名/不在池里）
    保留原地址；解析器缺失或抛异常都只是降级，绝不影响发送。
- `core/device_pool.py`：维护 `serial → 名称` 内存快照——`init_app` 同步刷一次、
  增删改名/迁址后各刷一次（改名立刻生效）、`device-names` 线程每 60s 兜底刷一次
  （覆盖整库恢复这类进程外改动）。`name_of()` 只读内存，可在通知路径上安全调用。
- `web_server.py`：装配层接上 `notifier.set_device_name_resolver(device_pool.name_of)`。
- 元素抓取/测试此步骤的设备列表：`GET /api/uiauto/devices` 的 `name` 改用**平台名**，
  前端 `editor.js` 新增共用的 `_devCard()`——名字做主标题（粗体），
  `型号 · 地址` 作副标题。
  · 池外设备**退回地址而不是 uiautodev 的 name**：实测那份 name 是设备 codename
    （一柜子机器全叫 "earth"），拿它认设备等于没名字，地址至少唯一。
  · 「测试此步骤」的设备列表原来连状态角标都没有，一并统一成同一个卡片。
- 顺带修一个**既有 bug（不是本次需求）**：`/locate` 设备端定位页从 ce47a5b 那次
  web 蓝图拆分起就一直 500——拆分时漏掉了 `render_template_string` 与
  `markupsafe.escape as _esc` 两个 import。后者不只是缺个名字：定位页把 query 里的
  serial 拼进 HTML，而 `render_template_string` 的模板名是 "<template>"、
  **不会自动转义**，所以那还是个反射 XSS。已显式转义（已用 `<img onerror>` 验证）。

自测：device_pool 快照/改名即时生效、fill_device_names 全分支（含列表、
未命名保留地址、不在池保留地址、解析器缺失/抛异常降级）、真消息渲染断言
**通篇不含 IP**；GET 路由冒烟 54 个 0 个 500；前端语法 + 卡片渲染截图核对。
 2026-09-24 08:55:10 +08:00
butubb beb51637dd feat(设备): 电量显示（大屏 + 监控页）+ 低电量 webhook 告警 
需求：大屏和监控页都要能看到每台设备的电量，并且"低于多少电量就发通知"。

数据从哪来：`adb -s <serial> shell dumpsys battery`（**只读**，实测 0.2~0.35s/台，
11 台并发一轮 0.44s）。设备只要在 `adb devices` 里就说明 transport 现成，
**不需要 connect**——所以连空闲设备也能查。这是本模块敢每轮扫全量的前提，
也是这条只读路径与"空闲设备不主动 connect"红线（DEVELOPMENT.md §2 #3）的边界，
已写进文档免得后人误加 connect。

- core/device_battery.py（新）：后台 daemon 线程 `device-battery`（照 device_discovery
  的 init_app/shutdown 模式），默认 60s 一轮，采「设备池 ∩ 在线」（与 list_ready 同口径，
  adb 可见但不归平台管的设备不上屏也不告警）。
  · 结果**只放内存**（不落库 → 不建表、不动备份覆盖清单），离线设备保留最后读数；
  · 读失败不清缓存：list_devices 失败时若照清会把整份缓存抹掉、大屏全体变「—」；
  · 配置存 `app_meta.device_battery`（照 step_defaults：出厂值 + 白名单 + 范围钳制 +
    只落与出厂值不同的字段），改阈值不用重启（线程每轮重读配置）。
- 告警：事件 `device.battery.low` / `device.battery.recovered`（默认关，去通知页勾订阅）。
  **按档位做状态沿**（0 正常 / 1 低 / 2 严重）：掉档才报、严重再报一次、恢复报一次；
  迟滞 +5% 避免在阈值上下反复告警；同档位每 6h 重复提醒一次。
  "充电中"看的是 `status:` 行（2/5），**不是"插着电"**——所以"插着却没充电"
  （劣质线/温控/满电停充 status:4）仍会告警，那正是最该知道的情况（实测 fleet 里
  就有一台 8% 插着 AC 但 `Max charging current: 0`）。
- GET /api/status 每台设备多一个 `battery`：`{level,charging,at,tier}`。
  **tier 由后端算好**，前端只按它上色——阈值只在「工具 → 设备发现 → 电量监控」一处定义，
  免得 JS 里再判一遍、两边不一致。
- 前端：大屏卡片型号行右侧加电量徽标（绿/黄/红 + ⚡ 充电中，离线置灰），
  `cardHtml`/`renderGrid` 增量更新/脏检查白名单三处都改了（漏一处就不刷新）；
  监控页设备表新增可排序的「电量」列（空表 colspan 11 顺带对齐了）。
- 接口：GET/POST /api/devices/battery[/settings] + POST /scan（需设备权限，
  与 /api/devices/discovery/* 同权限档）。

自测：单元 30 项（解析真机输出/档位/状态机/钳制，含 scale=255、无 status 行、
垃圾输出等边界）、集成 27 项（临时库自建设备池：缓存/通知/离线保留/删设备清理/
配置往返/阈值改动即时生效）、真实 11 台设备一轮 0.44s 全读到、API 端到端
（登录/权限/钳制/越界/REST 往返/页面 DOM）、两份前端各自语法检查 + 渲染用例。
 2026-09-24 08:37:42 +08:00
butubb c29516cff5 feat(任务): 任务级「公共巡检」——独立于步骤画布的守护条件（含 webhook 通知） 
需求：任务编辑器里能单独配"这个任务每隔 N 秒检查一次"——熄屏就点亮、某个元素
出现就通知、掉出 App 就停本设备；通知标题正文要能自己写。

配置与执行分离（这是本次的关键设计）：
- **配置是任务级的**（`params.watchers`），在任务编辑器单独一块，不进步骤画布；
- **执行是穿插的**：worker 每执行完一步、以及长等待的每个分片，看一眼哪个巡检
  到点了。不起线程 → 不需要并发模型，也不会和主流程抢屏幕（两边同时点屏幕会
  互相打断）。代价是精度受步长影响（某步卡 30s，巡检最多晚 30s），已在文档写明。

- core/patrol.py（新）：检查项/动作注册表（CHECKS/ACTIONS）+ evaluate/act。
  检查：屏幕熄灭/亮着、元素存在/不存在、前台是/不是某 App；
  动作：只通知、点亮、息屏、停止本设备。屏幕走 `dumpsys power`（0.3s，
  不用 d.info——那玩意在部分设备要 14s），前台走 d.app_current()（0.7s）。
- tasks/generic/task.py：`_maybe_patrol` / `_run_patrol`（冷却、命中记一条
  步骤明细、发通知）；**文案在动作之前渲染**——点亮后 {screen} 就成了"亮屏"，
  用户要看的是"发现熄屏，已点亮"。
- 任务编辑器新增「公共巡检」块（static/admin/tasks.js）+ 样式；保存进 params.watchers。
- 通知：新增事件 `task.patrol.hit`（巡检命中）与 `task.notify.custom`（步骤发通知）；
  给了 title 就用它当标题（不再拼前缀），level 字段可点名级别。

顺带（巡检需要的原语，也可单独用）：
- if_el 条件判断支持 `selector_type=screen`（亮/熄）与 `foreground`（前台包名）；
  非元素条件不参与「选择器健康」统计（否则会攒出假的"选择器失效"告警）。
- 新增两个步骤：`notify`（发自定义通知）、`stop_self`（停本设备，记"被停止"
  而不是失败，不触发重试）。步骤类型 18 → 20，相关文档计数一并更新。

修 bug：`wait` 步骤在巡检耗时超过剩余时间后 `sleep(负数)` 抛
"sleep length must be non-negative"（真机联调抓到，已 clamp 到 0）。

自测：假设备单测 12 组（命中/冷却/间隔/元素/前台/停止/静默/异常不炸）；
真机联调：熄屏→点亮（False→True）+ 通知文案正确、掉出抖音按间隔命中 5 次、
长等待里穿插生效且步骤回到 ok、清理后用户通知配置原样恢复。
文档：TASK_DEV §4.5（含两个可抄的例子）与步骤表/条件类型、NOTIFY §3、README。
 2026-09-16 13:02:40 +08:00
butubb 16e3e162b2 fix(通知): 多设备批次不再逐台报成功；批次汇总瘦身并列出失败设备；设备只显示名字 
用户反馈：一条任务覆盖 13 台设备，每台成功都推一条，群里被刷屏；批次汇总里
「任务：抖音养号」与标题重复、「样本：抖音养号」毫无信息量、「stopped」还是英文。

- task_manager：
  · **多设备批次不发 `task.device.success`**（批次汇总里已有成功台数；单台任务照发）；
    失败仍逐台发——那是少数，且要知道是哪台；
  · `_BatchTracker` 收集失败设备（`名字（型号）：原因`，最多 5 条）并加进批次汇总；
  · 设备级事件带 `model`：型号取自**设备池快照**（批次开始时一次查好带下去），
    不是 worker 每次连接现采的（那次 `d.info()` 可能超时 → 空），也不查库；
- notifier：
  · 聚合窗口口径修正：事件声明 `agg_window=0`（批次结束/服务启停/备份恢复等低频
    高危事件）**不再被 hook 的窗口拖住**——原先事件级设置完全失效；
  · 「样本」行只在真的合并了多条(>1)时出现，且按**设备**维度写（合并多台时写
    任务名每条都一样）；与标题重复的字段行（「任务：x」）不再重复渲染；
  · 设备名与地址同时存在时**只显示名字**（IP 是给日志看的）；
  · 补 `stopped`/`failed_devices` 中文标签（原先直接显示英文 key）；
- notify_events：批次事件补 `skipped`/`failed_devices` 字段，设备事件补 `model`。

实测（dev 真机 + 假接收端）：
  批次 2 台 → 只收到 batch.started/finished，无 device.success，汇总 总数2/成功1/跳过1；
  单台任务 → 收到 device.success，显示「设备：cs1 / 型号：M2010J19SC」不含 IP。
文档：doc/NOTIFY.md §3（多设备批次怎么发 + 批次消息样例）、§6（窗口口径与注意事项）。
 2026-09-16 09:47:25 +08:00
butubb 3b6ec8c98f feat(通知): 加钉钉 / 飞书两种格式（含各自的加签算法） 
## 两家签名算法不一样，照抄必错
| | 钉钉 | 飞书 |
|---|---|---|
| HMAC key | `secret` | `"{timestamp}\n{secret}"` |
| 被签内容 | `"{timestamp}\n{secret}"` | 空 |
| timestamp | 毫秒 | 秒 |
| 拼在哪 | URL query | JSON body |
| 结果 | Base64 再 urlencode | Base64 |
| 出错码 | `errcode 310000` | `code 19021` |

实现为 `BaseAdapter.sign_request()` 钩子（默认不动），两家各写各的；
`core/notifier.py` 的 `_post_once` 在发请求前调用它。

## 另外
- 钉钉：markdown 消息（title+text）；成功码 0；默认限流 15/分（官方 20/分，**超限会被限 10 分钟**，留余量）
- 飞书：交互式卡片（header 颜色按事件级别 + markdown 元素）；成功码 0；默认 60/分
- `PLANNED_FORMATS` 清空（下拉里不再有置灰项）
- **修一个泄漏**：`mask_url` 原来只打码 query 参数——**飞书的 token 在 URL 路径里**（`/hook/<token>`）
  → 接口回显会漏出去。现在同时处理路径 token（≥20 位随机串）与 Slack 的 `/services/T…/B…/X…` 三段。

## 验证（都跑过）
- **签名对拍官方示例**：钉钉逐字节一致（含 urlencode，`%2B` 级别）、飞书的 key/message 口径一致；
  时间戳钉住后比对，不靠"自己跟自己一致"
- 成功码按格式：wecom/dingtalk/feishu 的 0 与 bark 的 200 分别判成功，各自的错误码判失败
- 端到端 15 项：钉钉/飞书在假接收端上真发（URL 带签名、body 带 timestamp/sign、卡片是 markdown 元素、
  毫秒 vs 秒的时间戳），签名错时正确判失败（310000 / 19021），token 在回显里被打码
 2026-09-15 14:29:11 +08:00
butubb 24ea289c15 feat(通知): 加 Bark 格式 + 格式切换时界面提示全部跟着变 
## 用户报的第二件事：格式改了，提示没跟着改
弹窗里的 URL 示例/说明、密钥标签、限流说明都写死成企业微信了——选「通用 JSON」时
占位还是 `qyapi.weixin.qq.com`，限流还写着「企微硬限 20」。现在这些文案挂在**适配器**上
（`url_hint/url_help/secret_label/secret_help/limit_help`），由接口随格式下发，切格式即时更新；
限流值在用户没手动改过时也跟着格式的推荐值走（企微 20 / 通用 JSON 60 / Bark 60）。

## 新格式：Bark（iOS 推送）
- `POST {url}`，body `{title, body, markdown, group, level[, device_key]}`
  —— `markdown` 传富文本、`body` 传纯文本兜底（老版本 App 不认 markdown 字段时也能看清）
- URL 两种填法都支持：直接粘 Bark 复制的那串（`https://api.day.app/<key>`，key 在路径里），
  或填 `https://api.day.app/push` + 把 key 填到「设备 Key」（作为 device_key 发送）
- **成功判定按格式**：Bark 是 `code==200`（企业微信是 `errcode==0`）→ 新增
  `BaseAdapter.ok_codes`，`_post_once` 用它判定。少了这一步 Bark 的每次成功都会被误判成失败
- 正文按 2048 字节截断（走 APNs，体量有限）

## 顺带
- 通用 JSON 的 `secret` 现在会作为 `X-Webhook-Secret` 请求头发出（原先填了没用）
- `_formats()` 改为序列化适配器元信息，新增格式只改一处

## 验证
- 格式切换 14 项断言全绿：三种格式的 URL 示例/密钥标签/密钥说明/限流说明/模板区/限流默认值
  全部跟着切换；下拉里 Bark 出现在已实现区
- Bark 端到端 7 项：`code=200` 判成功、`code=400` 判失败（含重试）、请求体带
  device_key/title/body/markdown/group、URL 里的 key 在接口回显里被打码
- 文档：NOTIFY.md §5 的格式表补 Bark 列（URL 怎么填 / 成功码 / 约束），并说明
  "提示文案挂在适配器上，别写死在页面里"
 2026-09-15 14:05:33 +08:00
butubb 97cec6e211 feat(通知): 系统级 Webhook 通知子系统（事件目录 + 可插拔适配器 + 防刷屏） 
平台此前出了问题只能靠人盯页面。现在各组件统一走 `notifier.notify(事件, **字段)`，
推到企业微信 / 自建服务；**所有可通知点都登记进事件目录，默认全关，用户按 webhook 勾选**。

## 架构（`core/notifier.py` + `core/notify_events.py`）
业务线程调 `notify()` → 只做内存操作（读配置快照/匹配订阅/入队）→ 返回；
后台 1 个 dispatcher（聚合 + 每 hook 限流 + 折叠摘要）+ 3 个 sender（真实 HTTP、退避重试）
负责真正发出去。硬约束：**notify 零 DB、零 HTTP、零阻塞、异常不冒泡**——所以任务线程里
可以直接调（不用 app_context、不用 try/except），但**必须放在所有 `with self._lock` 之外**。

- **事件目录 36 条**（任务批次/单设备/设备/Worker/业务/安装/系统/AI），支持 `task.*` 通配订阅；
  语义分工避免重复告警：`worker.*` 是单次尝试级，`task.device.success/failed` 是唯一权威结论。
- **适配器可插拔**：`wecom`（markdown，按 4096 **字节**截断、超限不截半个汉字）+
  `json`（模板占位符，替换值按 JSON 转义，保存前干跑校验）；钉钉/飞书留了插槽（前端置灰）。
- **防打爆四层**：聚合窗口（默认 30s，同批次合并成一条并带样本）→ 令牌桶限流（默认 18/分，
  对齐企微硬限 20）→ 被限流的**折叠成摘要不丢弃** → 有界队列背压。取舍：失败通知最多延迟
  一个窗口，换来群不被刷屏。

## 安全与存储
- 配置只落 `app_meta.notify_webhooks` 一个键（**不建表** → 不涉及备份覆盖红线）。
- URL 本身就是凭据（企微 `?key=`）→ 接口回显/发送记录/日志一律 `mask_url()/scrub()`；
  编辑时留空即不修改；secret 永不回显。DATA_MODEL 的明文凭据告警补上了这一条。
- 发送记录：内存环形缓冲 200 条（重启清空）+ 独立 `logs/notify.log`。

## 接入点（每个都放在锁外、不改 return 顺序）
task_manager（批次开始/结束用新增的 `_BatchTracker` 统一在 finally 计数、单设备成功/失败/
离线/重试/停止/抢占/归还/cron 停止）、device_worker 心跳看门狗、generic 任务选择器连续失效、
apk 安装开始/完成、设备上下线（**状态沿检测**，只报新变化）、备份导出/恢复、经验巡检、
用户登录、服务启停。

## 前端
系统 Tab 新增「通知 / Webhook」子分栏：多条 webhook 列表（URL 打码）+ 编辑弹窗（格式/URL/
密钥/事件勾选树带 ★建议/聚合/限流/自定义模板/预览）+ 发送测试 + 发送记录。

## 自测
- 进程内逻辑 10 组断言全绿：聚合合并、限流+折叠、无配置/全局关静默丢弃、未知事件、
  内部异常不外泄、JSON 转义（标题含引号换行仍合法）、URL/异常消息脱敏、配置校验。
- 端到端（假 webhook 接收端）17 项断言全绿：真实事件投递（user.login / task.batch.no_device）、
  企微请求体形状、**HTTP 200 + errcode 93000 判为失败**、500 重试 3 次、记录里 URL 打码。
- 韧性：webhook 指向黑洞地址时登录耗时 100~114ms（基线 107~133ms，**异步隔离生效**）；
  配置写成坏 JSON 服务照常启动、通知静默不发、日志有 error（服务端实测后已复原）。
- 页面：系统 → 通知 面板/弹窗/36 个事件复选框/预览全部正常，无 JS 报错。
- 自测数据已清理（webhook、自建任务、写坏又复原的配置键）。

文档：新增 doc/NOTIFY.md（事件表/配置/格式约束/防刷屏/加事件三步骤/排障）并登记进 doc/README；
API.md §2.11；DATA_MODEL 的 app_meta 键表与明文凭据告警；ARCHITECTURE 线程表/分层/扩展点；
根 README 功能索引与日志表。
 2026-09-15 13:55:14 +08:00