Because Android includes stale (or rather ancient) versions of a few popular open source libraries (e.g. Apache HttpClient & Apache Commons Codec) app developers may run into problems when they want to make use of more recent versions of these libraries (e.g. #479).
Thankfully there is a Maven plugin, called maven-shade-plugin, which makes dealing with this sort of situation easy (e.g. http://stackoverflow.com/a/16916552/1084488).
But sadly android-maven-plugin and maven-shade-plugin do not seem to be compatible.
By default the maven-shade-plugin attaches itself to the package phase, meaning it performs the "class relocation" at the wrong moment in the apk build cycle, namely after, instead of before, dexing. Consequently only the jar is affected, not the apk (meaning the app code will still try to reference the library with the clashing package name).
I was therefore hoping it would be possible to make future versions of android-maven-plugin aware of maven-shade-plugin such that the shading can be triggered at the correct moment.
This possibility has been discussed before in 2011 (see https://code.google.com/p/maven-android-plugin/issues/detail?id=170) and a preliminary patch was produced, but as far as I've been able to find out the effort was abandoned.
In my opinion the most elegant solution would be to introduce some kind of <executeShadePlugin>true</executeShadePlugin> parameter in the <configuration> which would make android-maven-plugin aware of maven-shade-plugin.
Or, if the 2 plugins are inherently incompatible (which may be the case, see comment below) than perhaps it would be best if android-maven-plugin was extended with built-in support for this kind of "class relocation", without actually using the shade plugin as such.