Thanks for clearing things up! :)
On Wed, Oct 22, 2008 at 10:40 AM, hackbod <[EMAIL PROTECTED]> wrote: > > On Oct 22, 12:15 am, tauntz <[EMAIL PROTECTED]> wrote: >> I think I have a wrong understanding of SYSTEM and APPLICATIONS then :/ >> I always thought that (for example) the Contacts thingie is an >> application and NOT a system component. But you are saying that these >> methods and classes are NOT for application use.. but the Contacts >> thingie uses them ergo the Contacts thingie is a system component and >> not an Application that is equal to all other apps that everybody else >> can create. >> >> One of Androids main promises is that "Any app on the mobile device >> can be replaced or extended -- even core components such as the dialer >> or home." Now word-for-word this holds true - I can replace the >> Contacts system component with a self-made Contacts application >> (AFAIK.. correct me if I'm wrong) but my replacement will always be >> inferior to the Google created one because it has no access to the >> various APIs that the Google created Contacts thingie has. > > I already explained this in the rest of my previous reply. Yes, many > of the current system applications use private APIs, because they have > been under development for a long time (well before the first SDK > release) in parallel with the platform, and it hasn't been possible to > keep them up on the official APIs as the platform was being cleaned > up. (Not to mention that we didn't even have a way to link against an > SDK that didn't contain private symbols until the 1.0 release, so it > is very easy to accidentally use private APIs.) > > There should be nothing the regular built-in apps do that you can't do > in your own apps, except for some carefully considered scenarios, such > as dialing an emergency phone number or directly installing an app > without user intervention. If you find something an app is doing that > you truly can't do with the SDK (not that it is just using some > convenience class that is part of the system that isn't ready for > public use), then please file a bug about it. Or hell, submit a patch > to make that feature available with a good SDK API. > >> Sure, I understand why you don't give the same permissions to third >> party apps like (for example) the Google marketplace has. (OK, in a >> perfect world it SHOULD be the users choice what apps he wants to >> install on his own phone.. and phone/OS manufacturers should not >> restrict his/her choice based on what they think the user wants) > > It IS the choice of the user about what apps he wants to install. If > you don't want to use the market, you can install them yourself with a > web browser or something else that invokes the system installer. This > is a non-issue. > >> But >> currently you are using some harmless private APIs in your own >> applications that ship with the device and denying access to the same >> functionality/integration to other apps. >> >> Don't get me wrong, I don't want to start a flamewar or anything like >> that. It's just that I want the same integration with the system as >> Google created applications have (to a reasonable extent of course.. >> I'm not talking about functionality that can compromise security etc). >> I hope that's not too much to ask. > > Any APIs that have been hidden in the SDK have been explicitly done so > because they will not be maintained in future releases. For the one > specific instance I think you have brought up -- groups in contacts -- > I am pretty sure this was a very last-minute addition, so we were able > to get the feature in to the 1.0 product but not in a way that could > be supported as part of the SDK. Doing a product presents these kinds > of challenges: do we do the feature but not make it available in the > SDK, or just not do the feature at all? I think it was much better to > have this feature for the product than not. There is nothing > malicious about this, it's just a simple fact that making something > that can be supported forever is a public API is usually a lot more > effort than just implementing the feature for internal use. > >> > Again, if you are doing third party app development, you really need >> > to be developing against the SDK. That is what it is there for. >> Finally.. someone from Google saying that not all apps are created >> equal. There are Google apps that can do whatever they want to do and >> then there are third party apps that can only do what Google allows >> them to do. And that's perfectly fine.. that's exactly how all other >> phone OSs work. It's just that some people have currently the wrong >> impression that you can create applications on Android that can do >> *anything* and if they see an application bundled with the system, >> they have the impression that they can have an app with the exact same >> functionality/system integration. > > We have NEVER said an application can do anything. I have posted > numerous times to this list that applications can't directly install > applications without going through the system UI, as well as not being > able to place emergency calls, not being able to replace the in-call > screen or lock screen, etc. The "apps are created equal" is a > fundamental design philosophy of the platform, when you can see > directly reflected in a lot of the ways the system is designed and how > UI flow works. We don't live in a perfect world, however, and for > practical reasons there are some limits on what we can do right now > today for 1.0. We haven't tried to hide these limitations, are not > doing this out of some self-centered desire to keep third party > applications down, and will continue to work to address those > limitations as we go forward. > >> It's good that you are trying to improve this and I'll hope that >> sometime in the future all apps will truly be equal (: > > This will probably never be completely the case, because again this is > not a perfect world. There will always be new features worked on, > which are desired for a particular release but not yet ready to be > supported as part of the SDK. That's just the way things are. > > > > --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
