|
 |
From: hackbod <hack...@gmail.com>
Date: Wed, 22 Oct 2008 00:40:45 -0700 (PDT)
Local: Wed, Oct 22 2008 3:40 am
Subject: Re: Android Source Code Now Available
On Oct 22, 12:15 am, tauntz <tau...@gmail.com> wrote:
> I think I have a wrong understanding of SYSTEM and APPLICATIONS then :/
I already explained this in the rest of my previous reply. Yes, many
> 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
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
> Sure, I understand why you don't give the same permissions to third
It IS the choice of the user about what apps he wants to install. If
> 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) 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
Any APIs that have been hidden in the SDK have been explicitly done so
> 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
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
We have NEVER said an application can do anything. I have posted
> > 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. 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
This will probably never be completely the case, because again this is
> sometime in the future all apps will truly be equal (: 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 must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||