EGL is defined here and appears to be in OpenGL ES something what GLUT was (?) in OpenGL world. At least, EGL is what takes care of actually displaying on screen what was rendered by OpenGL ES.
EGLNativeWindowType is defined in opengl/include/EGL/eglplatform.h as struct egl_native_window_t* . egl_native_window_t is defined nearby in opengl/include/EGL/eglnatives.h . This is nice, clean, standalone structure (unlike horror in Eclair+). It starts with a "magic" (signature) 0x600913, followed by "version" which is sizeof of the structure (now I know why Microsoft gets a buck on each Android phone sold - they for sure patented this (stupid? lazy?) trick widely used in Win32 API). There're some function pointers (virtual method table) used by EGL to call into native windowing system (deep, close to vendor drivers) to support its workings. Out of these, there's essentially one related to rendering finalization: swapBuffers(). So yes, it seems that eglSwapBuffers() just calls out to this. The structure also directly contains "Base memory virtual address of the surface in the CPU side" and other easily graspable memory/graphics notions.
It's clear that in its young years, Android was fair and naive, not suitable at all for typical vendor OpenGL mumbo-jumbo. The "fix" came with the later versions.
Eclair and following
EGLNativeWindowType is defined (in include/EGL/eglplatform.h) to be struct ANativeWindow*. ANativeWindow was android_native_window_t in Eclair, but was renamed to ANativeWindow in Froyo (android_native_window_t is still available for compatibility). ANativeWindow is defined in platform/frameworks/base/include/ui/egl/android_natives.h:
Actual implementation of ANativeWindow for read device screen is in libs/ui/FramebufferNativeWindow.cpp . There's factory function to get its instance: android_createDisplaySurface().
All implementation details on buffers used are hidden in android_native_buffer_t type. It is also subclassed from android_native_base_t, its magic is "_bfr". Among simple things like width/height it contains buffer_handle_t, which leads in utero of vendor graphics driver. buffer_handle_t is native_handle*, and native_handle is a generic container for arbitrary number of fd's and pointers.
native_handle's are produced by gralloc vendor module, and that's exactly what FramebufferNativeWindow constructor does - it loads gralloc module, then uses it to open framebuffer and gralloc devices. It then allocates back and front buffers from gralloc devices with the size of the framebuffer. queueBuffer() method is implemented by calling framebuffer's post() method which well, shows the buffer on the screen.