Thanks Dianne/Mathias - I want any class I create to look indistinguishble from any other kind of Surface - e.g. supporting SurfaceHolder, so that it can be locked and drawn to, or passed to a media API for video playback.
- Presumably, the way Android would specify which display a surface were to be placed on would be to add a property that can be set on SurfaceHolder before the thing is laid out - e.g. setDisplay (along with setFlags, setType...). On Mon, Mar 16, 2009 at 7:16 PM, pixelflinger <[email protected]>wrote: > > Also note that SurfaceFlinger will be largely overhauled in future > releases, as well as its client library and protocol to both create > surfaces and talk to real h/w. We are not ready to share these changes > yet, as they are not finalized, but they will most likely make your > applications incompatible and integrating your SF changes, > challenging, to say the least. > > I don't think that supporting multiple displays should be done using > SF at this time. A simple way, could be to simply open /dev/fb1, > create a Canvas on it, or, directly blast video into there. You could > achieve this with a small server on the side of surfaceflinger and a > simple binder interface to access it as well as minimal API changes to > the system. > > Mathias > > > > On Mar 16, 10:37 am, F H <[email protected]> wrote: > > Thanks Dianne, > > > > I'm trying to figure out the best way of creating a Surface that can be > > displayed on an alternative display. I know that Android doesn't support > > multiple displays. Our version of SurfaceFlinger does though, so I was > > hoping to talk to it using a low-level interface in order to obtain a > > Surface on the alternative display. The Surface in question being one > that > > is suitable for using in a media player for example. > > > > The WM doesn't manage multiple displays and from what I can tell, unless > you > > have low-level access you can't tell SF to create a Surface on a > different > > display. > > > > Do you have any thoughts on the best way of implementing such a feature > > without contaminating any of Android's API's. > > > > On Mon, Mar 16, 2009 at 4:51 PM, Dianne Hackborn <[email protected] > >wrote: > > > > > On Mon, Mar 16, 2009 at 8:28 AM, F H <[email protected]> > wrote: > > > > >> Is it intended that low level access to Surface Flinger is granted > only to > > >> components that a part of the system and not to applications developed > using > > >> the SDK and signed using an arbitrary certificate? > > > > > Yes. > > > > >> Is it the intention that an Android platform be signed with a > certificate > > >> unique to an android provider, > > > > > Yes. > > > > >> who if they wished could enable applications to be signed by the same > > >> certificate. > > > > > No, this would allow you to write third party applications that are > either > > > significant security vulnerabilities and/or break across platform > releases. > > > The platform certificate is intended to be exclusive to the device > > > manufacturer, and something they keep private. > > > > >> When an android system is built - where is the certificate that is > used > > >> for signing the system and does it need to be generated in a > particular way > > >> (e.g. does it need to be generated by some signing authority). > > > > > No it can be generated the normal way you general one for an SDK > developer. > > > > > The development certs are here: > > > > >http://android.git.kernel.org/?p=platform/build.git;a=tree;f=target/p. > .. > > > > > I don't know off-hand how you sign with your "real" certs; but a basic > rule > > > is that these are not checked in to any source repository but done as a > > > separate step as part of making a final release image, and only > accessible > > > to a few select people. > > > > >> Presumably applications that connect up to surface flinger are routed > > >> through something that has the requisite permission. (Or is it that > apps in > > >> general do not use low-level access?). > > > > > Applications do not get to use surface flinger. The window manager > uses > > > surface flinger, and provides the higher-level access that can be kept > > > stable across releases. > > > > > -- > > > Dianne Hackborn > > > Android framework engineer > > > [email protected] > > > > > Note: please don't send private questions to me, as I don't have time > to > > > provide private support. All such questions should be posted on public > > > forums, where I and others can see and answer them. > > > --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
