Ask your self a question do you really need pixel perfect collision detection. Actual device screen is usually so small that its just not worth it. Pixel perfect collision detection is performance is really bad and the gains are usually neglible. Just compose your game objects from primitives: circles, rectangles, maybe even polygons. Then math is lot more robust and more performant.
Also keep in mind that there is ton of difference size screens in Android scene. How you deal with that if your game logic is based on pixels? What happen when you want animated characters? Do collision events based on current animation state and cause jerky movement.

I desing all my game sizes on meters, this is just lot more natural and work perfectly well on every screen size and every scenario. If I decide that I need more accurate graphics and I double all picture sizes that do not cause any changes on logic layer.

How are you rendering the rotated images? In particular:

1. Are you using anti-aliasing? If so, you're going to need to define how pixel-perfect collision should work...
2. Is the angle quantised?
3. Do you pre-render anything to a back-buffer? If not, is the memory vs performance tradeoff the reason why not?

Just read pixel, if its opaque add transformation to that coordinate(local texture coordinate) and then check sprite position + transformed pixel against geometry that you want.

Still I disagree the need of pixel perfect collision detection. Pixel perfect collision just means that you divide your object to size*size number of rects and bruteforce all possible collisions. Non naive implementation would use just as many rectangles that are needed for accurate collision detection. Bounding boxes are your friend learn to use them right.
Pixel perfect collision might work good enough for object vs static objects and only when you don't need collision forces but it's just not scalable or offers anything that would not be possile with other means.

I personally use Auriel Ribbon's box2d editor. http://code.google.com/p/box2d-editor/
I take my game object image and draw outlines and rest is magic. I would suggest you to think something similar in future.

I allready gave an answer how to do it.

I have a friend who made a game engine in Delphi and the other day he showed me how he deals with this type of collisions:

 On every frame he calculates a "bounding polygon" of the sprite and uses it as a sort of bounding box, checking if it overlaps with other sprites. The result was amazingly precise... You don't have to make a perfect silouette of the sprite for the sake of performance, but calculating the relevant points that cover the current frame and joining them would be enough. Maybe on Android it's too much calculation per frame, I don't know, but you could try that approach.