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