We can't give you a complete list of everything you can't do. Yes there are some permission definitions in the SDK that really shouldn't be; these were missed when we were doing cleanup of the APIs, which is unfortunate, but they really don't hurt anything (it's just a string constant) so they still haven't been cleaned up.
If you are wondering about some facility you see a permission for, but no SDK API: first you can pretty much assume there is some code in the system that does that, but no API (yet) available; second, as you said, a Google search will probably turn up the official explanation of what is going on, if there is one; third, you have the FULL source code available to you, to find out about these things if you want. For example, there is an android.bluetooth package you can easily find in the source tree: http://android.git.kernel.org/?p=platform/frameworks/base.git;a=tree;f=core/java/android/bluetooth;h=4a09a9d3698c7374b0f54d43c3325951951a7748;hb=HEAD As far as when things will be available, the current official roadmap is here: http://source.android.com/roadmap On Mon, Mar 16, 2009 at 9:34 AM, brian.schim...@googlemail.com < brian.schim...@googlemail.com> wrote: > > Thank you for your answers so far, but I still think you're getting me > wrong. > > I'm not planing to use private APIs - at least not as long as they > remain private. I'm trying to create high quality software and I know > that hacking won't get me there. > > But it would be nice if Google (or the Open Handset Alliance as a > whole) would have some more trust in developers. Of course, the list > which I proposed could encourage some more developers to use those > APIs when they should not do it. But even as a righteous software > developer, with no plans whatsoever to actually abuse those APIs, I > would really benefit from candid information about them. > > Lets say I want my Application to search other bluetooth enabled > devices: I look into the public API, search for "bluetooth" and see > there is a permission called "BLUETOOTH_ADMIN" which sais "Allows > applications to discover and pair bluetooth devices.". Enough of a > evidence that it should be possible, but I just can't figure out how > to actually do it. So I'm just using a plain old google search on the > web and what do I find? Well, if I do it now, I find some blog posts > telling me that the bluetooth APIs were dropped from 0.9 to 1.0, but > when I did this search some months ago, when 1.0 was already there, > but blogs were too slow to pick up the topic, all I could find were > code examples written againt the 0.9 SDK that strengthened my belief > that it was possible - of course they did not actually state that they > were written for 0.9, I found this out the hard way. > > So the basic problem is, there are many indications telling me that my > App could do something: > * Permissions left over from old API revisions > * code examples (of coude inofficial ones) that target old SDKs or > use hacks to access the private APIs on current versions > * the official page at http://www.android.com/about/ telling that: > > Android does not differentiate between the phone's core applications > > and third-party applications. They can all be built to have equal > > access to a phone's capabilities providing users with a broad > > spectrum of applications and services. With devices built on the > > Android Platform, users are able to fully tailor the phone to their > > interests. They can swap out the phone's homescreen, the style > > of the dialer, or any of the applications. > > On the other hand, there are only few sources of information telling > me what is not possible or not public: > * blog posts (but only for very popular APIs, and all we know blogs > about Android are full of misinformation) > * changelogs (only if the API was public before, because if it's > private from the beginning, there's no change) > * or may be no information at all > > All I'm asking for is a simple place to go to and just have it clear: > "No, Brian, you cannot search for other bluetooth devices, this is a > private API, and you know what it means: Don't even think about using > it". Maybe that's bad news for me, but I can stomach that, I'd be glad > to find that information from a trusted source, e.g. directly from > you. In my opinion, that's what a developer might expect to find. I'm > not talking about "No, Brian, there is no public API to brew coffee on > android" because that's obvious. Just talking about the many cases > where developers have some good reason to believe a feature was > available when in fact it is not. > > Especially for bluetooth I know that it's private because it simply > wasn't final when 1.0 came out. But I was surprised when 1.1 came > without bluetooth, and I'm wondering if it will be in 1.2 or 1.3 or if > it was simply kicked out of the schedule forever. But I'm not looking > for a concrete answer to that specific question (If I was, I would > have asked it right away) but I'm trying to understand (and maybe > change) the way you are dealing with information about private APIs. > > If developers knew that you might release a new, final, pulic API for > bluetooth very soon, it might as well stop them from using the private > API now. But if they don't have information about it, I can understand > they will resort to the only obvious alternative: using private APIs. > Think about it, please. > > Sorry for the lenghty discussion, > Brian > > On 14 Mrz., 00:47, Dianne Hackborn <hack...@android.com> wrote: > > Don't use private APIs. Seriously. Your app will break at some point > when > > your users get a new version of the OS. > > > > In the vast majority of the cases where the built-in apps are using a > > private API, there is in fact a public API they can use to do the same > > thing. In the few cases where there isn't a public API, it is because > that > > part of the platform is not ready to be stabiliized for public use, so > that > > is very very likely something that will change in the future and bite you > in > > the butt if you are using it. > > > > (And of course there are the set of APIs that simply are not for > > applications to use, for security reasons, and most of those should > already > > be protected by permissions so even the private API won't do you any > good.) > > > > > > > > On Fri, Mar 13, 2009 at 4:20 PM, <mark.ka...@gmail.com> wrote: > > > > > On Android, All apps are created equal but some are equal than > > > others... You can replicate most of the functionality of the built in > > > apps by using internal classes, that do not ship as part of the SDK. > > > The only exception I've found is that some classes require you to have > > > the same process id and signature as the internal apps. You'll need > > > to grab the source or class files from the repository, and you'll have > > > to go through the process of building your application referencing > > > these classes. There is no documentation or support for this. I have > > > duplicated quite a few functions of the built in apps using this > > > technique. This is however not officially supported, and is hacking. > > > Not rare, but serious side effects may result. It can be done, but is > > > an advanced topic... I've had pretty good luck so far in duplicating > > > the functionalities of some of the built in apps, but I consider > > > myself an experienced device developer and hacker, not everyone will > > > have as good of luck I suppose. > > > > > On Mar 13, 8:38 am, Romain Guy <romain...@google.com> wrote: > > > > > Does this mean those APIs, e.g. reading contacts, will be made a > > > > > "public" part of the SDK? > > > > > > Reading contacts is already part of the public APIs. > > > > > > > * No, there is no such list. > > > > > > No, there is no such list and we won't offer one. > > > > > > > Please understand my point of view: I understand that there is a > > > > > reason to have private APIs. I just don't understand why this > should > > > > > be kept secret. > > > > > > They're not private: you can grab the source code and find them in > > > > there. But developers are already wrongly using those APIs and > > > > producing such a list would only encourage the use of private APIs. > It > > > > will only cause problems and there is absolutely no good reason to do > > > > so. You have a list of public APIs, if something you want to do is > not > > > > possible with these APIs, then you cannot do it. You are welcome to > > > > submit patches (source.android.com) or file feature requests > > > > (b.android.com) though. > > > > > > -- > > > > Romain Guy > > > > Android framework engineer > > > > romain...@android.com > > > > > > Note: please don't send private questions to me, as I don't have time > > > > to provide private support. All such questions should be posted on > > > > public forums, where I and others can see and answer them > > > > -- > > Dianne Hackborn > > Android framework engineer > > hack...@android.com > > > > Note: please don't send private questions to me, as I don't have time to > > provide private support. All such questions should be posted on public > > forums, where I and others can see and answer them. > > > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
