Sorry I am not following what you are trying to do. On Thu, Mar 26, 2009 at 10:16 AM, F H <[email protected]> wrote:
> 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. >> >> > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
