Another intentionally crippled API in Android wouldn't exactly be surprising. I run into them all the time as a developer.
The initial SDKs had an awesome XMPP implementation that made communicating with programs on other phones incredibly easy. A program could even be started remotely to add a status bar notification that someone is challenging you in a multiplayer game you both have installed, for example. Now there's no public XMPP API at all and you have to include a less integrated Smack API JAR provided by the community. This uses up a lot of the very small amount of data storage space for installing applications and requires you to query the user for user and password information the phone already has anyway. Needless to say the issue thread for this is full of developers complaining and detailing how badly it impacts them and Google doesn't care.
Similarly, earlier versions of Android exposed some great APIs for searching for nearby businesses. For example, you could find all pizza places near the user and do something cool with that information in your application. The classes that allowed this were com.google.googlenav.Search and com.google.android.location.GmmGeocoder, but are now inaccesibe. The public GeoCoder class is useless for this. Developers are forced to call the Maps web service, handle all the potential problems and resource issues of opening HTTP connections, and parse XML results when this functionality is already completely written, just no longer exposed. The built in Maps application does this, so Google probably wants to prevent developers from being able to do the same easily.
I suppose it is a lot like how Apple rejects apps that "duplicate functionality". Google is trying to cripple third party developers in the same manner, they just do it at the API level.
Is it that, or that there are political reasons behind their choice? Anything that can push to phones is an SMS killer, for instance.
I don't think they're actually so concerned about crippling developers as trying to get people to ship real phones, and they won't do that if the phones make it really easy to get around high margin stuff like SMS's, unfortunately.
I see no difference... it's two sides of the same coin.
Are they intentionally screwing developers' access to APIs to prevent competition to their own apps? or are they limiting the APIs to ensure revenue streams for telcos, to ensure the platform lives on.
Both are business decisions (and therefore always justifiable), but neither are interesting to a hackers or a consumer. The latter two want the ability to do magical things, and can't.
If there are no phones with Android, it's not very useful, is it, no matter how open the API is? Of course I have no knowledge of what their internal discussions are like, but I think that's the compromise.
In a perfect world, we would have open platforms and open infrastructure to go along with open source. Just imagine: a hacker organized and run telecom ...
The initial SDKs had an awesome XMPP implementation that made communicating with programs on other phones incredibly easy. A program could even be started remotely to add a status bar notification that someone is challenging you in a multiplayer game you both have installed, for example. Now there's no public XMPP API at all and you have to include a less integrated Smack API JAR provided by the community. This uses up a lot of the very small amount of data storage space for installing applications and requires you to query the user for user and password information the phone already has anyway. Needless to say the issue thread for this is full of developers complaining and detailing how badly it impacts them and Google doesn't care.
Similarly, earlier versions of Android exposed some great APIs for searching for nearby businesses. For example, you could find all pizza places near the user and do something cool with that information in your application. The classes that allowed this were com.google.googlenav.Search and com.google.android.location.GmmGeocoder, but are now inaccesibe. The public GeoCoder class is useless for this. Developers are forced to call the Maps web service, handle all the potential problems and resource issues of opening HTTP connections, and parse XML results when this functionality is already completely written, just no longer exposed. The built in Maps application does this, so Google probably wants to prevent developers from being able to do the same easily.
I suppose it is a lot like how Apple rejects apps that "duplicate functionality". Google is trying to cripple third party developers in the same manner, they just do it at the API level.