Viva 'la Android!
Just a note about the release:
This source code (looking at tag android-1.0 or head release-1.0) is
clearly not the one that the 1.0r1 SDK uses. There are countless
methods/classes in the source that are not present in the 1.0r1 SDK
release (for example:
So that leads me to the following questions:
1) what version of the code (1.0r1 or the one that was just released
or some other variant) is on the G1?
2) when will we have access to the new SDK? (yes, I know I could
compile it myself from the source but I'm talking about compiled
binaries on http://code.google.com/android/download.html)
Would it be imaginable that (some time in the future) all non-public
APIs are in the com.google* domain and not in the same domain as all
the public classes (android.*)?
Currently it's a little confusing if I look at the source of some
Google app and see that it uses (for example) the method
lookupProviderCategoryFromId(..) from the class
android.provider.Contacts.ContactMethods. Now the public API has a
class with the exact same name and package but without the method that
Google uses so I always have to manually check if a method or constant
exists in the public API documentation when looking through the source
code (and after that I have to check if it also exists in the real SDK
since the SDK and the API documentation are also not the same). It
would be much easier if public and non-public stuff is in separate
packages (like com.sun.* in instead of java.* (J2SE)).
Just my 2 cents..
And congrats again to the team! :)
And further than that, people writing third party applications MUST
develop them against the SDK, not against the open source release.
Otherwise you can easily use non-public APIs, and thus break in a
Just out of interest, do you have an offline API checker app that could,
say, be run against applications before they get uploaded to the App
Store? Or possibly that could be run as part of the upload process?
It's conceivable it might be useful to have the *phones themselves*
verify the app before installing them, too.
(I'm thinking here of the ghastly mess Java ME is in where applications
will either work, not work, randomly crash, or crash the phone,
depending on which private APIs they're using. If there was a way of
getting the phone to at least *warn me* if I was installing a dodgy app
I'd be rather happy.)
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ --- Conway's Game Of Life, in one line of APL
Yes, but I'm more interested in making sure that *other people's*
applications aren't doing anything they shouldn't be.
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
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.
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) 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.
>> Would it be imaginable that (some time in the future) all non-public
>> APIs are in the com.google* domain and not in the same domain as all
>> the public classes (android.*)?
> We have been migrating private APIs to the com.android.internal
> packages, but it will NEVER be the case that everything under
> android.* is public. Never, ever. Just link to the SDK, which is
> guaranteed to only contain the supported public APIs, and you are
Nice to hear that you are cleaning the house (:
>> Currently it's a little confusing if I look at the source of some
>> Google app and see that it uses (for example) the method
>> lookupProviderCategoryFromId(..) from the class
>> android.provider.Contacts.ContactMethods. Now the public API has a
>> class with the exact same name and package but without the method that
>> Google uses so I always have to manually check if a method or constant
>> exists in the public API documentation when looking through the source
>> code (and after that I have to check if it also exists in the real SDK
>> since the SDK and the API documentation are also not the same). It
>> would be much easier if public and non-public stuff is in separate
>> packages (like com.sun.* in instead of java.* (J2SE)).
> Yes, a lot of the bundle apps shipped with the system are using
> private APIs, and this needs to be cleaned up. This is mostly an
> artifact of the apps being developed in parallel with the platform for
> the last 2-3 years, and not having time to do a final cleanup of them
> to switch to the public APIs. This is something that needs to be
> 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
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 (:
And again, I'm sorry if I sound offensive or whiney.. I'm trying not
to be. We all have the same common goal here - you want to make the
best mobile OS and we want to develop for the best mobile OS (;
(Ok, this should go to the discuss list but since it started here I'll
post this also here.)
Although the Android doesn't force users to use Marketplace can you why,
from a usability and functionality perspective, Marketplace already has
an unfair advantage that can only be levelled by using non-public APIs,
and hence why all the time bundled apps such as Marketplace uses
non-public APIs other apps will do so?
Wooooaaahhhhhh...... Since when has installing apps without user
intervention been a good thing?, and if it is a good thing why is it
reserved for Googles apps?
I'm sure most app developers would LOVE to be able to install updates
without having to force the user through the same permission set
agreements each time the user gets a new version.
It sounds like Android, at the moment, is heading for the same path.
My main concern is that Marketplace seems to be an obvious example of
where a bundled app is getting an unfair advantage just because it's an
approved application. This would also extend to diallers, from what
hackbod has said it would appear that any dialler written by a third
party won't be able to call emergency services, which is kind of crazy.
imho, on an open platform all apps should be equal.