Native Activity and layout.xml

[Philippe Simons]

Is it possible to mix native activties with opengl es rendering and a layout.xml file ?

in the android_native_app_glue.h there is a field ARect contentRect; but it seems to never be used by the implementation...

Thanks for help

[Doug .]

I'm reasonably certain this isn't possible.

[Philippe Simons]

any idea from android team?

On Sat, Apr 16, 2011 at 7:55 AM, Doug . <douglas...@gmail.com> wrote:

I'm reasonably certain this isn't possible.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Dianne Hackborn]

No, the whole point of NativeActivity is that the native code gets complete control over receiving events from and drawing to the window.  If you want to mix native code with Java code, you should use the normal JNI approaches; there is nothing better NativeActivity could do for you in that situation.  (And actually architecturally NativeActivity just doesn't work that way, so it wouldn't be NativeActivity at all that would do this.)

--
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, 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.

[Philippe Simons]

ok thanks

[Bob Holmboe]

Dianne,

 

 The reason people keep asking about this approach is that there is alot of existing 'C' code that could be ported to Android if there is an easy to do the port. The Android team should keep the 'easy port' idea in mind when developing the framework. In my opinion you could jump start a lot of application being ported to both the phones and the tablets if someone comes up with an easy way to port the existing 'C' source.

 

                                                                                                               Thanks,

                                                                                                                Bob H  

[Dianne Hackborn]

NativeActivity doesn't make it easier to port C code, it makes it easy to write a native app that completely takes over the activity's window.

What about NativeActivity besides that do you think would make things easier?  It does have a separate loop for the native code to run in, but if that code isn't getting UI events and doesn't have anywhere to draw, there is not much interesting for it to do I don't think.

Is it really that hard to write a little JNI wrapper to call in to your C code?  You are most likely going to need to do that pretty quickly when using NativeActivity anyway, unless your app is relatively simple like a game and only cares about the input events and screen drawing it can do.

[Doug .]

Direct access to the pixel buffer without having to invoke JNI calls or use opengl springs to mind...

(Specifically this would make it easier to port gui frameworks).

[Dianne Hackborn]

On Fri, Apr 29, 2011 at 7:32 PM, Doug . <douglas...@gmail.com> wrote:

Direct access to the pixel buffer without having to invoke JNI calls or use opengl springs to mind...

That is part of the 2.3 APIs for working with surfaces.  Given a Surface object, you can use the APIs to directly access the frame buffer or create an OpenGL ES context on it.

[Doug .]

What Surface object?

When you init an egl drawing context you do this (summary form):

  // init

  EGLDisplay display = eglGetDisplay(EGL_DEFAULT_DISPLAY);

  eglInitialize(display, 0, 0);

  // select display

  EGLConfig config;

  EGLint numConfigs;

  const EGLint attribs[] = {

    EGL_SURFACE_TYPE,

    EGL_WINDOW_BIT,

    EGL_BLUE_SIZE, 8,

    EGL_GREEN_SIZE, 8,

    EGL_RED_SIZE, 8,

    EGL_NONE

  };

  eglChooseConfig(display, attribs, &config, 1, &numConfigs);

  // magical native activity visual buffer init

  EGLint format;

  eglGetConfigAttrib(display, config, EGL_NATIVE_VISUAL_ID, &format);

  ANativeWindow_setBuffersGeometry(android->window, 0, 0, format);

  // Create surface & context

  EGLSurface surface = eglCreateWindowSurface(display, config, android->window, NULL);

  EGLContext context = eglCreateContext(display, config, NULL, NULL);

  // Try to bind 

  if (eglMakeCurrent(display, surface, surface, context) == EGL_FALSE) {

    na_error(impl->gfx->api, "Unable to invoke eglMakeCurrent");

    return(-1);

  }

In this, the EGLSurface is a void * object, and the android->window is an ANativeWindow * object, which is purely a typedef with no content in /includes/android/native_window.h.

What surface are you talking about?

As far as I'm aware, the only way of directly accessing pixel data is using int AndroidBitmap_lockPixels(JNIEnv *env, jobject jbitmap, void **addrPtr), which involves having some java code somewhere to get access to the jbitmap object...

~

Doug.

[Dianne Hackborn]

The API in native_window_jni.h to retrieve a native surface object from a Dalvik Surface:

/**

 * Return the ANativeWindow associated with a Java Surface object,

 * for interacting with it through native code.  This acquires a reference

 * on the ANativeWindow that is returned; be sure to use ANativeWindow_release()

 * when done with it so that it doesn't leak.

 */

ANativeWindow* ANativeWindow_fromSurface(JNIEnv* env, jobject surface);

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Doug .]

I don't see how that's possible without using jni in a native activity application.

An example would be great...

(NB. As per the original post I'm talking specifically about a native activity application without an java code).

~

Doug.

[Dianne Hackborn]

I guess I am confused about the question, then.  Saying "a native activity application without any java code" doesn't make sense in terms of using a layout.xml, because the layout files are purely relevent to using Java code -- I mean, each tag is the name of a Dalvak class to have instantiated.

In my answer to your question, "Direct access to the pixel buffer without having to invoke JNI calls or use opengl springs to mind...", the NativeActivity API allows you to do this, so I again am getting confused what different thing is being asked for here.

I thought you were asking for being able to do so something related to the original poster's question, integrating native code with a layout.xml which is providing a top-level object hierarchy of Dalvik View classes that are managing the window.  In that case, you can use the API I pointed to to provide your native code with a drawing surface, such as by putting a SurfaceView in the view hierarchy and letting it take ownership of drawing that surface.

~

Doug.

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Doug .]

Yes, ignore the layout.xml thing. That's clearly not possible.

If there is actually a way to get access to the pixel buffer in a native activity application without using java I would love to find out how to do it. If you can point me in the direction of any documentation or examples of this I would very much appreciate it.

Very specifically I want to use freetype to render fonts without being forced to build a font atlas in opengl. 

As far as I'm aware, the only way of doing this is as is shown the bitmap_plasma example, which does not use native activity. If that's not the case, please link me up with more info.

~

Doug.

[Philippe Simons]

what about native-plasma sample?

~

Doug.

--

[Doug .]

Oo... thanks. nifty. I didn't see that~

For anyone else who's looking, the relevant function calls are ANativeWindow_lock() and ANativeWindow_unlockAndPost(), which give you access to the ANativeWindow_Buffer struct, with (void *bits) which is the actual pixel buffer.

~

Doug.

[Dianne Hackborn]

Please note, you can not mix direct pixel access with OpenGL acceleration.