Why is the Android Telephony API so limited (closed)?(blog.herlein.com)
blog.herlein.com
Why is the Android Telephony API so limited (closed)?
http://blog.herlein.com/2009/09/why-is-the-android-telephony-api-so-limited-closed/
3 comments
> Google doesn't care.
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.
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.
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 source code is all there, so he ought to look at it and see. That doesn't mean it's necessarily very easy to access, especially via the public API, but if he wants to know what it's actually doing, it should be visible at some level.
Edit: for example:
http://android.git.kernel.org/?p=platform/hardware/ril.git;a...
Edit: for example:
http://android.git.kernel.org/?p=platform/hardware/ril.git;a...
This sounds bazaar. So its not possible to access the audio in and out in android? It is 2am and I should be sleeping so maybe I read it wrong.
Android was on my to try list but this is a showstopper. Thanks for saving me some time.
Android was on my to try list but this is a showstopper. Thanks for saving me some time.
A little research reveals:
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.
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.
>Specifically for telephony, does one need something else?
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!
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!
Pretty insightful. Regarding the last part of your comment, I don't agree with the idea of using a developer certificate. In the case of malicious software, this only pushes the malicious developer into having to have their piece of software create maximum damage at once, since they will only get one shot at it. I like the current Android approach better: when you install an app, the phone lists all the pieces of functionality that the app will make use of. I assume this is done through a cursory source-code analysis but i'm not sure. This means that you can tell ahead of time if that app will be using your GPS sensor, or be sending SMS messages.
when you install an app, the phone lists all the pieces of functionality that the app will make use of. I assume this is done through a cursory source-code analysis but i'm not sure. This means that you can tell ahead of time if that app will be using your GPS sensor, or be sending SMS messages.
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.
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.
This is true, though it is possible for phones to check the certificate online at install time, so the app could potentially only affect phones up until the certificate is revoked then no more.
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.
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.
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.