Segmentation fault due to attempt to launch native gles2/egl app on android, without native activity

Question

Sorry my English, I'm not native speaker.

I'm trying to launch simple gles2/egl app on android (Galaxy S4, Jelly Bean) without native_activity.

I have next main.c:

#include <stdio.h>
#include <stdlib.h>

#include <EGL/egl.h>
#include <GLES2/gl2.h>

int main( void )
{
  EGLDisplay dpy;

  printf( "hello world.\n" );

  dpy = eglGetDisplay( EGL_DEFAULT_DISPLAY );
  printf( "egl dpy: %p.\n", dpy );

  return 0;
}

And next Android.mk:

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS) 

LOCAL_MODULE := hello_world_gr
LOCAL_SRC_FILES := main.c

# I have found libGLESv2.so and libEGL.so libraries and appropriate header files in ndk.
LOCAL_LDLIBS := -L/home/ila/programs/android-ndk-r10e/platforms/android-18/arch-arm/usr/lib -lGLESv2 -lEGL
LOCAL_C_INCLUDES := /home/ila/programs/android-ndk-r10e/platforms/android-18/arch-arm/usr/include

include $(BUILD_EXECUTABLE)

I have chosen 18-th NDK-supported API level due to I have 4.3 (Jelly Bean) android release.

My project's directory looks like (before building):

prj:
--  jni:
    -- main.c
    -- Android.mk

So, I launch ndk-build (in prj directory) and obtain ARM ELF executable file in prj/libs/armeabi and in prj/obj/local/armeabi/ with name hello_world_gr.

Also I was trying to pull out libEGL.so and libGLESv2.so libraries from phone and use them for linking.

In both cases, app is successfully launched on phone without any linker error, app prints hello world and receives segmentation fault in eglGetDisplay with some delay (in which nothing is occurred).

If I try to do this on desktop Ubuntu:

$ gcc -o hello_world_gr main.c -lGLESv2 -lEGL
$ ./hello_world_gr
hello world.
egl dpy: 0x25e7010.

As you can see, all is fine.

On X11-based target, I can obtain EGLNativeDisplay via, for example, xcb_connect(), and pass it to eglGetDisplay, does such function exist for android (of course I mean about C/C++ function)?

You can look to https://android.googlesource.com/platform/hardware/libhardware/+/master/tests/hwc/ and ensure that it isn't my crazy idea.

I have built and launched this example but, again, have received such segmentation fault within eglGetDisplay. (I have built this app also manually via ndk, no full Android build.)

Did anybody try to do this? Did you get success?

Answer 1

I'm not sure why your code snippet is crashing , but I wouldn't expect it to work. Certainly not while the rest of the Android framework is running.

While we like to think of computers and devices as having The Frame Buffer, in practice such a thing might be inaccessible or not exist at all -- perhaps replaced by a set of configurable overlays. On Android, framebuffers and overlays are managed at the lowest level by the hardware composer (HWC), and at a slightly higher level by the system graphics compositor (SurfaceFlinger).

The best place to look for non-app examples is the frameworks/native/opengl/tests directory. If the system compositor is running, you can ask it for a surface to draw on. The "angeles" demo provides a nice example. It uses the WindowSurface class (in the lib directory) to get a top-level display-sized surface from SurfaceFlinger. It will work even while apps are running.

If SurfaceFlinger isn't available, you'll need to interact with the hardware composer directly. The tests in the hwc directory do this. Note they will not work if SurfaceFlinger is running. (And they're old enough that they might not work at all anymore.)

None of this uses public SDK APIs, so your code is likely to break if run on an older or newer version of Android.

More information about the Android graphics architecture, especially SurfaceFlinger and the HWC, can be found here .