TL;DR
Even when doing no drawing at all, it seems impossible to maintain a 60Hz update rate on an OpenGL ES rendering thread on an Android device. Myste
Not sure if this is the answer, but note that the call to eglSwapBuffers() blocks for at least 16 ms, even if there is nothing to draw.
Running the game logic in a separate thread could win back some time.
Check out the blog post at the open source Platforming game Relica Island. The game logic is heavy, yet the framrate is smooth due to the authors pipeline/double buffer solution.
http://replicaisland.blogspot.com/2009/10/rendering-with-two-threads.html
You are not binding the framerate yourself. So it's bound by CPU.
Which means that it will run fast when the CPU has nothing to do and slower when it's doing other stuff.
Other stuff is running on your phone, which occasionally takes CPU time from your game. Garbage Collector will also to this, although not freezing your game like it used to do (since it now runs in a separate thread)
You would see this happen on any multiprogramming operating system that was in normal use. It's not just Java's fault.
My suggestion: bind the framerate to a lower value if constant bitrate is required. Hint: use a mix of Thread.sleep() and busy waiting (while loop), since sleep might go over the required waiting time.