Develop Reference

Rendering a video from GStreamer in VR (Oculus Quest 2)

I'm working on a robot that is controller via the VR headset and sends a real-time video feed to the headset.
I've chosen to go the native way on Android and now have everything I need to receive the video stream and encode it (using GStreamer) and also to send the control data to the robot via UDP.
The last thing to do (and the one I most struggle with as I nave no prior experience with computer graphics) is to draw the image (encoded camera feed) to the screen. In the last few days, I've been reading stuff about how Vulkan and OpenGL works, I've also went through the examples provided in Oculus Mobile SDK (mainly VRCubeWorld_SurfaceView) but that's way to complex for what I need, I've tried to simplify it so I could just draw two images, but then I thought.
Do I even need any of that? And this question might sound stupid, but I really don't have any prior experience doing this.
I mean, the example is using OpenGL to basically compute all the layers of the 3D scene, apply colors and then fuse them together to get a final frame that is passed to VR_API via the function:
vrapi_SubmitFrame2(appState.Ovr, &frameDesc);
Can I just take those images, and somehow force them into the frameDesc structure to skip the whole OpenGL pipeline? If so, can anyone knowledgeable enough point me to a working solution?
I don't need any kind of panning over the images, just to render them. Later I'll be using head sensor data, but it won't actually do anything with the "scene".

Android Animation Alternatives

I want to implement a news ticker in my application, with vertical and horizontal scrolling, as well as some alpha animations.
I need the animation to be unaffected by the rest of the application (GPU/hardware accelerated). Especially since the application will be run on a Google TV box, and the user is expected to be using D-Pad navigation which can cause animation to become choppy.
These appear to be my options (I need to support Honeycomb and above):
Use the Android Animation classes
Will the performance of this approach ever match using OpenGL?
Is hardware acceleration possible, and reliable?
Easiest to work with.
OpenGL ES 2
There appears to be a limit to the texture size of 2048. If I have a headline longer than that
RenderScript
The documentation is sparse here.
In your opinion, what is the best solution? What other solutions are there?

One pattern that's common is to enable hardware acceleration, animate, then disable it. However, on the Intel based GoogleTV boxes there is a problem with text when you turn on Hardware Acceleration. I haven't tried it on an ARM based Google TV yet.
I am by no means an OpenGL ES expert, but I am a huge fan and have seen some wonderful things done using it for Google TV. That said, I think your understanding of OpenGL ES Textures is incorrect. The size of the texture should have little bearing on the length of a headline. I currently have an intern working on a bunch of OpenGL ES examples that we hope to publish by the end of August.
There is excellent sample code for working with RenderScript, even if the documentation is sparse. However some developers haven't been able to integrate RenderScript w/ d-pad navigation.
My suggestion is to try your worst case senario using OpenGL ES as a very short program and see how it works. It's likely to be the best solution.
I can imagine why your seeing choppiness on some GoogleTV animations, StateLists firing when D-Pading, but it's not an insolvable issue.

3D rotation like credit card in Android

I need to provide some 3D rotation of images, like credit card (please check the video in the link)
I want to know is it feasible or not, in the case of Android. If yes, how can I do that.
The card must have some thickness.

It definitely is feasible, but you will have to do some studying:-).
Start here: http://developer.android.com/guide/topics/graphics/opengl.html
But you may also achieve your goal by just using the video you have posted in your link.

Some context would be useful such as will this be a loading screen? Something in video? etc?
For instance, if you are trying to make a website style layout and have the card up at the top always spinning, I would advice against that on any mobile device as its a waste of performance.
If instead you are using it as a loading screen then again I would advice against it as you are going to spend a lot of time initializing open gl and loading the texture and mesh for the card as well as any lighting you need and then initiate animators and do the spinning etc.
As previously stated OpenGL would be a way of doing this; however, this is not a simple few lines of code. This would be quite the undertaking for someone unfamiliar with OpenGL and 3D modeling to accomplish in a short time frame.

Question: do you require a native Android app, or would it be alright to use Flash Player? You can find tons of interactive 3d geometry demos on http://wonderfl.net - I forked one that had a plane, switched it to a cube, and you can download the results -
3d box on wonderfl
Not OpenGL - the example I found was Papervision3D (which is out of date a couple of years) - but software rendering is fine for 12 triangles. You, of course, would have to import your card faces as texture images if you want to make it look like a credit card.

Android Live Wallpapers -- OpenGL vs Canvas

I am a fairly "newb" Android developer, and I would like one of my first projects to be a live wallpaper, however I am conflicted on whether I should be focusing on Canvas or OpenGL for it. Being new to this I know I should master Canvas first since it is easier to use, but I prefer to learn from real world projects that I have an interest in, even if it's a little backwards at times.
I have used both before in very basic ways, and I understand the general concepts to them, but I am not sure how they transfer over to the realm of live wallpapers. I figure that the full blown speed of OpenGL isn't required on a live wallpaper, since running it at max FPS would just run down the battery more than it necessary, but at the same time I am worried that using Canvas would cause lags and stutters when doing things like changing home screens.
I have been leaning towards using OpenGL ES 2.0, both to keep performance optimal and because my initial ideas for the wallpaper involve a lot of layering that I am not sure Canvas is capable of, but I'd like a more experienced developers opinion on whether or not all of the extra work involved in using OpenGL (especially in relation to live wallpapers, from what I've read) is worth it.

If you can get away with just drawing to a canvas (e.g. cube example in SDK), that's much less work. Because of the simplicity of the animation (no bitmaps), the cube is able to achieve a high frame rate without difficulty.
If you want to use OpenGL, you will need to use a supplemental package, such as GLWallpaperService, AndEngine, or RenderScript.
http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live-wallpapers
http://www.andengine.org/forums/tutorials/live-wallpaper-template-t258.html
Browse the Android source code to see how the stock wallpapers (e.g. Grass, Galaxy) are implemented using RenderScript. This link may work, but no guarantees: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android-apps/4.1.1_r1/com/android/wallpaper/ (then scroll down to the wallpapers)
Moonblink has discontinued his project, but if you're really keen, you can try researching his work (Substrate) starting here: http://code.google.com/p/moonblink/source/browse/wiki/Setup.wiki

I ended up using OpenGL as halfway through the project, canvas drawing proved to be too slow for what I was trying to achieve. Using OpenGL caused a massive performance boost. Unfortunately I had to refactor my code, so I would reccomend using OpenGL from the start. Dirty rendering is supported by OpenGL as well as the wallpaperservice's structure doesn't rely on the way you render things so you would still be able to create a wallpaper that doesn't drain the battery. Actually a well programmed wallpaper doesn't render when it's hidden. As the wallpapers shipped with android don't follow that pattern, live wallpapers now have the bad name of being battery suckers. Really a shame..

Using OpenGL for displaying a 2D map or not? (Android 3.0 SDK)

I want to create a simulation game and a main component of this simulation will be a 2D map (topographical/navigation map), which shall have different layers (objects are moving on the map, using of labels, you get it)
The question for me is now, shall I use OpenGL to accomplish this or is that not necessary? I have no special requirements apart of that the scrolling and zooming shall be smooth. The target platform are only Android tablets (so Android OS 3.0+).
Edit: To precise my question:
platform independence is not important for me
I'd like to go with the easiest way concerning implementation efforts

If and only if you're really targeting Honeycomb specifically, then don't bother with OpenGL... and I say that as a reasonably experienced OpenGL programmer who's done some cool things with it on Android.
My reasoning is that, starting with Honeycomb, the normal Canvas-based APIs are hardware-accelerated too. Typically the only real reason for using OpenGL was greatly increaased performance, but that is no longer the case.
Or so the theory goes... I've yet to see actual Honeycomb hardware and run comparative tests. What I do know is that the Honeycomb emulator shows triangular tearing everywhere, strongly suggesting the whole desktop is now going through the GL pipeline.

If you have solid experience with OpenGL go with it. If not try some performance tests before you really decide if you invest time to learn it or if you use the good old simple 2D canvas drawing...

I'm not an expert on OpenGL + android (or any other mobile devices), but I think you will get better results (more FPSs, better drawing and animation options, etc) using OpenGL.
If you're used to non-OpenGL android development and are new to OpenGL it would be easier develop the game without using OpenGL. But before you choose this option, be aware that it should be a better option to use OpenGL if you aim to achieve beautiful/good performance graphics!
In short, if you master "regular" android development and prefer to build something good enough in a short time, stay "regular". Otherwise, I advice you to go for OpenGL.