ACCESS_SURFACE_FLINGER permission confusion
3,717 views
Skip to first unread message
F H
Mar 16, 2009, 11:28:56 AM3/16/09
to android-porting
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?
Is it the intention that an Android platform be signed with a certificate unique to an android provider, who if they wished could enable applications to be signed by the same certificate.
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).
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?).
Is it the intention that an Android platform be signed with a certificate unique to an android provider, who if they wished could enable applications to be signed by the same certificate.
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).
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?).
Dianne Hackborn
Mar 16, 2009, 12:51:26 PM3/16/09
to android...@googlegroups.com
On Mon, Mar 16, 2009 at 8:28 AM, F H <expel...@googlemail.com> 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/product/security;h=be33ff699f23419ffd2067daf5489f785551df70;hb=HEAD
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
hac...@android.com
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.
F H
Mar 16, 2009, 1:37:54 PM3/16/09
to android...@googlegroups.com
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.
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.
Dianne Hackborn
Mar 16, 2009, 2:19:19 PM3/16/09
to android...@googlegroups.com
If you are building your own device, you can give your own .apks any certificate they want, if they need to access your own private new features. If you don't want to sign your own .apks with the platform cert, then you will need to introduce some higher-level API that allows an app to call to the system process and do the work for it... of course ensuring this doesn't introduce any unintended security regressions etc. (For example, a very simple API might be createSecondarySurface(); it would not be createSurface(int whichDisplay).) This could just be a new API on IWindowManager or IWindowSession... this all just depends on how "real" you want your API to be.
pixelflinger
Mar 16, 2009, 3:16:06 PM3/16/09
to android-porting
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 <expelia...@googlemail.com> 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 <hack...@android.com>wrote:
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 <expelia...@googlemail.com> 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 8:28 AM, F H <expelia...@googlemail.com> 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...
> > On Mon, Mar 16, 2009 at 8:28 AM, F H <expelia...@googlemail.com> 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:
>
>
> > 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
> > hack...@android.com
> > 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
F H
Mar 26, 2009, 1:16:42 PM3/26/09
to android...@googlegroups.com
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...).
- 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...).
Dianne Hackborn
Mar 26, 2009, 2:28:54 PM3/26/09
to android...@googlegroups.com
F H
Mar 27, 2009, 10:12:58 AM3/27/09
to android...@googlegroups.com
Sorry - I'm rambling a bit
If I add an API to create a 'secondary surface' by extending the IWindowSession and adding the requisite calls to WindowManagerService.java it looks like I have something that works correctly (many thanks for the pointer).
One thing I'm puzzling over though is this:
- The new 'Surface' gets created in WindowManagerService.jave a using 'new Surface..'
- Should I be creating it using a SurfaceSession provided by the client or one in the WindowManagerService (or does it matter)?
- Should I be using the pid of the client or the pid of the current process (i.e. the WindowManagerServer) when creating the surface?
- If the Surface is created in the WindowManager and passed back to the client using something like outSurface.copyFrom(newly created surface) do I end up with a surface that has multiple references to it and do I need to call myNiceNewSurface.clear() multiple times to tear it down?
If I add an API to create a 'secondary surface' by extending the IWindowSession and adding the requisite calls to WindowManagerService.java it looks like I have something that works correctly (many thanks for the pointer).
One thing I'm puzzling over though is this:
- The new 'Surface' gets created in WindowManagerService.jave a using 'new Surface..'
- Should I be creating it using a SurfaceSession provided by the client or one in the WindowManagerService (or does it matter)?
- Should I be using the pid of the client or the pid of the current process (i.e. the WindowManagerServer) when creating the surface?
- If the Surface is created in the WindowManager and passed back to the client using something like outSurface.copyFrom(newly created surface) do I end up with a surface that has multiple references to it and do I need to call myNiceNewSurface.clear() multiple times to tear it down?
Dianne Hackborn
Mar 27, 2009, 12:42:29 PM3/27/09
to android...@googlegroups.com
You should follow the exact same pattern that the window manager does for the normal surfaces it returns to apps.
tony
May 5, 2009, 3:36:22 AM5/5/09
to android-porting
Hi Dianne,
Does it mean we can grant permission like ACCESS_SURFACE_FLINGER in
the camera application which is part of system? But it also fail to
grant permission.
B.R
Tony
On 3月17日, 上午12时51分, Dianne Hackborn <hack...@android.com> wrote:
Does it mean we can grant permission like ACCESS_SURFACE_FLINGER in
the camera application which is part of system? But it also fail to
grant permission.
B.R
Tony
On 3月17日, 上午12时51分, Dianne Hackborn <hack...@android.com> wrote:
Dianne Hackborn
May 5, 2009, 3:38:55 AM5/5/09
to android...@googlegroups.com
You need to be signed with the platform certificate. But the stuff this permission protects is really not intended to be used directly by applications -- the window manager uses it, and takes care of doing the correct arbitration between clients.
Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.
2009/5/5 tony <e13...@gmail.com>
tony
May 5, 2009, 6:18:03 AM5/5/09
to android-porting
Hi Dianne,
Thanks for quick response,the reason why I need it is because we want
to keep the View finder display unchanged when switch from portrait to
landscape.
And I'm not clear on how to "signed with the platform certificate"? Do
you mean use
jarsigner -verify -verbose -certs *.apk
How can we specify the permission ACCESS_SURFACE_FLINGER?
B.R
Tony
On 5月5日, 下午3时38分, Dianne Hackborn <hack...@android.com> wrote:
> You need to be signed with the platform certificate. But the stuff this
> permission protects is really not intended to be used directly by
> applications -- the window manager uses it, and takes care of doing the
> correct arbitration between clients.
>
> 2009/5/5 tony <e13...@gmail.com>
>
>
>
>
>
>
>
> > Hi Dianne,
>
> > Does it mean we can grant permission like ACCESS_SURFACE_FLINGER in
> > the camera application which is part of system? But it also fail to
> > grant permission.
>
> > B.R
> > Tony
>
> > On 3月17日, 上午12时51分, Dianne Hackborn <hack...@android.com> wrote:
> > > On Mon, Mar 16, 2009 at 8:28 AM, F H <expelia...@googlemail.com> 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.
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
>
> - 显示引用的文字 -
Thanks for quick response,the reason why I need it is because we want
to keep the View finder display unchanged when switch from portrait to
landscape.
And I'm not clear on how to "signed with the platform certificate"? Do
you mean use
jarsigner -verify -verbose -certs *.apk
How can we specify the permission ACCESS_SURFACE_FLINGER?
B.R
Tony
On 5月5日, 下午3时38分, Dianne Hackborn <hack...@android.com> wrote:
> You need to be signed with the platform certificate. But the stuff this
> permission protects is really not intended to be used directly by
> applications -- the window manager uses it, and takes care of doing the
> correct arbitration between clients.
>
> 2009/5/5 tony <e13...@gmail.com>
>
>
>
>
>
>
>
> > Hi Dianne,
>
> > Does it mean we can grant permission like ACCESS_SURFACE_FLINGER in
> > the camera application which is part of system? But it also fail to
> > grant permission.
>
> > B.R
> > Tony
>
> > On 3月17日, 上午12时51分, Dianne Hackborn <hack...@android.com> wrote:
> > > On Mon, Mar 16, 2009 at 8:28 AM, F H <expelia...@googlemail.com> 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.
>
> --
> Dianne Hackborn
> Android framework engineer
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support, and so won't reply to such e-mails. All such
> questions should be posted on public forums, where I and others can see and
> answer them.- 隐藏被引用文字 -
> Note: please don't send private questions to me, as I don't have time to
> provide private support, and so won't reply to such e-mails. All such
> questions should be posted on public forums, where I and others can see and
>
> - 显示引用的文字 -
Dianne Hackborn
May 5, 2009, 12:39:16 PM5/5/09
to android...@googlegroups.com
You specify the certificate in your makefile, the same as things like the Settings app.
Regardless, I don't see how getting this permission will allow you to do what you are asking for. And very likely, going directly to the surface flinger APIs that are protected by this permission, behind the window manager's back, is likely to cause problems. Seriously.hac...@android.com
Regardless, I don't see how getting this permission will allow you to do what you are asking for. And very likely, going directly to the surface flinger APIs that are protected by this permission, behind the window manager's back, is likely to cause problems. Seriously.
tony
May 5, 2009, 9:15:40 PM5/5/09
to android-porting
Hi Dianne,
The idea is to use Surface.setFlags() to pass a special flag so that
LayerBuffer can decide if it supports orientation change.
B.R
Tony
The idea is to use Surface.setFlags() to pass a special flag so that
LayerBuffer can decide if it supports orientation change.
B.R
Tony
mahesh mudela
Aug 23, 2014, 9:17:40 AM8/23/14
to android...@googlegroups.com
Hi,
I am unable to access surfaceflinger, How could I enable this for my experimetal task .
regards
mahesh
Reply all
Reply to author
Forward
0 new messages