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