Refactor framework daemon to Kotlin - #597
Conversation
|
@AllenChangMusic @jiggs82 please test the lates CI of current branch to see if the support of Android 17 beta 3 is complete now. |
Vector release build still isn't working for me, on lsposed manager says it's not installed |
|
@jiggs82 Please provide logs by uploading the folder |
|
@jiggs82 It seems that Vector CI build is not flashed correctly. |
|
@JingMatrix debug build works, but release build does not Also... Looks like Vector has issues enabling new modules. And if you uninstall it, and reinstall, you aren't able to enable any modules. May be related to the report in the other thread where it isn't able to create the lspd folder |
Still same issues and yes now I encounter that :( |
|
There are bugs in the refactoring, hence I create pr #603 to fix the issue for the java code before refactoring, to help isolated issues. |
|
When I use the release build, it crashes, but the debug build works fine. |
3611782 to
0da27d9
Compare
|
@jiggs82 @AllenChangMusic @mmmpipi Please also test the latest CI builds of current branch, before I finally merge it. |
Tested and one module - InstaEclipse doesn't work in this version, but did in the previous CI. One thing to note is in LSPosed manager, it keeps complaining there's an update, but it's the old pre-vector version |
|
@AllenChangMusic Please upload your debug version logs for the module not working. |
|
@JingMatrix I'm not seeing any specific crash log, but this CI causes IG to crash |
|
@AllenChangMusic I see logs of containing |
Instagram app just crashes, won't even open. Compared to the previous CI, it opens fine, and you can open the InstaEclipse settings (long holding the search icon in the instagram app), and use the app just fine |
Flashed latest build and all good here 👍🏻 |
|
@JingMatrix anything you need me to debug or send logs for to help troubleshoot why it's causing crashing? |
|
@AllenChangMusic I think it is a problem of the module. |
Hi, I am the dev of InstaEclipse, this issue was fixed with InstaEclipse 0.5 debug, the user is using it. I will check myself... Thanks for the great LSPosed/LSPatch!! |
|
@ReSo7200 Nice to hear from you, and it is my pleasure to serve the community. Please do tell me if current refactoring (this pr) is causing issues for your module. I will wait for your test result before merging this. |
|
@ReSo7200 Looking through logcat, seeing these 3 errors consistently popping up, not sure if it's related to the hooking.
|
it works fine! thanks |
|
@bikram-agarwal Please if the latest CI build from current pr works for you. |
No, modules tab is again blank when I flash this. |
CorePath check both of them before injecting. Moreover, we fix a compilation waring of null string.
|
@Dev4Mod and @huynhbaman, thank you for finding out this bug, it is fixed now. |
|
@huynhbaman LGTM Both legacy and 101's modules are working Here are some logs if needed |
|
hi @JingMatrix |
Modules such as `io.github.mhmrdd.libxposed.ps.passit` [PlayStrong](https://t.me/meetstrong/125) call methods with `libxposed` API signatures via JNI during its initialization, which is bounded to fail if dex obfuscation is always enabled. Vector has removed the user configuration of `Xposed API Protection` (toggling the dex obfuscation option) during its daemon refactoring in #597, for the reason that this option is too technical for most users. Ideally, module developers should extend their module compatibility with dex obfuscation mode, by for example, inheriting Xposed APIs. In any case, we now disable dex obfuscation for debug builds, so that Vector users could test out these modules. P.S.: strong integrity is obtained on my local test with community shared RKA token.
During the previous refactor #597, we forget to implement the `auto_include` feature.
During the previous refactor #597, we forget to implement the `auto_include` feature.
Modules such as `io.github.mhmrdd.libxposed.ps.passit` [PlayStrong](https://t.me/meetstrong/125) call methods with `libxposed` API signatures via JNI during its initialization, which is bounded to fail if dex obfuscation is always enabled. Vector has removed the user configuration of `Xposed API Protection` (toggling the dex obfuscation option) during its daemon refactoring in #597, for the reason that this option is too technical for most users. Ideally, module developers should extend their module compatibility with dex obfuscation mode, by for example, inheriting Xposed APIs. In any case, we now disable dex obfuscation for debug builds, so that Vector users could test out these modules.
We rewrite the Vector daemon from Java to Kotlin using a modular design as specified in the daemon README. This transition improves code maintainability and modernizes the codebase. We note below several behavior changes in this refactor. Bug Fixes and Improvements: - Directory Permissions: Correctly configured for XSharedPreference storage. - Database Management: Migrated to Android DatabaseHelper for better versioning and automatic migration from LSPosed database (`v101`). - CLI Tool: Added a command-line interface at `/data/adb/lspd/cli` for managing modules and scopes. Removed Features: - Denylist Filtering: Removed UI warnings for denylist apps, as the Vector functions independently of them. - In-app Updates: UI-based updates removed in favor of root-level manager updates (e.g., Magisk/KernelSU). - Logcat Watchdog: Removed due to lack of practical utility from previous debugging experiences. - Obfuscation Toggle: Xposed API obfuscation is now permanently enabled, while it remains configurable via `DaemonState` at compile-time.
During the previous refactor JingMatrix#597, we forget to implement the `auto_include` feature.
Modules such as `io.github.mhmrdd.libxposed.ps.passit` [PlayStrong](https://t.me/meetstrong/125) call methods with `libxposed` API signatures via JNI during its initialization, which is bounded to fail if dex obfuscation is always enabled. Vector has removed the user configuration of `Xposed API Protection` (toggling the dex obfuscation option) during its daemon refactoring in JingMatrix#597, for the reason that this option is too technical for most users. Ideally, module developers should extend their module compatibility with dex obfuscation mode, by for example, inheriting Xposed APIs. In any case, we now disable dex obfuscation for debug builds, so that Vector users could test out these modules.
…om (#809) Flash Vector, open it from the root manager, close it, and there is no way back in. The dialer code registered a filter with no action, which matches nothing, so that branch has been dead since #597; it works again and is rebound to 832867, VECTOR on the keypad. Parasitically the manager is not installed, so the launcher has nothing to show either: the pinned shortcut and the standalone install that #796 dropped return, in an "Opening Vector" section and a first-launch prompt, with `getManagerApk()` handing over the APK the host cannot read. Sixteen new strings, translated into all eighteen languages. The version string now names where a build came from rather than calling every canary "dirty", which it did only because the workflow writes signing credentials into the tracked `gradle.properties`. Repository and commit both come from the pull request's head, since GitHub's defaults describe the run and not the code. Closes #815.
#882) Constructing a Notification on Android 16 reads an aconfig flag of the systemui container, and the daemon cannot serve that read: it holds an ActivityThread but no application record, so the settings provider is refused it and the constructor throws SecurityException. Setting systemui_is_cached before the first read leaves the flags at their compiled defaults and removes the read. That bypass was gated on SDK_INT >= VANILLA_ICE_CREAM, wider than the release it belongs to, because Xiaomi shipped the change on Android 15 without the SDK level; #96 was such a device, four days before Android 16 DP1 was published. #597 rewrote the test as SDK_INT == 36 and lost that case, which #880 now reports on the same vendor and the same version. Android 17 sets those fields unconditionally, so the test spans 35 to 36, the versions in which the field can exist.
Handing a module app its `IXposedService` means starting it: the daemon acquires the module's own `XposedService` provider, which brings the process up, and passes the binder in the reply. That reference was never released, and the platform reads an outstanding external reference as a live client — so `OomAdjuster` held every module app at `FOREGROUND_APP_ADJ` with adj type `ext-provider`, never cached, and a host dying while its provider was still launching was restarted for it. The platform bounds those restarts at three per provider record; acquiring again rebuilds the record with the count at zero, which is how #889 reached fourteen process starts in seventy-six seconds, six of them ours. The release has to be unconditional, because the two returns that matter come back null with the reference already registered. Three consequences of the same path. The delivery no longer runs on the uid observer, where one module delayed every other module's binder by eight seconds. A failed send is no longer recorded as a delivered one, and repeated failures are throttled to one attempt a minute rather than one a second. And a delivery is recorded per process rather than per uid — a uid outlives any one of its processes, so the record could otherwise never clear. Separately, `getContentProviderExternal` gained its `tag` argument in Q by replacing the three-argument form, so the unconditional four-argument call has meant no module received its app-side service on 8.1 or 9 since #597. And the `IUidObserver` stub declared four of the interface's eight methods; the rest stayed abstract at runtime, which `oneway` makes fatal rather than reportable. Module apps are no longer immortal, so a scope answer arriving an hour later may find the app gone. The grant itself is written before the callback.



This PR transitions the framework daemon from legacy Java to a modernized Kotlin implementation, rebranded as
Vector. The refactor moves beyond a literal translation to implement a more robust, domain-driven architecture.See REAMDE in module
daemonfor more implementation details.