Live data from Hacker News

Why is the Android Telephony API so limited (closed)?

blog.herlein.com

11–13 of 13 posts

Re: Why is the Android Telephony API so limited (closed)?

#11
post #3

Earlier quoted context omitted.

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 t…

>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…

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.

Re: Why is the Android Telephony API so limited (closed)?

#12
post #11

Earlier quoted context omitted.

>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…

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 fun…

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.

Re: Why is the Android Telephony API so limited (closed)?

#13
post #11

Earlier quoted context omitted.

>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…

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 fun…

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.

Post reply on HN