On Feb 26, 2:48 am, F H <expelia...@googlemail.com> wrote:
> As I understand it SurfaceFlinger is a service and clients talk to it
> through a Binder interface. Help with talking to this service can be
> obtained using the native ui library.
>
> I'm not familiar with Binders, but was wondering whether something like a
> Java application could connect to the service through a route other than the
> UI library - e.g. using the Binder Java APIs.
>
> (Perhaps the window manger does this already).
It does. There are Java version of the UI lib client API (that's what
Surface.java is).
You could also talk binder directly -- it won't be fun.
> The reason I'm asking is; If I:
>
> a) replaced the UI library components that talk to SurfaceFlinger with
> functions that talked to something else (e.g. a functionally equivalent
> alternative compositor - with the same interface at the library level).
> b) rebuilt everything to use the modified UI library.
> c) removed SurfaceFlinger as a service.
>
> What would break?
It could work in theory. the SF API is actually pretty small.
Note that none of the native APIs are public (in the sdk) and that
they *will* change in incompatible ways in the future. So relying on
SF's binder protocol or even the client libraries, is not safe.
> Thanks.
> FH.
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---
