I would like to write an application for Android which displays stuff on screen using the framebuffer. This will run only on a specific rooted device, so permissions etc is not a problem. Same application (simple test version anyway) is already running okay on PC/Linux.
The questions:
How to avoid the Android OS from accessing the framebuffer? I would like, while my application is running, to have the OS never touch the framebuffer, no writes and no ioctls. What do I need to do to get exclusive use of the framebuffer, and then (when my application quits) give it back to the OS?
Are there any differences between Android framebuffer and Linux framebuffer to watch out for?
P.S. I would like to start my application as a regular Android application (with some native code), it just has no visible UI except for framebuffer draws which take over the whole screen. It would be nice to still be able to get events from the OS.
See also:
http://www.kandroid.org/online-pdk/guide/display_drivers.html
Hi Alex Not sure why / how to stop android OS from writing to framebuffer. As long as your android application is visible and on top you have the control as what you want to display.
Your application should have an activity with a SurfaceView ( you may want your application to hide notification bar call this function in oncreate of your activity)
requestWindowFeature(Window.FEATURE_NO_TITLE); )
your activity should have SurfaceHolder.Callback implementation to handle callbacks as when the surface is ready to filled with framebuffer. Get the surface holder object as SurfaceView.getHolder() incase you want set pixel formats of the view etc.
Once "surfaceCreated" callback is called you can safely pass your surfaceview object(passing width and height maybe a good idea too) to the native so that you can fill it framebuffer using "ANativeWindow" class.
Check NDK sample code to see how to use the class NDK documentation
SurfaceHolder.Callback documentation
SurfaceHolder documentation
essentially you need to these (ON JB /Kitkat)
get the native window (ANativeWindow) associated with the surfaceview by ANativeWindow_fromSurface.
Acquire a lock on the ANativeWindow by ANativeWindow_acquire .
Set geometry parameters(window,width,height,pf) for the nativewindow by ANativeWindow_setBuffersGeometry
Load the nativewindow with the frambuffer stored (apply dirty rectangle if any here)
by ANativeWindow_lock
Final step to unlock and post the changes for rendering by ANativeWindow_unlockAndPost
Go through the ndk sample examples in case you need sample code.NDK documentation
Related
I am developing an android app for the fresh Google Cast API for remote display
https://developers.google.com/cast/docs/remote
I have used libgdx for rendering my objects on the device android screen.
That worked fine.
Now I want to add functionality to my app: render some other objects to another view that I can pass to the layout of remote screen.
I have tried as in the remote display example, first I created an AndroidGraphic and pass this to the setRender function because AndroidGraphic is implementing Renderer interface:
setContentView(R.layout.first_screen_layout);
firstScreenSurfaceView = (GLSurfaceView) findViewById(R.id.surface_view);
// Create an OpenGL ES 2.0 context.
firstScreenSurfaceView.setEGLContextClientVersion(2);
// Allow UI elements above this surface; used for text overlay
firstScreenSurfaceView.setZOrderMediaOverlay(true);
firstScreenSurfaceView.setRenderer((AndroidGraphics) mGraphics);
If i run this alone, this is working fine - objects are rendered by libgdx to the remote screen. But if I start my Activity that renders via libgdx and I also start the renderer in the service as described above, one screen freezes at the begin, the other screen in my case remote screen (TV connected via Chromecast) is rendering the view right.
My question is now: is it possible to render for two views at the same time with libgx android backend? Or are they using shared resources that this is not possible?
Because if i run my activity on device render via libgdx and run the CubeRender at the same time, they are both working well simultaneously. So I think my problem is by libgdx and shared resources.
I am happily using libgdx for an android game application.
At a specific point in the game, I use a FrameBuffer object to render the screen onto, and then use its attached color texture for rendering that to the screen (to be able to render a half-transparent screen with full-color rectangular zones).
The documentation for FrameBuffer says:
FrameBuffers are managed. In case of an OpenGL context loss, which only happens on Android when a user switches to another application or receives an incoming call, the framebuffer will be automatically recreated.
And that works perfectly, I can switch to other applications, put the device in sleep mode, go back to the application and everything including the framebuffer is working as usual.
The problem begins when I try and change the device's language when the application is running (using the android settings menu).
After I change the language to something else, the framebuffer attached texture becomes completely black (either the rendering to it fails or its rendering to the screen does).
The incredible thing is that, even if I restart the application (i.e. the application reaches its onDestroy() method and exits), the problem does NOT go away, and it does only when I kill the application process from the task manager.
I probably could solve this by adding a System.exit(0) inside the onDestroy() method, but does anyone have an idea about what exactly happens when I change the device language?
I cannot think of any possible relation between that and the framebuffer object state (the other textures are working as usual!), if anyone could enlight me it would be greatly appreciated.
Can anyone explain me what is android SurfaceView? I have been trough the android development web site and read about and i cant still understand it.
Why or when is it use in android application development.Maybe a good example if possible
Thank you
Android SurfaceView is an object that is associated with a window (but behind a window), using which you can directly manipulate the canvas and draw whatever you like.
What is interesting about the implementation of SurfaceView is that although it lies BEHIND a window, as long as it has any content to show, Android framework will let the corresponding pixels on that window to be transparent, thus making the surface view visible.
It is most likely to be used for building a game or browser, where you want a graphical renderer to calculate pixels for you while you can also use java code to control the normal APP logic.
If you are new to normal Android programming, chances are you do not need to know too much about it.
For further information, see this and the official documentation.
View or SurfaceView comes into picture when you need custom design in the android layout instead of using existing android widgets provided from android.
Here the main difference of View and SurfaceView is drawing threads. View is drawn in the UI thread and SurfaceView can be drawn in a separate thread.
Therefore SurfaceView is more appropriate when it requires to update UI rapidly or rendering takes too much time (eg: animations, video playback, camera preview etc..)
I'm trying to figure out if it is possible to use a camera video stream from within a background service rather than from a normal intent.
What I had in mind is this:
start the service from my app
this service accesses the video stream and extracts features continuously; depending on the features, it sends network packets (to localhost)
user switches to another app - the service must still be running and extracting features!
Before trying to implement all that, I'd like to know if it was possible.
Thanks in advance
Nicola
yes its possible, check my answer and sample code on one similar thread
Open/Run Camera from background service in android
You have to show the fake preview over the current screen. For that you have to create the surface view with 1*1 px dimension and display the preview in that. You have to draw the surface view over other apps for that.
Check out this library that provides facility to capture image from the background even from the service.
I don't think this is possible as the camera needs a preview screen. See previous question here
I would just like to ask if SurfaceFlinger is always called for any type of drawing into the screen?
Example, displaying of JPG file to the screen.
SurfaceFlinger is not what draws your window. It allocates a frame buffer for your window, which the framework running in your application draws directly to without interacting with SurfaceFlinger. The only interaction SurfaceFlinger is involved with when you draw your window is to composite the final new frame buffer to the screen once you are done drawing a frame.
http://pierrchen.blogspot.jp/2014/02/what-is-surfaceflinger-in-android.html
SurfaceFlinger is an Android system service, responsible for
compositing all the application and system surfaces into a single
buffer that is finally to be displayed by display controller.
Let's zoom in above statement.
SurfaceFlinger is a system wide service but it is not directly
available to application developer as Sensor or other services can
be. Every time you want to update your UI, SurfaceFlinger will kick
in. This explains why SurfaceFlinger is a battery drainer.
Besides your application surfaces, there are system surfaces,
including status bar, navigation bar and, when rotation happens,
surfaces created by the system for rotation animation. Most
applications have only one active surface - the one of current
foreground activity, others have more than one when SurfaceView is
used in the view hierarchy or Presentation mode is used.
SurfaceFlinger is responsible for COMPOSITING all those surfaces. A
common misunderstanding is that SurfaceFinger is for DRAWING. It is
not correct. Drawing is the job of OpenGL. The interesting thing is
SurfaceFlinger used openGL for compositing as well.
The composition result will be put in a system buffer, or native
window, which is the source for display controller to fetch data from.
This is what you see in the screen.
Yes, SurfaceFlinger is Android's compositor so it takes everything that will get displayed, figures out what the resulting frame will look like and then sends it off to be displayed on the screen via the graphics card's EGL interface.
You can get the idea that it controls the result of everything you see in a post by Android developer Jeff Sharkey where he tints the whole screen for nightmode. I also found a beamer presentation that looks good about this topic.