Android SurfaceFlinger

[Badri C]

I want to develop a native application targeting Android 4.0.4. A android application will run on a android device but its display and control will be shown on another device.

To achieve this i want to understand how the android application generates its display surfaces, how those surfaces are passed through the binder to SurfaceFlinger and how those are displayed on the screen.

Please can anyone help me with what methods, and which native libraries should i use to achieve the above functionality.?

Thanks

[sithruk sana]

I am not sure how far i could help, but few things are :

There is something called ANativeWindow in the Native Layer which can be easily mapped to the SurfaceView of Application Layer.  The rendering you can do directly  to the ANativeWindow. It is bit complicated, but doable. You may need to run through Basic JNI Layer to get JavaVM instance inside Native layer, and also, to get the reference of the surfaceview.

Displaying into different mobile?.  I am not sure, probably someone can help me in this.

[Ron Munitz]

What you are trying to achieve is not trivial.
You cant use the surface completely by its own for such a task (unless you really only care about the fb itself,  and willing to sacrifice performance), but you can actually live without it.
A couple of helpers:
Master the EventHub
And have a good look at the native canvas (SKCanvas ).
The HW accelerated canvas behaves differently, and there are some tricks with the webkit/later chromium ones.

Note that a lot has changed since 4.0.4, so if you dont need high performance I would recommend you just install a vnc server on one of the devices, and customize a vnc client on the other one.
There are open source projects for both.

-Ron Munitz

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.
To post to this group, send email to android-...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.

[sithruk sana]

Hi Ron,

Thanks and nice explanation. :). i have a question " Does anyway SKCanvas is related to SurfaceView?."..  SKCanvas is an independent framework ? or part of the android stack itself?

On Friday, May 30, 2014 5:51:24 PM UTC+5:30, Badri C wrote:

[Ron Munitz]

Don't get me by the word, ESPECIALLY since buffering has changes significantly between the versions, but I would refrain from using the word "independent".

There are multiple layers, and I am afraid it will take me time to answer subsequent questions, so I'll be very brief and inaccurate.

Theoretically it should give you the places to look at. When I say look, I mean run, attach, debug, and be patient. 
In fact, any discussion which does not seriously involve different pipelines in the GPU is incomplete - but as these are extremely hardware dpendent, it ovecomplicates an initial discussion. 

To make a very long story short, and setting aside  the view system itself (i.e. android.widget.*,  ViewRootImpl et. al...)  and graphic acceleration (see libgles, libgralloc et. al) there are 4 layers you should care about when starting to look at this subject.

Java Canvas, Native Canvas, Surface and FrameBuffer.

A native canvas is a data structure that can hold an image, and manipulate it. It knows to draw shapes, draw images, draw text, etc.

The Java Canvas is a way to communicate with the Native Canvas. Hardware does not speak Java. VM's do. The libandroid_runtime is roughly a JVM.

Now that's great. But these are logic entities. They are pretty much like an HTML5 <canvas> </canvas> element. 

Something needs to actually make sense of these to the hardware, and that's what Surfaces do.

Surfaces allow to hold such a canvas, and eventually "automagically" pass them on to something that communicates with hardware.
The end result is the framebuffer (which today is usualyl not the simplde /dev/fb or /dev/graphics/fb it used to be). What you see on your screen - it is roughly a matrix of ARGB. 


Disclaimer: This is extremely simplified and inaccurate, but thanks to my students I believe it is much less overwhelming than getting to the "right" thing at first shot.
It may be pretty accurate to the ICS versions though. Honestly, I don't remember exactly what was then.

Good Luck,

Ron.

--