how to bind with aidl ipc to the daemon?

[itapi]

Hi! @JingMatrix
first of all,thanks for your awesome maintaining this project,thorught you busy personal life,phd,etc

I'm currently working on integrating with the LSPosed daemon via AIDL. I've noticed that communication through AIDL here works a bit differently than usual — especially regarding how parcelables are imported and shared between the manager and external clients.(tried to bind,but didnt found any eplicit intent for it)

Of course, I’ve imported all the relevant AIDL files into my project (an app I’m developing).

What is the correct or recommended way to communicate with the LSPosed daemon from an external application using AIDL?
Is there an official approach or best practice to follow?

I wont for example to use the setModuleScope from the LSPManagerService.java class,which uses the ConfigManager class.

I have cloned this project and build it from souce..so if need to change something in the source code..I'm able to do this of course :)

Thank you so so much !:)

Thanks in advance!

[JingMatrix]

Hello! I appreciate your passion about this project. I am also very glad to see that your interesting question here.

The short answer to your question is that: no, you cannot communicate with LSPosed daemon.

The binder used for the daemon-manager communication is sealed in a secure way, to not leak the trace of LSPosed.
I don't remember the full details, but you can start to recongnize this sealing mechanism from the function Service::InitService in service.cpp and the files BridgeService.java.

For your goal of using setModuleScope, I suggest you to directly modify the database created by LSPosed, in a way consistent to the codebase of LSPosed. This should suffice your usage.

In case of confusion, you may refer to PixelXpert.

[Dev4Mod]

The lsposed Modern API has these scope-requesting features, but to be honest, I've never tested them, and from the documentation, it looks like it was under development but unstable. These features are still available in Lsposed @JingMatrix?

[JingMatrix]

I haven't received any bug report regading dynamic scope.
Since the required functions are implemented in the codebase, so I suppose these APIs are already stable before the upstream closes.
However, there aren't many modules using these APIs.

If you are happy to try, I am willing to make LSPosed more robust regarding these APIs.

[itapi]

@JingMatrix thanks for your kind reply.

Actually, I don't intend to interact with the daemon via AIDL — instead, I tried to access the modules database directly, but I have two main questions:

How can I access the file /data/adb/lspd/config/modules_config.db using standard Java API, without executing su commands?
I consistently get "access denied" errors (SELinux) on multiple devices when attempting to read it directly.
Is there any way to bypass that limitation?
I'm wondering how the daemon itself manages to access it — does it run under a privileged UID like 2000, or have special context permissions?

I also noticed there's a caching layer involved.
When I manually update the database via su commands, the changes don’t take effect until a reboot.
However, when changes are made via the LSPosed Manager, they apply immediately (even without restarting).
I saw references to functions like cacheScopes() and cacheModules() — which probably trigger in-memory updates or notify the daemon to refresh.

Any insights on how the Manager/daemon handles this caching mechanism, or how to trigger a cache refresh programmatically, would be greatly appreciated.

Thanks again!

[JingMatrix]

Surely that, LSPosed data are well protected against third-party access, via SELinux.

Could you specify your overall (ultimate, initial) goal so that we can help you easier?

[itapi]

@JingMatrix Thanks again for your response!

To clarify my ultimate goal:
I'm building a content filtering system based on LSPosed, designed for end-users. The idea is to manage modules, their configurations, and scopes on a remote server, while a background app on the device continuously syncs and applies the correct setup — including activating/deactivating modules and setting scopes accordingly.

For this to work, I need programmatic access to read, modify, and apply LSPosed module configurations, without relying on the Manager app or directly interacting with the daemon via AIDL.

I did try accessing the modules_config.db file directly, and while it works via su commands, I would prefer to avoid that route — it feels a bit hacky and unstable, especially when considering production use across various devices.

So again, my main questions:

1)Is there any recommended way to access or modify LSPosed module data (especially scopes and active status) from a background app, without using AIDL or su?

2)Is there any way to ensure changes are immediately reflected (like triggering cache refreshes)?

I’d love any guidance you can share — especially on how to interact with LSPosed in a stable and consistent way across devices.

Thanks in advance!

B.T.W., I came across a fork by @mywalkb some time ago that added a CLI-based way to communicate with the daemon directly, not just through the Manager. While that approach is interesting, I prefer sticking with your official version, as it's more up-to-date and clearly much more maintainable and actively developed.
https://github.com/mywalkb/LSPosed_mod

[itapi]

@JingMatrix sir?

[Dev4Mod]

In my opinion, this would open a possible exploitation door, leaving the device vulnerable to attacks. I believe that the user must approve any scope request. Of course, with root it is possible to directly change the lsposed database, but allowing this for lsposed itself would be complicated in terms of security.

[Dev4Mod]

The CLI also had some restrictions that could be configured by the user to allow scope access, but in this case it had two layers, it needed root access and the user allowed access via CLI in lsposed.

[JingMatrix]

I don't really have an elegant solution for your project.

I'd suggest you, run a server, and urge users to sync updates by their own. To do this, it suffices to design your modules with dynamic scope requesting feature.