Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AudioPluginInterfaceCallback object is not transmitted to service if client and service are different apps #188

Closed
atsushieno opened this issue Nov 26, 2023 · 4 comments
Labels
bug Something isn't working

Comments

@atsushieno
Copy link
Owner

In AudioPluginInterface.aidl there is setCallback() method that passes a callback object to the AudioPluginInterface service.

Its corresponding service setCallback() implementation receives in_callback correctly if the client and service are the same app (e.g. aapinstrumentsample on its own PluginManagerActivity), but if they are different apps then in_callback is nullptr.

@atsushieno atsushieno added the bug Something isn't working label Nov 26, 2023
@atsushieno
Copy link
Owner Author

atsushieno commented Nov 26, 2023

It is blocking notify_parameters_changed() dogfooding implementation in aap-juce (#130).

@atsushieno
Copy link
Owner Author

I wondered if cross-process callbacks are not supported, but it seems to work at least on Java level. Locally confirmed that this example works (it mentions an example git repo): https://stackoverflow.com/questions/13948671/how-can-i-use-aidl-remote-service-to-deal-with-defferent-clients-concurrent-req/34217138#34217138

@atsushieno
Copy link
Owner Author

Other possibilities:

  • NdkBinder does not support it yet
  • it is too early to send callback until onServiceConnected() call is done (it is currently done within the call)

@atsushieno
Copy link
Owner Author

atsushieno commented Feb 12, 2024

After more investigation, it turned out that NdkBinder lacks android.os.Binder equivalent, and it leads to missing Stub class in the generated code.

When we bind our interface e.g. MyService in .aidl, there will be IMyService.Stub class and IMyService.Stub.Proxy class if it were Java, along with IMyServiceDefault class. aidl(.exe) with -lang=ndk generates only IMyServiceDefault which only provides interface methods stubs.

android.os.Binder seems to do a lot of work and it is not easily ported to NdkBinder land (at least the full implementation equivalent would be hard task). We need to get around it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant