SMS and other app-related APIs (e-mail etc) are outside of my area of responsibility (which is the core platform). Generally though these things aren't exposed because the people responsible for them aren't ready to commit to an API they will maintain and have other higher priorities they need to deal with than implementing such an API.
Saying "it is extremely simple to do" does not make it so. :) No API is extremely simple, just because along with it you have to account for documentation, QA, CTS tests, and the need to maintain compatibility with it for many years in the future. On Thu, May 26, 2011 at 1:03 PM, Ali Chousein <[email protected]>wrote: > Dianne, talking about limitations, as a developer I'm not happy at all > with the fact that Android does not support an official interface for > reading SMS messages (simple, the ones that you've received and sent) > and e-mails. I don't understand why the Android designers didn't > include this in the official interface, because it is something > extremely simple to do. A developer who is interested to write an app > which works with SMS mesages and e-mails has to dig into the code of > Android to find out how to do it. However, there is no backward > compatibility guarantee in this approach. I don't know if iOS supports > this, but my impression from discussion platforms is that many > developers are interested in this functionality. > > -Ali > > > On May 26, 9:16 pm, Dianne Hackborn <[email protected]> wrote: > > On Wed, May 25, 2011 at 9:39 PM, Chris Stratton <[email protected]> > wrote: > > > On Wednesday, May 25, 2011 6:14:55 PM UTC-4, Dianne Hackborn wrote: > > > > >> I'm still wondering what these "limiting decisions" are. > > > > > I find that surprising, considering the amount of time you spend > explaining > > > to people that the things they want to do are not possible, some > because > > > they are not yet supported and others because your team intentionally > chose > > > to preclude any means for a user to authorize an application to do > that. > > > Frankly I would agree some of the things people want to do are really > bad > > > ideas; but others a quite good ideas - the point is that this is a > > > subjective decision. Your team made its choices, but a lot of people > > > disagree with you about what should or shouldn't be allowed or > supported, > > > and Android has not in the past been readily suitable for doing things > > > outside of it's architects' vision. Fortunately, the theoretical > > > possibility of producing one's own build is increasingly becoming a > > > well-organized reality of alternative distributions - changing "one > little > > > thing" no longer means going it alone. Projects that weren't worth > doing > > > when there was no base of devices capable of using them become worth > doing > > > when the installed base of alternative builds grows. > > > > I think you are using "limiting decisions" in a way different than DanH. > > What you are talking about here a simply policy decisions about what > > applications will be allowed to do. They are nothing the platform is > tied > > to -- they can always be changed in the next release if there is a > > compelling reason to do so. (As I said, from a platform maintenance > > perspective it is *much* easier to remove restrictions on what > applications > > can do than it is to enforce new ones.) > > > > The vast majority of limitations on applications (beyond what people > coming > > from desktop operating systems expect) are there either because there is > a > > compelling benefit for the overall platform or ecosystem for them to be > > there, and/or there has not yet been time to design and implement a > facility > > for apps to use that is robust and maintainable for many years to come. > > > > But again, these have little do to with whether android has "legs" which > was > > the original point of discussion. > > > > Let's take one of the limitations that comes up -- being able to > intercept > > input events before they go to other applications. If we find ourselves > in > > a situation where another platform has such a facility, and has allowed > some > > developers to write extremely compelling applications that aren't > possible > > on android, and this is threatening android's viability in the market, it > > would be fairly trivial to add such a facility to android. It was > actually > > much harder to design and implement android to have the restriction than > to > > not have it. > > > > That said, this is something we would 99% positively never just open up, > > because it would have many negative impacts across the platform. > > > > And consider it from the other direction -- if your platform already > allows > > applications to freely intercept input events from other apps, and you > find > > this is actually harming your platform, how do you fix it? That's a > > *really* hard problem, especially if you don't want to break a bunch of > > third party apps. (And when it comes to third party apps, you will often > > find them relying on this kind of stuff in places you never think they > would > > have.) > > > > In fact this has been an issue for Windows. For example to implement the > > UAC dialog in a way that it can be sure the user is interacting with it > and > > not some app, one of the things it does is switch to a completely > different > > user environment in which the dialog is run, with a screenshot of the > > previous screen shown behind it to make it feel more integrated. > > > > So Android can actually implement a much cleaner and integrated > experience > > with the user because of this limitation it places on apps. More than > that, > > *apps* themselves can implement such interactions with users. Thus, as > not > > infrequently happens, imposing a limitation on what applications can do > > actually opens the door for other things. > > > > > I think we are coming out of the most limiting period as official > builds > > > are enhanced and alternative builds gain a following on a wide variety > of > > > devices, but a lot of things that we expected would be possible with a > > > "pocket linux box" have historically not been possible with android > devices, > > > for reasons ranging from the java-apis-first decision to the inability > of a > > > user to alter the security model. > > > > Yes if you want Android to be a "pocket linux box," that is not what it > is. > > That really is a different product, and as the example I give above > shows, > > making such a product is most likely going to be done at the detriment to > > many good things android provides. > > > > > It probably is worth looking at that subject of security for a minute. > By > > > not giving the user any real ability to customize or exert fine grained > > > control, a given user cannot make their device less secure than the > default, > > > but neither can they make it any more secure than a default they may > find > > > quite inadequate. In an official build, I cannot for example decide > that > > > it's okay for an application to know if I am on the phone, but not okay > for > > > it to be able to discover my phone number. > > > > I certainly agree that this particular permission was poorly done. This > is > > a good example of where giving apps too much access bites us. I think > there > > has been some ongoing work to split those pieces of information apart, > > because clearly access to personal information is a big and growing > concern. > > > > These kinds of things have only served to reinforce my feeling that > limiting > > what applications as much as possible should be the first design > priority. > > :) > > > > -- > > Dianne Hackborn > > Android framework engineer > > [email protected] > > > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
