星霜日记
网页版:https://tg.xingshuang.xyz/
# Windows 磁盘清理 Skill

弄了一个清理硬盘的 Skill,和 Wiztree、Everything 一样用 NTFS/ReFS 自带的索引快速扫描,并且删除文件都只是标记,都要用户二次确认,会比较安全..大概

欢迎品尝(

https://github.com/std-microblock/windows-disk-cleaner-skill
#shell #adb #monkey
关键代码(从设备 /system/framework/monkey.jar 反编译)

1. 每次 monkey 运行结束必发旋转事件(Monkey.java 的 run 流程,正常结束和异常退出两个分支都有):
int crashedAtCycle = runMonkeyCycles();
new MonkeyRotationEvent(0, false).injectEvent(this.mWm, this.mAm, this.mVerbose);  // 正常结束
...
} catch (Throwable th) {
    new MonkeyRotationEvent(0, false).injectEvent(this.mWm, this.mAm, this.mVerbose);  // 异常退出
    throw th;
}

2. 这个事件就是"冻结→解冻"(MonkeyRotationEvent.java):
iwm.freezeRotation(0, "MonkeyRotationEven#injectEvent");   // 强制冻结到0度
if (!this.mPersist) { iwm.thawRotation("MonkeyRotationEven#injectEvent");    // 解冻 = 释放方向锁
}

3. --pct-rotation 隐藏选项确实存在
(processOptions 里 mFactors[4])——但即使比例为 0,上面这段也会无条件执行

*总结*
freezeRotation(0)+thawRotation 由 system_server 的 DisplayRotation 落地 → 对 accelerometer_rotation 连写 2 次→ 解冻=恢复自,方向锁定被清成 ar。与启动哪个 App(UNSPECIFIED、PORTRAIT等)、什么启动方式都是 monkey 自己的收尾动作
详细操作步骤
步骤 1:设置 Worker 回源域名(Fallback Origin)
按照【方案一】的步骤,先给你的 TGProxy Worker 绑定一个自定义域,例如 worker-tg.domain-a.com。
访问 https://worker-tg.domain-a.com/health,确认返回 {"ok":true}。
步骤 2:开通 Cloudflare for SaaS 并设置回源
在 Cloudflare 控制台打开主域名 domain-a.com。
在左侧菜单点击 SSL/TLS -> Custom Hostnames (自定义主机名)。
首次进入点击开通 Cloudflare for SaaS。
在页面下方的 Fallback Origin (回源来源) 输入框中,填入第一步绑定的域名:worker-tg.domain-a.com,点击 Add Fallback Origin。
等待 Fallback Origin 状态变为绿色的 Active。
步骤 3:添加自定义主机名(优选域名)
在同一页面点击 Add Custom Hostname。
Custom Hostname:输入客户端实际访问的域名,例如 tg.myproxy.com。
TLS 设置:
Minimum TLS Version: TLS 1.2
Certificate authority: 选择 Let's Encrypt 或 Google Trust Services
Certificate validation method: 选择 TXT Validation
点击添加。
步骤 4:在第三方 DNS 完成所有权与证书验证
添加完成后,点击展开该主机名,会看到两条需要添加的 TXT 记录:
Hostname Ownership Validation(主机名所有权):
类型:TXT
主机记录:_cf-custom-hostname.tg
记录值:复制 Cloudflare 提供的校验字符
Certificate Validation(SSL 证书申请):
类型:TXT
主机记录:_acme-challenge.tg
记录值:复制 Cloudflare 提供的校验字符
前往你管理 myproxy.com 的 DNS 解析平台(如 DNSPod),添加这两条 TXT 记录。等待 2~5 分钟后回到 Cloudflare 刷新,直到 Certificate status 和 Hostname status 全部变成 Active。
步骤 5:配置优选 IP 解析
当证书状态为 Active 后,即可在第三方 DNS 将该域名解析到测出的优质 Anycast IP:
本地使用测速工具(例如 CloudflareSpeedTest)测出当前宽带网络下延迟低、丢包为 0 的 Cloudflare IP 段。
在 DNS 控制台中,为 tg.myproxy.com 添加 A 记录,指向测出的优质 IP:
可以设置分线路解析:移动线路指向香港/日本优选 IP,电信/联通指向美西圣何塞优选 IP。
(也可以直接 CNAME 指向维护良好的公共优选 CNAME 地址)。
关键步骤:重新计算 Bridge URL 并配置 Telegram
在 CF-Workers-TGProxy 中,访问代理页面的鉴权参数 ?bridge=<token> 依赖了访问时的完整域名。如果更换了域名,之前的 bridge 参数会直接失效导致 404。
1. 本地生成新的 Bridge 链接
确保本地已安装 Node.js,打开终端执行以下命令(替换其中的 SECRET 和 DOMAIN 为你自己的配置):
bash
node -e '
const crypto = require("crypto");
// 填写你在 Worker 环境变量配置的 SECRET
const secret = "你的SECRET_32位或34位hex";
// 填写你最终给客户端使用的域名(方案一的域名或方案二的优选域名)
const domain = "tg.myproxy.com";
const hexKey = secret.length === 34 && secret.startsWith("dd") ? secret : secret.slice(-32);
const key = Buffer.from(hexKey, "hex");
const hmac = crypto.createHmac("sha256", key);
hmac.update("tdesktop-web-proxy-bridge-v1\n" + domain.trim().toLowerCase());
const bridgeToken = hmac.digest("base64").replaceAll("+", "-").replaceAll("/", "_").replace(/=+$/, "");
console.log("\n================ 专属代理地址 ================");
console.log(`https://${domain}/?bridge=${bridgeToken}`);
console.log("==============================================\n");
'

2. 在 Telegram 客户端配置
Telegram Desktop:
启动参数测试:在终端或快捷方式属性中添加启动参数:
text
Telegram.exe --web-proxy="https://tg.myproxy.com/?bridge=<计算出来的token>"

或者进入 Telegram 设置:Settings -> Advanced -> Connection type -> 启用 Web Proxy / tproxy 并粘贴上述完整 URL。
Android / Webview:
在支持应用内 Web Proxy 协议的客户端中,填入上述生成的完整链接即可。
常见问题与排查清单
访问 URL 显示空白或 404:
检查 bridge 参数是否是用当前访问的精确域名(小写,不带端口)生成的。
检查 SECRET 是否与 Worker 环境变量中的配置严格一致。
连接出现 1034 错误 (Edge IP Restricted):
该错误表示域名直接解析到了 Cloudflare IP,但 Cloudflare 边缘没有该域名的路由信息。请确认 Cloudflare for SaaS 中的 Custom Hostname 是否已是 Active 状态。
SSL 证书错误:
检查 SaaS 控制台中的证书验证状态,必须等待两条 TXT 记录生效并通过 DCV 证书签发后再切优选 IP 解析。 GitHub - XIU2/CloudflareSpeedTest: 🌩「自选优选 IP」测试 Cloudflare CDN 延迟和速度,获取最快 IP !当然也支持其他 CDN / 多个解析 IP 的网站 ~
Sonar: 基于 SwiftUI 的原生 iOS 与 macOS 音乐播放器

• 聚合网易云与 QQ 音乐搜索,支持歌曲、歌手与歌单分类检索

• 提供同步歌词、逐字高亮、本地歌单及 JSON 导入导出

• macOS 集成菜单栏与刘海屏播放器,支持播放队列、多种循环模式和收藏同步

https://github.com/can4hou6joeng4/Sonar

🧐 合集 💬 群组 😄 恰饭 🥰联系推广

🥰#音乐播放器 #SwiftUI #iOS #macOS #GitHub
🎉 CF-Workers-TGProxy · 重大发布 🆕

AK大佬 又一力作,可以部署在Cloudflare Workers的最新TG-WebProxy代理(桌面端、安卓端已支持,IOS还在测试版)。

━━━━━━━━━━━━━━

🥇 零服务器 · 一个 Worker 搞定
🥈 Telegram 无需外挂代理,直连般的体验
🥉 免费套餐也能打 · 大文件不断流

━━━━━━━━━━━━━━

⚙️ 部署仅需三步

新建 Worker → 粘贴 telegram_webproxy.js → 绑定 SECRET 与 BOOT 变量后部署上线
- SECRET: 32位小写字母和数字组成,推荐使用 openssl rand -hex 16 生成,
- BOOT: 建议 ≥ 16 位的随机字符串,推荐使用 openssl rand -hex 24 生成;
- 缺任一个 /health 直接返回 500。

📈 接入建议:配自有域名 CNAME,或走 Cloudflare SaaS 自定义主机名优选,线路会更稳。

━━━━━━━━━━━━━━

🐱 项目地址(去给大佬点个Star)
https://github.com/ToiCF/CF-Workers-TGProxy

✏️ Demo(由AK大佬提供)
https://t.me/webproxy?server=luckys.ekt.me&secret=5fe9173aea5203e80435f4a8fe138a59

#Telegram #Cloudflare #Workers #TGProxy #代理 #免费
#碎碎念
“先王昔年见过墨拓国人行事,自认北狄子民眼界狭隘、心智愚钝,认定这些墨拓人身怀异智、见识高远,远胜本国之人。”
“因此特意颁下王令,但凡墨拓国人定居北狄,尽数享受超然待遇。免赋税、免徭役,官府不得责罚,百姓不得欺凌,各城必须好生供养、礼遇尊待。”
“经年累月下来,墨拓国人在北狄地位越来越高,横行郡县,鱼肉百姓,无人敢管,俨然成了凌驾所有子民之上的特殊贵籍。”
P.S. 上面的 setfattr/getfattr 我用的是 termux 的,如果你没有 termux ,可以试试系统的 toybox setfattr/getfattr ,但是可能不好用

P.S.2 BUSYBOX 指你的 magisk busybox 路径,magisk 是 /data/adb/magisk/busybox , KernelSU 是 /data/adb/ksu/bin/busybox (ksu 的 busybox 来自于 magisk)。使用 magisk busybox 的原因是它的 unshare 会同时 make rprivate ,而系统的可能不会。

P.S.3 如果你正确执行了上述命令仍然无法解决开机慢的问题,说明不是 restorecon 导致的,建议分析开机的 dmesg 寻找开机慢的原因。
我的手机两年前上 Android 11 之后开机在第一屏一直都耗时很长,直到昨天才在 ksu 群的讨论中知道原因。

init 在 post-fs-data 的时候会执行一个 restorecon ,这会重置 /data 子目录下的所有文件的 selinux label 。这是一个很耗时的过程,正常来说只会在系统更新的时候执行,如果执行成功就会记录一个和当前系统相关的 hash (根据 plat_file_contexts 计算出来,持久化存储在 xattr security.sehash ),下次启动检查 hash ,如果和系统的匹配就不需要再重置了。但是某些设计不良的系统 会因为某种原因导致这个过程失败(比如 selinux 规则不正确,某些文件无法被 init restorecon ),导致 hash 不会被记录。从而每一次重启都要执行完整的 restorecon ,因此开机经常要在第一屏卡上 1~2 分钟(具体时长取决于你手机中非 ce 存储的文件的数目)。([1] [2])

由于这条命令在 post-fs-data 阶段的早期执行,先于 adbd 启动,更没有进入开机动画(第二屏),所以卡在第一屏的这段时间完全没法进入系统查看情况,很容易让心急的人以为手机莫名其妙成砖了。

解决方法自然是让这个过程顺利完成,前人已经给出了方法([1] [2]),也就是自己用 root shell 跑一遍成功的 restorecon .

/system/bin/restorecon -Rv /data

注意:Magisk 用户请勿直接执行上面的命令,最好在执行之前给 /data/adb/modules 盖一层 tmpfs ,否则会导致模块异常。

但是这样太浪费时间,还容易意外修改本来不该修改的 con ,因此我想了个捷径(以下为伪代码,请结合实际情况使用):

# 在私有隔离 ns 中操作
BUSYBOX unshare -m sh
# 制造一个假的空 /data 目录
# 不用 tmpfs 是因为 restorecon 会跳过 tmpfs
mkdir /data/tmp
mount --bind /data/tmp /data
# 因为 /data 没有文件,restorecon 只会修改目录自身的 label 并记录 hash
restorecon -Rv /data
# 从假 /data 获取当前系统下 /data 的 sehash
getfattr -n security.sehash /data
<HASH>
# 把真正的 /data 目录的 sehash 修改为上面得到的 hash
umount /data
setfattr -n security.sehash -v '<HASH>' /data


这样操作之后 /data 的 sehash 直接被重置为和当前系统一致的 hash ,开机启动的 restorecon 就能成功跳过,终于不会再卡第一屏了。
#碎碎念
刘备找了三个人,登基称帝,唐僧找了三个人,取了真经,我也找了三个人,赢了我五百多。
Back to Top