Even as a developer, I hope to God that is never available to anyone but Google.
If I've downloaded a free app, and the developer decides he wants money instead, I don't want him having the power to forcibly uninstall the free app from my phone as "incentive" to buy the paid version.
I could probably imagine other malicious uses of that feature if you need more proof that it's a bad idea.
Of course, there's nothing stopping the developer from releasing an update that makes the free app less functional/desirable.
As far as I know, the only way to tell what an update will be like without installing it is to look for App Market comments from disgruntled users who have installed the update. And you cannot return to a previous version of the application once an update is installed.
Several of the useful free apps that I have installed later became annoying, ad-supported ones.
What if, for example, I include by mistake confidential information that I am forced by law not to disclose, or media I don't have the proper copyright for?
For example, I make a statistical financial simulator for Android and by mistake the build includes my test data which is from some big bank ? Being able to pull the plug on that build would be really nice -- because I'm pretty sure nobody at Google would care to help you with that.
Or, I might do an audio player and I'm including some music whose copyright expired in the rest of the world, but not in US.
Indeed it might do more harm than good that normal developers have the right to do this, but if you assume developers are responsible about it, it might be a good thing. For example, Google could supervise this or charge a flat fee, etc.
Or don't include sensitive data in your test set or build system. If you include something in a release that you should not have included, then you are responsible full stop, and a revocation system is not a solution. This sort of functionality should not be used to fix developer mistakes; you can't do this sort of thing with desktop applications either, and once again, for good reason.
Even if Google initiates a mass revocation, that doesn't mean the application is no longer in the wild. Users who want to exploit your mistake could just as easily do one ogf the following:
- Disconnect their phone from a data connection or wifi signal
- Dump their current ROM/data to a backup image using a 3rd party bootloader
- Extract the .apk from the phone using root access, using an app like Titanium Backup
- Install the .apk from a source other than the Market, so that the revocation system will ignore it
Google's mass-revocation system only "works" because it is designed to remove malicious applications from the phones of unsuspecting users. If you make sensitive data public, it becomes public data, period; there's no going back.
Why should we treat the situation differently just because you distributed the application electronically, versus shipping it in the traditional/literal sense on CD-Rom or floppies?
If you wrote an application that contained (say) code that wasn't yours, and shipped a few thousand copies before anyone caught on, well you'd be S.O.L. I'd imagine that the damages you'd be responsible for would depend in some way on the number of copies that made it out the door.
But I don't see any reason why a developer ought to be able to conduct a sort of clawback to cover their own ass if they let something out the door that they shouldn't have.
Let's see, Amazon pulled back 1984 because they figured out they didn't have the license for it. They returned the money and fixed the problem without fuss (kinda).
If you were in a situation like you said to unknowingly include unlicensed 3rd party code it sure would be nice to just return the money and do a remote delete. Compared to, say, waiting to be sued and having the damages determined upon the numbers of copies sold.
If I've downloaded a free app, and the developer decides he wants money instead, I don't want him having the power to forcibly uninstall the free app from my phone as "incentive" to buy the paid version.
I could probably imagine other malicious uses of that feature if you need more proof that it's a bad idea.