According to http://developer.android.com/reference/android/graphics/ImageFormat.html#NV21, NV21 is the default used format.
There are quite a number of code on web
Terms like "most significant position" are ambiguous, because it depends on the endian of the machine.
When all data types are 8 bits, there is an easy unambiguous specification: byte order. For example, unsigned char rgba[4]; would have the data stored as rgba[0] = r; rgba[1] = g; rgba[2] = b; rgba[3] = a;
or {r, g, b, a } regardless of the endianness of the processor.
If instead you did
int32 color = (r << 24) | (g << 16) | (b << 8) | (a << 0);
you would get { r, g, b, a } on a big-endian system, and { a, r, g, b } on a little-endian system. Do you work on systems that have heterogeneous processors? Like maybe you have a CPU and a GPU? How do they know which endian the other is using? You are much better off defining the byte ordering.
First of all, I am not super experienced with image encoding (has some limited exposure to this about a year ago). So, take my answer with grain of salt.
However, I believe you are right. I think in their code both a) V and U are flipped b) R and B are flipped
I have a feeling that when both of these things are flipped, it will produce the same result as if they arent' flipped. That's the reason why you can find wrong code in many places (originally, somebody got it wrong and after it was copied all over the places, because the resulting code works (however, variables named incorrectly)).
Here is another example of code (which works the same as yours): http://www.41post.com/3470/programming/android-retrieving-the-camera-preview-as-a-pixel-array