测试基于 ptrace init 的 ZygiskNext ，最低 Android 版本需求是 8.0 ，Magisk / KernelSU 版本要求不变
模块页面看不到 ZygiskNext is Loaded 等状态提示是正常现象，因为没做，请自行检查 Zygisk 模块是否正常工作。

systemless hosts 模块用户可以看看是否还存在冲突

fd6a454 修复了低版本 Android 的兼容问题

https://github.com/5ec1cff/ZygiskNext/actions/runs/6852625402
增加注入重试次数，缓解个别系统第一次启动 zygote 可能失败的问题

偶然看到 magisk delta 的一张截图。在此声明：本人从未参与过 Magisk Delta 的开发，从未主动向该项目贡献过代码，也从未使用过该项目，只是曾经的 maru 代码被作者 HuskyDG 擅自合并，这可能是我出现在该列表中的原因。

传一下，以防有人不知道「最新」是什么
P.S. 仅指本频道的「最新」，本频道发布的都是测试版，不是正式版

频道最近发的几个 Zygisk Next 都没有在模块信息显示运行状态，因为重构的时候删掉了。我目前不打算加回来，因为这个功能本身实现就不正确，模块信息显示运行不一定代表模块实际在运行，

同理，Magisk 的 Zygisk Next 用户也不要因为在 Magisk 管理界面发现 zygisk 模块显示未加载就大惊小怪，那是因为关闭了 magisk 的 zygisk ，所以 magisk 不会加载它们，但 Zygisk Next 会加载它们。

判断 Zygisk Next 是否工作正常的最好方法是看 zygisk 模块（如 LSPosed / Shamiko）工作是否正常。

PlayIntegrityFix 用户如升级到 13.5 遇到 zygisk 无法使用的问题，可尝试升级 13.6 13.7 : https://github.com/chiteroman/PlayIntegrityFix/releases/tag/v13.7
该模块的 zygisk companion 会 abort ，本来这个进程应当自动重启，然而 ZygiskNext release 的 111 版本未正确实现该机制，导致 zygisk 不可用且必须重启系统恢复。不过正常来说 companion 不应该崩溃，所以这是模块问题，应该让模块作者修复。

随机化临时路径

(1/2)
前段时间才把 HMA 从 2.2.4 升级到 3.2 ，并因此发现它有很大的性能问题。
使用 ApplistDetector 1.3.2 的时候，发现在 pm getPackagesHoldingPermissions 卡了很长时间（十几秒）。由于最新版本 2.4 早已移除了该检测项目，因此新版用户无法感知。
1.3.2 的 getPackagesHoldingPermissions 检测调用了 PackageManager.getPackagesHoldingPermission 获取程序包列表，该 API 接收一个 permission 列表，返回所有具有该列表中任一权限的包。该实现直接收集了所有的 android.Manifest.permission 中的权限并提交给 PMS 查询。
HMA 3.2 通过 hook AppsFilter.shouldFilterApplication 实现过滤，这个方法原本是用于系统内部包可见性的逻辑。这个方法相比旧版的拦截 PMS api 再进行过滤的方法，确实易于实现，且影响范围广，但是没有考虑到该方法被频繁调用的问题。
回到 getPackagesHoldingPermission ，这个方法内部实现是遍历系统中所有的 package ，检查该包是否具有传入的权限列表中的权限，检查需要调用 checkPermission ，这是以查询者 app 的身份进行调用的，因此会受到包可见性影响，需要调用 shouldFilterApplication 进行过滤，这就是说该方法会被调用 N×M 次，其中 N 是系统中包的个数，M 是传入权限的个数。一般 N 和 M 为几百，所以检测器调用一次，该方法就会被调用数万次。更严重的是在 A11 （笔者的主力机的系统）上，这个方法持有 PMS 的 lock ，因此在这十几秒的卡顿期间 systemui 都无法正常使用。更高版本的 Android PMS 采用了 snapshot 机制，可以缓解这种问题，但查询仍然缓慢。
经过实验，发现如果没有 HMA hook ，系统还是能够很快地处理如此大的请求，因此可以认为是 HMA 的性能问题。

(2/2)
一开始怀疑是 Xposed hook 导致的性能损耗，比如分发回调、反射调用原方法等。而在 HMA 中停止服务，调用了 unhook 之后也仍然存在较大的卡顿，这是因为 LSPosed 的 unhook 并不会在底层调用 LSPlant 的 unhook ，也就是说仍然存在反射调用，因此 hook 确实带来了性能损耗。
于是我用继承的方式重写系统的 AppsFilter 实现 hook ，这样在 HMA 中被 disable 或者处于 blacklist 模式的 caller app 已经不会因为调用 getPackagesHoldingPermissions 而卡顿了，这样解决了 xposed hook 的性能问题。但是开启 whitelist 的 caller 仍然存在卡顿。
仔细调查后发现罪魁祸首是 HMA 的 log （如图）。过滤成功的时候会写一条 debug log ，本来没打开 debugging log 开关是不会输出的，但是 HMA 判断是否要输出之先进行了一个 parse 操作，而恰好这个 parse 很慢，导致如果过滤成功次数较多（也就是 whitelist）的时候很卡顿。解决方法也很简单，把 parse 放到判断是否需要 log 后面就能减少卡顿。

我的手机两年前上 Android 11 之后开机在第一屏一直都耗时很长，直到昨天才在 ksu 群的讨论中知道原因。

init 在 post-fs-data 的时候会执行一个 restorecon ，这会重置 /data 子目录下的所有文件的 selinux label 。这是一个很耗时的过程，正常来说只会在系统更新的时候执行，如果执行成功就会记录一个和当前系统相关的 hash （根据 plat_file_contexts 计算出来，持久化存储在 xattr security.sehash ），下次启动检查 hash ，如果和系统的匹配就不需要再重置了。但是某些设计不良的系统 MIUI 会因为某种原因导致这个过程失败（比如 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 就能成功跳过，终于不会再卡第一屏了。

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 寻找开机慢的原因。

141-a88d7a5
- 确保 zygote 重启时 zygisk companion 重启（与 Magisk 行为一致）。
- 恢复旧版的 companion 行为，现在每个模块的 companion 运行在独立的进程中。
- 随机化 init_control 名字（现在可以通过 /data/adb/modules/zygisksu/bin/zygisk-ctl 控制 init monitor）。
- 缩减 debug 构建的体积。
- 分离 zygiskd 的 debug symbol （可以在 CI 下载）。
- Rust 部分代码在崩溃时使用系统 abort 以便堆栈回溯

兼容性说明：本模块依靠向 init 进程附加调试器(ptrace)工作。理论上，只要您的 Magisk / KernelSU 正确支持 post-fs-data.sh 和 service.sh 脚本执行，且 init 进程不存在其他 tracer ，且内核允许 ptrace init ，即可正常使用。
需要的 KernelSU 版本：10940+ kernel, 10942+ ksud
需要的 Magisk 版本：26300+ ，关闭内置 zygisk
需要的 Android 版本（理论上）：8.0+ (API 26+)

P.S. 据说 huawei 设备不允许 ptrace init ，不知道有没有相关用户汇报？

由于内部原因，该频道已完成历史使命，我们下个版本再见～

Zygisk Next CI 发布频道： @zygisk_next_ci
考虑到 github actions 的 Artifacts 会过期，所以 CI 构建同时自动上传到该频道。CI 构建会在每次推送代码的时候进行，可能不稳定，但代表最新版。

事实上本频道发布的版本也是来自 CI ，此后如无重大行为变更不会发布到频道。

debug 构建包含更多信息输出，所以反馈问题时必须安装最新的 debug 构建，确认能够复现再进行反馈（除非是 release 特有的问题），反馈时也请给出完整的版本号。release 构建经过优化，日常使用请安装 release 。

本频道讨论区接受 Zygisk Next 的问题反馈。如果您是以讨论 Zygisk Next 为目的在频道讨论区发言，请仔细阅读 CI 频道内置顶，尤其注意以下两条：

- 关于 symbols ： 包含 SYMBOLS- 前缀的文件是调试符号，并非模块，不可安装，仅归档于频道用作开发者查错。

- 关于隐藏： 这不是一个「隐藏模块」，也不具有任何特别的隐藏效果。任何有关隐藏的问题请勿在讨论区询问，否则会被禁言或封禁。