Availability of binder for multiple application

Many thanks.

I understood. So I close this ticket.

Many thanks.

I understood. So I will close this ticket.

> Supported but not optimal – only for legacy apps
> Drawbacks
> - UI and business logic are in the same app (monolithic)

Instead of splitting UI part and business logic part as done in type 1 or 3, the application is "monolithic". So it's more difficult to adjust one side without changing the other. Legacy apps are written like this and very difficult / expensive to change.

> - API access is not handled automatically

As your application has no binder, you don't have the "ghost API" functionality as in type 1. So the application must implement the same logic as the one in the binder to "know" how to contact a given service. That's useless duplicate work.

> - Apps must handle security appropriately

A binding running inside a binder exposes an API which can be protected with permissions on API verbs: the security mechanism is already implemented for you. For the legacy app, you'll be on your own: if you app exposes an API,; you'll have to secure it by yourself. Again, you'd have to redo what's already done in the binder.

So technically, type 2 could work but at least for the reasons above, it's far from optimal and we don't advise to use it.

Thank you for your quick response.

Sorry to bother you, but I'd like to know more detail about your below comment for type.2 of my original question file. Actually I cannot understand well the drawbacks which you point out.

> Supported but not optimal – only for legacy apps
> Drawbacks :
> - UI and business logic are in the same app (monolithic)
> - API access is not handled automatically
> - Apps must handle security appropriately

At the moment the documentation http://docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-binder/afb-overview.html is up to date.