Actually the screen density auto scaling feature of Android plays havoc on OpenGL compatibility.
We got to back things up a little further actually...
1st if the images are not power of two that is a problem of course and you'll have to remedy it.
2nd if you are working with power of two images and are not using the drawable-nodpi resource directory then your images are likely being scaled by a factor of 1.5 (hdpi density scale factor). When you try and load the images 128x128 becomes 192x192 which is not a power of two thus failure with OpenGL.
Now to complicate things and here is the OS / build fragmentation aspect. drawable-nodpi doesn't work on Android 1.5 OS. For unscaled resources on 1.5 one just needs to put resources in the drawable directory. Unfortunately images in the drawable directory in 1.6+ are auto-scaled. On 1.6+ to remain compatible with 1.5 it's necessary to set a boolean in BitmapFactory.Options or call the setDensity method on bitmaps created neither of which are 1.5 API level 3. This requires reflection to handle properly.
Anyway.. I'm getting ahead of the current situation as you are interested in getting things running on the Droid first let alone the rest of Android devices!
You need power of two images stored in the drawable-nodpi directory.
"In my case you can see I'm creating a dynamic Bitmap based on the height and the width. Am I understanding wrong?"
It's fine to create a dynamic bitmap with the 2D API in fact that is an encouraged way to create/composite images of the right size for the given device. When it comes to loading that image into OpenGL ES though you'll have to make a power of 2 image. So with the Droid an 854x480 image can be stored in the next biggest POT slot 1024x512. If you draw the 854x480 image from the top left of the 1024x512 image you use texture coordinates in OpenGL to display a sub portion of the larger image in this case (0,0) -> (0.833984375, 0.9375).
Depending on the situation you can also cram an image into a smaller texture, but you'll loose data/resolution by doing so. Say for example cramming 854x480 into 512x256 texture. You can scale the bitmap with the 2D API to do this and when you load into OpenGL you can for instance draw in ortho mode the image from (0, 0) -> (854, 480) with texture coordinates (0, 0) -> (1, 1). It will display, but may have some artifacts/stretching depending on how bad the down scaling is; sometimes this works for the given purpose and saves space / memory... In this case unfortunately 854 falls just over the middle point in between 512 and 1024. In this case cramming the image into a smaller texture is probably not a good idea so a 1024x512 image with the given texture coordinates as mentioned above is probably the best way to go especially if it is a detailed HUD.
So yeah... Some of the automatic scaling features of Android that are meant to be helpful actually hinder OpenGL development. They are not a part of OpenGL as it is a device independent cross platform API. The automatic scaling features of Android help normal GUIs using the stock Android 2D GUI components and such and icons, etc. It breaks GL compatibility and it must be circumvented; more so if you want to support OS 1.5.