測試版本
655-656

-  修復輔助功能焦點和文本問題
- 用受控多線程加載應用程式和模組
  (原本 fetchAppList() 會逐個 app 串行做兩件事：讀 label、解析 module metadata。現在改成用協程並行處理，每個 app 一個 async，但透過 Dispatchers.IO.limitedParallelism(...) 把並發數限制在 2..8 之間，避免一次把 PackageManager / ZipFile 掃描打滿。失敗時也保留 fallback，label 讀不到會退回 package name，不會整批中斷。)

657-664
下面用內建別看了，和你們沒啥關係

- 強化 PackageInfo 簽章替換與 seccomp 路徑偽裝，補齊 IPC 與 proc 視圖處理
- 對齊 FPA seccomp 並補強 Extreme proc 隱藏
- 強化 patch-loader 產物混淆並壓縮大小
- 改進簽名繞過處理
(透過使用最小的原生 APK 重定向路徑來偵測類似 360 的保護程序，並擴展 seccomp fd 路徑處理，從而提高對 360 加固的相容性)
- 為 Manager 添加簡單的簽名校驗

- 處理 maps inode 檢測 (重寫 /proc/self/maps 與 smaps 中的 APK 條目，讓其 device 與 inode 對齊原始 APK，避免 fstat 結果與 maps 條目比對失敗)
- 优化补丁安装文件读取逻辑与IO性能 (优先读取本地私有目录补丁文件，降级兜底SAF目录，修复文件长度读取错误，优化拷贝缓冲区大小提升安装稳定性与速度)

我參考了這個帖子的很多內容： https://bbs.kanxue.com/thread-285647.htm

抖音可用性收集
https://t.me/NPatch_HS/118947

又找到了幾處檢測點，晚上修

我一般用这四个测试效果，也给你们推荐

呃啊

小就一定好吗?
至少loli好

665-668

- 將衝突檢查延後到啟動初始化之後執行，確保啟動流程正確
- 修正 LSPlant 的 rwxp 記憶體權限洩漏所導致的環境異常問題
- 提升 seccomp 重導穩定性並更新 NPatch 的 LSPlant 相容性鉤子
- 加強 I/O 與路徑檢測繞過，補齊 APK 可見路徑與 fd 掛載資訊偽裝

更多說明：
這次更新主要針對的是目前 Android 生態圈中中高強度的加固方案（如 360 加固等）以及深度的環境檢測框架（如 Smallcheck）。這些檢測手段不再僅限於簡單的包名比對或 root 偵測，而是深入到 Linux 核心層與 ART 執行緒。

以下為具體「過掉」的檢測機制解析：

1. 提升 seccomp 重導穩定性並更新 LSPlant 相容性鉤子

這個部分的更新主要解決了主動探測防禦與 ART 執行緒逃逸的問題：

過掉「探測性崩潰（Crash-based Probing）檢測」：
- 檢測原理： 偵測會故意向 openat 等系統呼叫傳入「畸形的路徑」或「不可讀的記憶體指標」。如果你的 seccomp 攔截器（SIGSYS handler）直接去讀取（解引用）這些指標，就會觸發 Segmentation Fault，導致外掛進程崩潰，或者暴露出有工具在攔截 syscall 的事實。
- 繞過方式： 更新後，不再於 SIGSYS 中直接解引用指標，而是先讓核心去驗證該路徑是否合法並打開它，再透過 /proc/self/fd 解析回傳的 fd。這讓惡意探測無法引發攔截器崩潰，完美隱蔽了 seccomp 重導的存在。

過掉「ART 內聯優化逃逸（Inline / AOT Escape）檢測」：
- 檢測原理： 現代 Android (特別是 Android 8.0+) 的 ART 虛擬機會頻繁利用 ProfileSaver 進行 AOT (Ahead-of-Time) 編譯，並將部分頻繁呼叫的方法「內聯 (Inline)」。一旦目標方法被內聯，呼叫者會直接執行機器碼，不再經過方法的入口點，這會導致 LSPlant 等依賴入口點替換的 Java Hook 失效。防護系統會利用這一點，透過頻繁觸發特定邏輯並檢查執行時間或路徑，來判斷是否被 Hook。
- 繞過方式： 透過安裝 ProfileSaver 相容性鉤子並強制對 dex2oat 關閉 inline，確保目標方法永遠不會被編譯成無法攔截的內聯狀態。這保證了 Hook 的絕對覆蓋率，過掉了依賴內聯機制的完整性校驗。

2. 加強 I/O 與路徑檢測繞過，補齊 APK 可見路徑與 fd 掛載資訊偽裝

這部分是針對 VFS (虛擬檔案系統) 級別的深度稽查，特別是 Smallcheck 這類極度吹毛求疵的環境檢測工具：

過掉「Java 層 API 交叉比對檢測」：
- 檢測原理： 應用不僅會透過 Context.getPackageCodePath() 獲取 APK 路徑，還會深入反射讀取 LoadedApk、BoundApplication 內的 ApplicationInfo.sourceDir 等欄位，甚至透過 java.io.File API 進行交叉比對。如果重導邏輯只覆蓋了表層，底層欄位仍指向你 patch 過的私有目錄，就會被抓包。
- 繞過方式： 啟動後主動將這些深層框架變數恢復為原始 APK 的「可見路徑」，並偽裝 File API，讓所有 Java 層的路徑查詢都得到一致的假象。


過掉「底層 Metadata (中介資料) 檢測」：
- 檢測原理： 防護系統不呼叫 Java，直接透過 native 的 stat, lstat, statfs 或 statx 系統呼叫，去查驗 APK 檔案的「大小」、「Inode 節點」、「建立時間」或「磁區資訊」。如果讀取到的是補丁 APK 的資訊，大小和時間絕對與原始 APK 不符。
- 繞過方式： 將 native 檔案 hook 擴充到所有涉及 file stat 的 syscall，強制回傳原始 APK 的 Metadata，讓檔案屬性在檢測工具眼中完美無瑕。


過掉「掛載點特徵 (Mount ID / FD) 深度比對」：
- 檢測原理： 這是 Smallcheck 的拿手好戲。即使你完美偽裝了路徑與大小，檢測工具會去讀取 /proc/self/fd/ 下打開的檔案描述符，並進一步讀取 /proc/*/fdinfo/<fd> 裡面的 mnt_id (掛載點 ID)。如果你的補丁 APK 放在另一個分區（例如某個私有 data 目錄或 OverlayFS），它的 mnt_id 會與預期中 /data/app/ 目錄所在的 mnt_id 不同，重導行為直接曝光。
- 繞過方式： 系統動態追蹤被重導的 fd，並在檢測讀取 fdinfo 時，直接將裡面的 mnt_id 覆寫篡改為「可見路徑（原始 APK）」應該要有的 mnt_id。這直接在 VFS 層面阻斷了掛載點異常洩漏的問題。


過掉「虛擬檔案系統 (FUSE) 探測」：
- 檢測原理： 檢查 /dev/fuse 或相關掛載行為，來判斷系統是否運作在被魔改的模組環境（某些模組會利用 FUSE 來做檔案攔截）。
- 繞過方式： 直接對 /dev/fuse 的查詢回傳「不存在」，減少異常掛載點暴露的面積。

重點改動看下面的Commit，但功能我其實還沒做完，主要是修復了倉庫訪問不了的問題

https://t.me/ONPatch/178
https://t.me/NPatch_HS/119921
https://t.me/NPatch_HS/120290
https://t.me/NPatch_HS/120829

我下次發的版本會用fpa的分發倉庫，目前基本做完了，但我還有些設想比如說雙倉庫在嘗試，所以請甭急

引入了 FPA 同款在線倉庫，感謝 FunBox 提供的鏡像地址和實作參考
修復 split APK 相容性並優化 APKS 打包流程
將繞簽等級移出 config.json
完善倉庫頁 UI 與篩選流程
實作倉庫加載動畫與提示

修改了一些去簽相關，優化了在線倉庫相關，優化了一下UI問題，啟用了混淆字典

反正具體的你們也不看

测试版本
将模组作用域先储存在管理器的数据中 并在应用连接时进行同步 以避免作用域混乱或连线错误
支持自定义版本号（文本描述尚未更新）
调整了卡片 UI
优化了 Shizuku 服务连接
启用了混淆字典

改动不少，但下一个版本预期将修复和改动更多底层内容。虽然不涉及功能性改动，但为了确保全局稳定，还是先发布了这个版本以提供测试。

本地模式请先重新配置模组作用域

Just doing because I'm bored

api102?

预计包含大量 Bug，请谨慎测试。
这个版本是 NPatch 从 API 101 更新至 API 102 的测试版本。底层协议、储存层与通讯架构全面改写，影响层面遍及模组作用域、远端资料存取、修补程式启动流程与模组热重载。

- 正式引入 API 102 支援：实作 Running Targets 查询与 Module Hot Reload 完整流程，连接 libxposed 标准介面
- 统一 NPatch Remote 资料储存层：新增 NPatchRemoteStore 集中管理 Remote Preferences 与 Remote Files，去除 daemon 与 Manager 两条线路的语义差异
- Remote Service 全面可读写：API 101 和 API 102 的 Remote SharedPreferences 现在支援 Editor、commit、apply、clear 与即时回调，注入端 Binder 协议同步扩充
- 对外提供统一的 NPatch Remote API：新增 top.nkbe.npatch.remote Provider 与 NPatchRemoteClient，模组 UI 不依赖 libxposed 也能使用远端储存；Legacy XSharedPreferences 接入同一条 Binder 线路
- 废除 Dex 修改模式：移除了旧的 Dex 修改方案
- 修补程式自包含启动：loader dex 与 libnpatch.so 直接写入修补后的 APK，目标程式不再读取 Manager APK，避免跨应用存取与 SELinux 限制造成的启动失败
- 模组原生库快取隔离：新增 ModuleNativeCache，按模组包名与 APK 版本隔离快取；先写暂存再正式发布，避免中断留下不完整快取
- MetaLoader 容错恢复：启动失败时不再使整个 App 崩溃，改为记录诊断资讯并保留原程式元件建立流程
- 修复 Shizuku 安装稳定性：改用 ShizukuBinderWrapper 直接建立安装会话，避免 User Service 传递 PFD 的不稳定性
- 修复本地模式 MetaLoader dex 命名错误
- 提升最低 rolling version 至 705

版本更新后都要戳一下

改進 AppComponentFactory 的 class loader 回退與延後處理機制

移除針對每個 ClassLoader 的 factory 快取；改為嘗試使用多個 ClassLoader 載入。
當傳入的是過期的 ClassLoader 時，改由 ActivityThread 解析並取得實際有效的 ClassLoader。
在指定 Factory 之前，先驗證該 Factory 是否能成功載入；如果載入失敗，則保留原本的 Factory 名稱，而不是直接覆蓋。

fix(loader): 修复 AppComponentFactory 类加载递归与原生库路径丢失

- 为 runtime ClassLoader 解析增加重入保护
- 启动时优先返回包含宿主原生库路径的有效 ClassLoader
- 避免部分应用启动白屏及 System.loadLibrary 找不到宿主 so
- 仅在启用“豁免环境校验”时安装 shadow-fd I/O hooks