The standard Java compiler does some optimizations, but it leaves most of them to the JIT.
The JIT knows on which processor exactly the program is running and also has access to runtime information, and therefore it can do more optimizations than the Java compiler could do in advance. Also, doing extensive optimizations in advance could "obfuscate" the byte code somewhat, making it harder for the JIT to optimize it.
I don't know what Google's compiler does when it translates your Java byte code to Dalvik code - it might be doing more extensive optimizations.
Maybe this tool will be useful for you: Dalvik Optimization and Verification With dexopt
By the way, the example you mention is not always valid; transforming
a / 4 into
a >> 2 is not guaranteed to make your program run faster on any processor. I read an article somewhere once (sorry, can't find it right now...) that explained that on (I think) modern x86 processors,
a >> 2 might even be slower than
a / 4.
In any case, don't do premature optimizations like transforming
a / 4 to
a >> 2 by hand in your source code unless you have real evidence (from performance measurements) that it's worthwhile to do it.