Why is the Android Telephony API so limited (closed)?
blog.herlein.com
blog.herlein.com
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.
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.
Edit: for example:
http://android.git.kernel.org/?p=platform/hardware/ril.git;a...
Android was on my to try list but this is a showstopper. Thanks for saving me some time.
http://developer.android.com/reference/android/media/AudioTr... -- supports both streaming and static playback modes, interfaced by writing bytes
http://developer.android.com/reference/android/media/AudioRe... -- interfaced by reading bytes.
Specifically for telephony, does one need something else?
If you want to make a phone call, you can ask the device to dial a number. If it's possible to be in a phone call and, for example, record it by reading the same samples using this AudioRecord API, I don't know. There is an app called CallRecorder ($3.99) which claims to be able to record both incoming and outgoing calls, so it seems possible.
Often, yes. Device manufacturers and operators have traditionally been very cautious of allowing low level access to telephony APIs. For instance, getting access to the audio uplink and downlink of a GSM conversation is quite tricky (often impossible) on other platforms, so if it is possible on a real Android device as you indicate then that is a big win. If you get the downlink then you can record calls - not something that everyone wants, but something that certain industries view as essential, e.g. for recording of financial transactions made via a mobile phone. If you get access to the uplink, then you can mix audio into the call. For instance you could make a voicemail system that sits entirely on the phone itself, answering calls and playing messages to callers (when you're in coverage anyway!).
With Nokia's Symbian based phones, it is a constant game of cat and mouse to try and access these things, despite having paid partnering fees, making individual paid requests for APIs, and explaining the business case directly to Nokia. They told me directly that I can't have access to such things, and if I manage it today on certain phones with some creative engineering, then those loopholes will be closed in future. You'd think I was trying to harm their business, not create compelling applications that result in businesses buying more of their phones.
The status quo seems to be based on the assumption that every developer is an evil hacker intent on bringing down the network or sending millions of SMS messages to cost the end user money. To get round this, either you are forbidden from doing anything telephony related, or you have to put up a dialog and ask permission first ("The application wants to send an SMS message, is this ok?"). I have a simpler solution: in order to run software on most phones, I have to sign it with a paid certificate to say it came from my company. If I write harmful software, then revoke my certificate so it will no longer install and I can't distribute software any more. In the mean time, let me innovate, please!
You include the list of hardware capabilities your app needs to access in the manifest when you build your app -- the app can't access things it has not asserted it needs (I had trouble with this initially when writing an app to use GPS, as I had the name of the GPS service wrong in the manifest), and that list is what is displayed when the app is installed.
Also, I had to go through a number of hoops to get the certificate in the first place - proving that I was a registered company, handing over a chunk of cash etc. That has to be pretty off putting for a malicious coder.
Its even simpler with an app store model: if the app misbehaves or is misleading then it can be downvoted or even removed.