Android Source Code Now Available
Al Sutton
Timbobsteve
the entire OpenSource community. Today is a great day for developers who
enjoy freedom and developing with freedom in mind.
Viva 'la Android!
tauntz
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:
android.provider.Contacts.ContactMethods.lookupProviderCategoryFromId(..)
etc..)
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)
hackbod?
Tauno
Romain Guy
--
Romain Guy
www.curious-creature.org
hackbod
develop them against the SDK, not against the open source release.
Otherwise you can easily use non-public APIs, and thus break in a
future release.
On Oct 21, 10:14 am, "Romain Guy" <romain...@google.com> wrote:
> It is the same source code. The SDK contains only the public APIs.
>
>
>
> On Tue, Oct 21, 2008 at 10:12 AM, tauntz <tau...@gmail.com> wrote:
>
> > Good news! Congratulations Android team!
>
> > 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:
> > android.provider.Contacts.ContactMethods.lookupProviderCategoryFromId(..)
> > etc..)
>
> > 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
>
> > hackbod?
>
> > Tauno
Peli
Maybe I'm too hectic now so that I don't see it, but in which git
repository ( from http://android.kernel.org/ ) can I find the Java
classes?
For example, where can I find android.hardware.SensorManager.java?
(so far I could only find the low-level C-files in platform/hardware/
libhardware.git)
Peli
On Oct 21, 7:14 pm, "Romain Guy" <romain...@google.com> wrote:
> It is the same source code. The SDK contains only the public APIs.
>
>
>
> On Tue, Oct 21, 2008 at 10:12 AM, tauntz <tau...@gmail.com> wrote:
>
> > Good news! Congratulations Android team!
>
> > 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:
> > android.provider.Contacts.ContactMethods.lookupProviderCategoryFromId(..)
> > etc..)
>
> > 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
>
> > hackbod?
>
> > Tauno
Josh Roesslein
tauntz
applications only ;)
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! :)
Tauno
Romain Guy
point your IDE to this jar file for code completion, then you won't
have any trouble. The non-public APIs are identified with the @hide
annotation in the code.
--
Romain Guy
www.curious-creature.org
Zach Hobbs
http://git.source.android.com/?p=platform/packages/providers/MediaProvider.git;a=tree
This page can help you find what you're looking for also:
http://source.android.com/projects
--
Zach Hobbs
HelloAndroid.com
Android OS news, tutorials, downloads
AlfredBaudisch
Thanks again for the nice work Google.
Shane Isbell
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
future release.
Shane
Peli
com.android.providers.* and applications
com.android.*apps*
but where do I find the classes for
android.* ? (without "com." in front?)
Specifically, if someone could point me to
android.hardware.SensorManager.java, I'd be really greatful!
Peli
On Oct 21, 8:27 pm, Zach Hobbs <ho...@helloandroid.com> wrote:
> Everything in here:http://git.source.android.com/?p=platform/packages/providers/MediaPro...
> This page can help you find what you're looking for also:http://source.android.com/projects
>
> --
>
> Zach Hobbs
> HelloAndroid.com
> Android OS news, tutorials, downloads
>
> On Tuesday 21 October 2008 1:32:09 pm Peli wrote:
>
> > Hey, congratulations for going truly open source! I'm so excited!
>
> > Maybe I'm too hectic now so that I don't see it, but in which git
Romain Guy
Shane Isbell
Shane
Romain Guy
to change/disappear in the future and this will break the binary and
source compatibility if you use these APIs. Consider these APIs
private.
--
Romain Guy
www.curious-creature.org
Peli
hackbod
> Ok, understood, these methods are non-public and reserved for Google
> applications only ;)
use. This is because they are not stable and change across releases.
There may be some applications in the source tree using them, but
these applications are only shipped as part of the system image, so
that is okay. In other words, if you use private APIs, you can -only-
distribute the resulting app by having a carrier bundle it with a
phone.
> 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.*)?
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
good.
> 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)).
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
done.
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.
hackbod
> If these non-public APIs are open, I don't see any reason why we can't use
> them, as long as we peg our version of the application to the current G1
> distribution. That's how we have to do it in the Java ME space and I guess
> that's what Google is doing too.
the phone software is installed? Your app breaks. That sucks for
everyone.
David Given
[...]
> In other words, if you use private APIs, you can -only-
> distribute the resulting app by having a carrier bundle it with a
> phone.
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 ─────
│
│ ⍎'⎕',∊N⍴⊂S←'←⎕←(3=T)⋎M⋏2=T←⊃+/(V⌽"⊂M),(V⊝"M),(V,⌽V)⌽"(V,V←1⎺1)⊝"⊂M)'
│ --- Conway's Game Of Life, in one line of APL
Romain Guy
--
Romain Guy
www.curious-creature.org
David Given
> That's what the SDK is for. If your app compiles against the SDK, you're good.
Yes, but I'm more interested in making sure that *other people's*
applications aren't doing anything they shouldn't be.
Al Sutton
application directories with the same level of integration into the
phone as Marketplace has?
Al.
whitehexagon
fancy to install all these other tools just to browse the source code.
hackbod
> So is Google going to provide examples of how third parties can write
> application directories with the same level of integration into the
> phone as Marketplace has?
the direct call to install an app instead of going through the system
install UI, and all this does is allow it to do the permission
confirmation check before the user downloads an app instead of after.
The only reason why market can do this is because it is bundled as
part of the system image; if it wasn't, it wouldn't be able to do
that, and likewise if someone else has a carrier bundle their app with
a phone then they can do all of the same stuff.
Also the purpose here is not to give the Android Market a special
advantage, but to protect users: NO application installed as a third
party app can directly install other applications, because that would
effectively give it permission to everything in the world on the phone
(because it could just install another app with any permissions it
wants, with no confirmation by the user). We thought this was a
little too dangerous to allow, especially for the small benefit it
provides.
(Btw, Market -is- using some public APIs, in particular a download
manager, that are not yet available in the SDK. This is however
something you can write yourself, and it is also an API we plan to
make available to all apps in the future, we just didn't have time to
get it ready for 1.0.)
Ronnie
I dont care what Apple has to say about it, I have JailBreaked my
iPhone. bring it !! :)
tauntz
>
> On Oct 21, 11:10 am, tauntz <tau...@gmail.com> wrote:
>> Ok, understood, these methods are non-public and reserved for Google
>> applications only ;)
>
> NO. They are private to the SYSTEM. They are not for application
> use. This is because they are not stable and change across releases.
> There may be some applications in the source tree using them, but
> these applications are only shipped as part of the system image, so
> that is okay. In other words, if you use private APIs, you can -only-
> distribute the resulting app by having a carrier bundle it with a
> phone.
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.
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
> good.
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
> done.
>
> 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.
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.)
Tauno
Al Sutton
uninstall them either, which leads to the question; How do third party
app directories run their own kill-list?
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?
Al.
--
Al Sutton
W: www.alsutton.com
B: alsutton.wordpress.com
T: twitter.com/alsutton
hackbod
> 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.
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)
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.
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.
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 (:
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.
hackbod
> 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?
tricky. At this point, we think it is too dangerous to give a third
party application blanket access to install applications without the
user being involved. That may change in the future, but for now that
is the way it is. Yes, it means the Android Market app as a bundled
part of the system can do a little different UI flow than ones that
aren't bundled that way. Sorry, that's just how it is for now.
For uninstalling apps without the user's intervention, this is
something that would be a little less scary to allow, but we didn't
have time to look into this for 1.0.
Oh and fwiw, what you are talking about here has nothing to do with
private APIs. Yes, these APIs are not in the SDK, but even if they
were, you couldn't use them because they are protected by a permission
that you can only have granted to you if you are signed with the same
certificate as the core platform code.
Al Sutton
> 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.
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.
Al.
Al Sutton
releasing API details (here's a recent one
http://www.theregister.co.uk/2008/02/21/microsoft_goes_open/)
It sounds like Android, at the moment, is heading for the same path.
Al.
tauntz
Ewan Grantham
Al Sutton
platform" just to use a third party application installer and/or updater?
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.
Al.