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