> Yeah, that's what it does.
> But to reach that point it first uninstalls the old version and then only notices that that port had installed other stuff in the directory in question.
> By that time it already doesn't matter anymore that the new port does not get installed, since all the data of the previous version is already gone and there is no easy way back.
You simply activate or install the previous version again. We could perform something like a manifest check before but I think it'd be better to have the maintainer address these, either after someone else finds it in a ticket or in their own testing if they try manually installing the new after the old version (which is easier to do now thanks to archives).
> Right now I see already an SDK version 19 approaching… So, I am afraid that my virtual android machines will not be functional after the next port upgrade.
> But perhaps I am just missing something with regard to getting those virtual machines back to function.
Directories don't collide when installing from MacPorts, only files. MacPorts recommends letting it rename the files if you see fit.
An Android application contains an AndroidManifest.xml file; the manifest of a port-installed application should be tracked as the user likely won't modify it, and it appears to simply not have been tracked in the past. When opened by an IDE the manifest was likely created, by user or by the IDE. It likely was correct to delete/rename as MacPorts requested as the new application may need different permissions or have different Activity classes, not to mention a new version number.