用 Root 做可回滚自动化：充电上限与温度急停

Root 自动化最危险的不是脚本写错一行，而是错误会在无人看守时反复执行。充电控制又直接碰到 OEM 内核驱动与电源管理芯片，机型差异很大。本篇优先推荐系统自带充电保护；确实没有时，才用 ACC 的容量上限做一次白天、有人值守的 80% 暂停/70% 恢复实验，并用 Tasker 或 MacroDroid 做独立高温告警。

你会完成什么#

• 判断是否应该直接使用 OEM 原生充电上限。
• 安装并盘点 ACC，不手工猜测 /sys 充电开关。
• 只设置 pause_capacity=80 与 resume_capacity=70。
• 建立不依赖 ACC 的 42°C 告警和人工拔线急停。
• 观察一次暂停/恢复边界，再恢复默认、停守护进程或卸载。

先看结论#

心智模型#

OEM 原生上限？──是→ 使用原生功能并结束
       │否
       ↓
ACC 守护进程：仅 70% ↔ 80% 容量窗口
       │                   ↑
       ├─ acc -i / 日志观察 │
       └─ OEM 充电开关适配 ┘
                 +
独立温度告警（Tasker/MacroDroid，≥42°C）
       ↓
人工拔线 → acc -e → 停 daemon → 默认配置/卸载

ACC 不是“电池保养魔法”，而是根据配置调用内核暴露的充电控制接口。不同机型的开关语义可能相反或无法可靠恢复，所以不能照搬别人的 sysfs 路径。独立温度告警不负责改内核；它只确保当 ACC、充电器或环境异常时，人能及时拔线并执行救援。

工具清单#

项目全景：自动化与调优的 19 个项目，一个不漏#

以“让设备自动完成一个可验证任务”为主题，按 AI Agent、无障碍/测试框架、ADB 设备控制、性能调优和安全分析组织项目，并把农业公司 Root AI 等词义误收条目公开纠正。

1. AI Agent 与 MCP 设备控制 · 4#

用 Autonion、NeuralBridge、agentic-nexus 和视觉模型 Agent 展示从意图到动作的链路，要求屏幕预览、危险动作确认、权限最小化和本地日志清理。

本组共 4 项：4 个源项目、0 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

2. 手势录制、宏与测试框架 · 6#

把 MacroDroid、Auto.js 打卡脚本、uiautomator 多后端、getevent 回放和 Appium 页面对象模型放进从录制到断言的流程；账号自动操作需遵守平台规则。

本组共 6 项：6 个源项目、0 个 Fork，其中 1 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

3. ADB、远程设备与显示控制 · 3#

覆盖云端模拟器、DisplayToggle、无线 ADB 自启和基于 ADB 的自动化，说明配对、端口、网络暴露、撤销授权和设备离线恢复。

本组共 3 项：3 个源项目、0 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

4. Root/Shizuku 性能与内核调优 · 2#

用内核管理器和 ReAppzuku 一类项目展示“测量—修改—复测—恢复”，不把杀后台或内核预设宣传成无条件省电提速。

本组共 2 项：1 个源项目、1 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

5. 安全分析自动化及其边界 · 2#

SSL pinning 与攻击链关联项目只放在自有应用或企业 SOC 场景，说明它们与日常 Android 自动化的差异，并给出迁往 reverse_hook/DevSecOps 的建议。

本组共 2 项：2 个源项目、0 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

6. 专项工具与同名误收条目 · 2#

逐项覆盖剩余项目；Root AI 农业机器人公司等非 Android 条目只作一句辨析并建议迁类，描述不足的工具明确标记“未验证”，不补写不存在的能力。

本组共 2 项：2 个源项目、0 个 Fork，其中 0 项已归档。它们的平台、用途或分类存在边界，只作逐项核验，不当作默认安装候选。

开始前#

先在系统“电池”里寻找充电上限、保护电池或自适应充电。若能满足需求，直接用它。本篇只适合状态稳定的备用/可恢复设备：电池不鼓包、充电口正常、Root 可撤销、能进入 Root 终端，且电量在 40%–75% 之间。准备原装/可信充电器、计时器与一条书面救援卡。

救援卡写明并提前理解：acc -i 查看状态；acc -e 尝试恢复充电；acc -D stop 停止守护进程；acc -s r 恢复默认配置；acc -U 完全卸载。确认 Root 管理器也能禁用 ACC 模块。实验全程有人看守，不放在床上/车内/阳光下，不进行游戏、导航或相机压力负载。

操作步骤#

1. 保存原生基线与救援路径#

卸载/关闭其他充电控制模块、内核管理器配置和自动化，避免多方写同一开关。记录 Android/build、内核、Root 方案、ACC 版本、当前百分比、温度、充电器，以及系统原生保护功能状态。插电观察五分钟，确认未装 ACC 的基线能稳定充电，再拔线。

在 Root 终端依次测试能否打开 su 会话、能否退出，以及 Root 管理器的模块禁用入口。不要先执行任何 /sys 写入。救援卡放在另一台设备或纸上，避免手机界面故障时无法查看。

2. 安装 ACC 并只读盘点#

仅从 VR-25/acc 上游发行页获取稳定包，按你的 Root 管理器官方模块流程安装。安装后先运行 acc -D、acc -i 和 acc -s p，保存守护进程、充电信息与当前配置；如果命令不存在、日志报错或机型开关检测异常，卸载并结束。

运行 acc 交互向导时保持不了解的选项为默认。不要选择自定义 charging_switch，不设置电压、电流、温度、强制快充、开机脚本或定时任务。

3. 设置 80/70 容量窗口#

运行 acc 80 70；ACC 官方快捷方式的顺序是“暂停容量、恢复容量”。再用 acc -s p 查看并确认 pause_capacity=80、resume_capacity=70，其他参数仍为默认。若输出不是这两个值，不重复乱输，运行 acc -s r 恢复默认并查看官方帮助。

此时不要叠加 Tasker Root shell 控制。容量策略由 ACC 守护进程独立负责，自动化工具只做告警，减少两个调度器互相打架。

4. 建立独立温度告警#

在 Tasker 或 MacroDroid 新建一个配置：触发条件为“电源已连接”且“电池温度≥42°C”；动作为高优先级通知、声音/振动，并显示“立即拔线，运行 acc -i，必要时 acc -e 与 acc -D stop”。再建一个低于 40°C 的恢复提示即可，不执行任何 Root shell。

用工具的“测试动作”验证通知和声音可见，不要通过加热手机来触发。确认自动化有总开关，并把它加入救援卡。若系统不向工具提供可靠温度变量，就放弃自动告警，改用实验期间每五分钟人工查看。

5. 观察一周期并演练回滚#

白天将设备置于不燃、通风表面插电，每五至十分钟记录系统百分比/温度与 acc -i。接近 80% 时应转为未充电/空闲，百分比不再持续上升；拔线正常使用至接近 70%，再次插电应恢复充电。这个自然周期可能超过标注的主动操作时间，不可用高负载加速放电。

验证后先运行 acc -s r 恢复默认。如果不再使用，运行 acc -D stop，再运行 acc -U，按 Root 管理器提示完成移除并重启。插电观察十分钟，确认系统恢复原生充电行为；关闭/删除温度告警并记录最终状态。

验证#

排错#

完成清单#

• □我先检查并优先考虑 OEM 原生充电保护。
• □我保存了基线、ACC 状态和离线救援卡。
• □我只设置 80/70，没有改电压、电流、温控、switch 或 sysfs。
• □我建立并测试了独立 42°C 告警，且没有用加热触发。
• □我在白天有人看守时验证暂停与恢复，没有高负载加速。
• □我演练了默认配置、停服/卸载，并确认原生充电恢复。

一手资料#

• ACC 上游仓库与完整手册
• Tasker Run Shell 官方帮助
• MacroDroid Shell Script 动作说明
• Zuan Kernel Manager 上游仓库
• DisplayToggle 上游仓库