

Why is the Android Telephony API so limited (closed)? - gherlein
http://blog.herlein.com/2009/09/why-is-the-android-telephony-api-so-limited-closed/

======
desiderata
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.

~~~
davidw
> 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.

~~~
furyg3
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.

~~~
davidw
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.

------
davidw
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...](http://android.git.kernel.org/?p=platform/hardware/ril.git;a=blob;f=libril/ril_commands.h;h=de82e70829f5122b2f100a8a824d6bbe089bbae2;hb=HEAD)

------
Caligula
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.

~~~
thwarted
A little research reveals:

[http://developer.android.com/reference/android/media/AudioTr...](http://developer.android.com/reference/android/media/AudioTrack.html)
\-- supports both streaming and static playback modes, interfaced by writing
bytes

[http://developer.android.com/reference/android/media/AudioRe...](http://developer.android.com/reference/android/media/AudioRecord.html)
\-- 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.

~~~
charltones
>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!

~~~
loginx
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.

~~~
thwarted
_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.

