Does it mean that you do not need the c headers and have the 'pascal bindings' directly accessing the Java GUI API?
You can use both at the same time. In my current hello world I use only Java APIs in Pascal, but I am considering using native APIs for logging for example (unit log.pas in the lazarus-ccr bindings/android/ndk/log.pas). They are faster. If a native API is available, then the native API should be prefered. If only a Java version is available, no problem, we can use the Java version =) I am writing an article about this for the Blaise Pascal magazine.
A. Some Android functionalities may only be accessed via the Android NDK API.
As explained above, no problem. You can still use the NDK too.
B. It may be more sophisicated to do the direct pascal bindings.
It already works, just needs to be extended to support more classes / more methods.
C. The c headers may be a level of abstraction that may shield us from future changes to the Android API?
So far they are keeping backwards compatibility in the Java APIs. I don't have much experience in the NDK ones, and the entire NDK is too new to tell if it will have a good backwards compatibility.
D. OpenGL apps:
The indusctry trend is to move all GUI to OpenGL, think WPF, Wayland (replacement if X11.org ~ New Unity DE for Ubuntu). Does it mean that there will be a different Lazarus/FPC API (bindings) for the Android OpenGL API?
How does this fit in with the LCL ?
The Android Java GUI API uses OpenGL deep down.
I think that a LCL interface for Android could combine native GUI elements and OpenGL widgets (for TCustomControl descendents) together to achieve the best result.
A fully OpenGL LCL interface would be possible too, but it is a huge, imense work. And when you get the basic functionality done you will realise that you have no arabic letter joining, no virtual keyboard, etc, etc, etc. All features which are automatically taken care by native components.