众所周知 核心破解(CorePatch) 的「禁用软件包管理器签名验证（Disable digest verify）」功能会导致 momo 检测到「包管理服务异常（Package manager service is abnormal）」。

该功能用于允许安装签名错误或未签名的包，而 momo 正是利用这一点进行检测。其通过 PackageInstaller API 提交一个未签名的 apk 文件，检测 EXTRA_STATUS 结果是否为 STATUS_PENDING_USER_ACTION ，如是则说明通过了签名验证（这种情况下通常需要启动一个 activity 让用户确认安装，但也可以 abandon 放弃安装），即 pm 异常。

正常来说，如果只是想覆盖安装签名不同的包，不需要开启此功能。

Demo

本频道已开放讨论区

关注 Mufanc 喵，关注 Mufanc 谢谢喵

发现 CFA （非 multiplatform）运行在后台的时候总是会每秒刷出这样的日志：
ActivityManager: Foreground service started from background can not have location/camera/microphone access: service com.github.kr328.clash/.service.TunService
一番调查发现问题来源于这里，是通知显示流量统计的功能，这个功能每秒更新一次通知，每次都通过前台服务调用 Service.startForeground 来更新通知，所以当应用在后台调用的时候系统就会出这个 log 。
缓解措施是关闭这个功能。
参考：如何更新前台服务通知

StethoX 1.0.2

- 虽然没人用但还是发个版，因为 1.0.1 过于敷衍了
- 支持启动时挂起进程
- 增加一些工具函数
- 修复 hook 的一系列 bug
- 增加 hook.getClassLoaders 获取 vm 中 ClassLoader 的列表

自用贴吧阅读器，感兴趣的可以在 actions 下载
如果在使用过程中遇到问题欢迎反馈
https://github.com/5ec1cff/RoTieba

最近的 DevTools 更新似乎给 Stetho 带来了严重的问题，前端会不停向后端请求设置断点，而后端并未实现，这样会带来严重的性能问题。

问题的原因尚不清楚，不过这也让我意识到依赖 Devtools 的问题，此前维护 StethoX 的时候，也遇到了前端反复发送大量无用请求的情况。Devtools 可以说是专门为 chrome 设计的，前端和后端存在一定的耦合，只靠实现 Devtools Protocol 很难让它正常工作。

于是决定转投 Flipper ，这是 Stetho 的替代品，同样是 facebook 出品。其支持在前端和后端开发插件，这比借用不可控的 Devtools 前端好多了。

同样尝试将 Flipper 集成到 Xposed 模块中。Flipper 同样只要给一个 context 就能正常工作，只是它依赖的 SoLoader 有些小问题，需要做一些 hack 。

比较麻烦的一点是 Flipper 的通信采用 tcp ，而不是 unix socket ，这样没有 internet 权限的 app 就没法用了。当然解决方法也是有的，只要拦截 Flipper 创建 socket 的过程，用模块 app 创建 socket fd 发送给它就可以了。

目前 Layout 模块能正常工作，期待能够用插件实现原来 StethoX 的功能。

https://github.com/5ec1cff/XFlipper

（图为被 Xposed 注入 Flipper 的 App 使用 Layout 功能的演示，App 并没有 Internet 权限）

可能对某些人有用的 userscript ：屏蔽 twitter 的点赞数、转发数、统计数

GM_addStyle([data-testid=like] [data-testid=app-text-transition-container],
[data-testid=retweet] [data-testid=app-text-transition-container],
a[href$="/analytics"] [data-testid=app-text-transition-container]
{ display: none !important; }
)

P.S. 点了赞的推文，赞数不会被屏蔽

P.S.2. 这条是昨天发的，今天就看到下面的新闻，马斯克你也在看频道吗😁

https://t.me/landiansub/6057

我以前用 chrome 的远程调试的时候，由于网络问题，无法访问 devtools 前端的在线页面，所以一直使用 inspect fallback ，也就是用 chrome bundled 的 devtools 前端。由于这个机制只对远程版本比本地版本高的启用，我还专门写了个 extension 强制开启这一机制。

而新版本 chrome 的 devtools frontend 遇到了在不支持 debugger 的情况下死循环设置断点的问题。这个 bug 已经在 8 月被修复了，然而最新的稳定版 chrome 的 bundled devtools 仍然没有包含这个提交。

研究了一下 CDP 的 http api ，发现目前返回的 webkit rev 过于老旧，正常情况下 devtools 都是根据这个参数在线请求 chrome-devtools-frontend.appspot.com 获得所需的 devtools 页面，所以对 stetho inspect 会得到一个非常旧的不能用的 frontend ，而我一直用 bundled ，因此没发现这个问题。

也就是说，我在 Stetho 的 README 里承诺的「打开 chrome://inspect 就能用」根本不符合事实，难怪没人用。

于是把 rev 换成和 kiwi browser devtools 后端返回的 rev 相同的值，这样就解决了死循环的 bug ，不过 devtools 是旧版的。

试了一下 chromium dev 频道（120），它的 bundled devtools 也修复了死循环的 bug 。顺便还发现这个版本获取 page 不用 /json 而用 /json/list 了，stetho 后端也要相应调整。

总之又给 Stetho 续命一段时间。我目前还是很依赖 StethoX 的 js 功能的，比起从零开始给 flipper 开发 js 控制台 plugin ，还是拿 StethoX 凑合用好。

Java 反射和代理使用中对异常处理不当导致的问题

Xposed 模块和其他注入系统的模块中常常用到反射和代理，但是很多开发者忽视了异常处理，这在严重的情况下会导致系统崩溃。

典型的例子是 ServiceManager Proxy 。很多系统模块选择代理 java 层的 IServiceManager ，拦截 addService 、getService 等方法以提供 binder 服务，自然要用到 Proxy 实现接口和 invoke 反射执行原方法，如 kr328 的 MagicLibrary （Clipboard Whitelist 、 IFW Enhance 等模块，Rikka 的 SR 也包含这一套代码）、 XServiceManager 。然而调用 invoke 的时候没有处理 InvocationTargetException [MagicLibrary, XServiceManager]，代码示例如下：

InvocationHandler handler = (proxy, method, args) -> {
  // .. injected logic ..
  return method.invoke(thiz, args);
}

因此如果执行的原方法发生了异常，这个异常就被包装成 InvocationTargetException 抛出。InvocationTargetException 又是个受检异常，会被 proxy 包装成 UndeclaredThrowableException 抛出。这样如果有代码调用 ServiceManager ，得到的异常和预期不一致，就导致了崩溃。

尽管这些代码已经使用多年，但是潜藏的问题直到 8 月底升级到 MIUI 14 ，很多用户反馈 SR 等模块出现了问题的时候才暴露。因为系统服务中调用 getService 被 SELinux 阻止，抛出 SecurityException 异常，也许系统代码已经捕获了 SecurityException ，但是由于 proxy 的存在，抛出的异常不是 SecurityException ，所以就变成了未捕获异常，进程崩溃。

因此，使用代理、hook 等手段修改了方法执行逻辑后，如果需要执行原方法，为了确保抛出的异常一致，正确的做法示例：

try {
  return method.invoke(thiz, args);
} catch (InvocationTargetException ex) {
  throw ex.getTargetException();
}

其实这些在两个月前就应该发了。 SR 和 MagicLibrary 模块在被汇报了上述问题后已经及时修复（SR 增强模块 v29.0.1+ , MagicLibrary ），不过我今天又看到有用户反馈同样的问题，发现该用户没有升级 SR ，且其使用的 Xposed 模块包含 XServiceManager ，其中代码仍然存在上述问题。

ZygiskOnKernelSU 用户如果遇到应用随机崩溃的现象，可以用下面的 v4-0.7.1-95-ba513a9 版本。

大概是原来使用的 riru 式自卸载方式导致的概率性崩溃，现在改用西大师的魔法，应该不会有问题了。

加回 32 位支持的 ptrace zygisk ，有没有勇士愿意试试？
正式版 Zygisk Next 已加回 32 位支持

图1

图2

图3

Android 的组件 EditText 有两个有用的特性：拖拽选择（图1）和拖拽移动光标（图2）。前者应该历史悠久，后者则是 Android 11 引入的（可能的提交）。这两个特性极大地便利了触摸屏上的文本编辑。

不幸的是，微信的定制消息输入框不具有这两个特性（图3，微信 8.0.42）。

P.S. TG 的动图没法集合在同一条消息，只能这样发了