I see that there is an "android.permission.GET_ACCOUNTS" permission, but there is not
currently any ACCOUNTS_SERVICE constant for the Context.getSystemService() method. 
Any idea when that will be available via the API?

Thanks,
Eric

Can I get a Googler to comment on whether this will even be allowed (in a future
release)?

(No comment was entered for this change.)

I too am looking for a solution to this.

The end result I need is just a unique identifier for a user.
A process that is repeatable, and produces the same identifier for the same user, no
matter what the device / hardware.

Any comment from a google representative?

With most phone SDKs, there is no way to uniquely identify a user regardless of
switching phones.  It is usually necessary to require a username/password.  Uniquely
identifying the user otherwise is a nightmare on the backend for other SDKs (BREW,
JavaME, etc.).

In order to use the Android phone, it requires you to get a gmail account, so it
would be nice if we could use that as a unique identifier of some sort. (Will still
need to require a password login for security reasons).

I second (third or fourth?) having access to the account information (minus password).

Any progress on this topic within the cupcake release?

I'm working on integrating the client.jar file found in
http://android.git.kernel.org/?p=platform/frameworks/opt/com.google.android.googlelogin.git;a=tree
in my application, but haven't actually succeeded yet.

Thanks,
Eric

You'll have to wait until they allow us to hook into the GoogleApps application that
is already running. This is the program that stores the SID that has already been
grabbed. Though as of now there is no way to access it.

Version 1.5 of the SDK is out now and it still appears that there is still no way to 
access the user's Google data (docs, contacts, calendar, etc.) without requiring them 
to sign-in to your application separately.

I'm starting to think that someone should make a generic "Google authenticator" 
application and then all of us other developers can just use that (via intents) to get 
the credentials.  That way the user only has to sign-in twice (once for Google and 
again for the rest of us).  Seems silly that Google doesn't just give us the user's 
token in the first place since as it is we can still get them (from the user) but it's 
a big pain.

As far as security is concerned, just have a generic activity pop-up the first time an 
application asks for the token.  That way the user knows the application is gaining 
access to their Google data and can reject it at that time if they please.  If they 
accept, then from then on that application will have access to the user's Google 
account.  You could take this a step further and allow the user 3 options, accept 
always, accept once and reject.  Even more you could have a UI in the system settings 
for managing the list of applications that have access to the user's Google Account.

good idea micahc.  I second the motion.

I've given up on trying to get the SID from Android.  Using the classes from the JAR
file I mention in comment #7, I was able to verify that the GoogleLoginService is
running, but the service is never bound (nor is any type of error thrown). I believe
the GoogleAppsVerifier class blocks all requests to bind to this class, even if you
have the right permissions defined in your manifest file, unless the application has
been signed by Google's keystore.

I'm disappointed that I have to continue to ask users of my application to enter
their Google email address and password directly in my application.  I would think
that Google would consider that to be a larger security risk than giving developers
access to the authentication token.

I think that an intent would be a nice interface. 
We apps launch the intent. The user gets asked if s/he wants to share the
authentication with the asking app – this guard question is managed by Google code –
and when s/he says "ok" then the activity result is the SID.

Intent resulting in standard screen with request "Allow application XXX to use your 
current Google ID (YYY)" Yes/Always/No/Never will be quite usable both for user and 
the developer.

"SU request" is an example on handling this in such way.

(No comment was entered for this change.)

 Issue 2869  has been merged into this issue.

(No comment was entered for this change.)

Also, it would be great if the intent-based-authentication would not be global for
the whole Google world, but 
could be restricted to domains, e.g. Google Reader only.

a quote from an other discussion :

I think i've a better idea (for google) :

- to access to a "complex website with API" (google, facebook,
hotmail) you need to install an "API app" on your phone (for each
"website")
- installing an "API app" installs also new "android api permission"
   examples of "API app" and "android api permissions" :
   google : "access gmail" , "access calendar", "access greader",
"search on google"
   hotmail/microsoft : "access hotmail" , "search on bing"
   facebook : "contacts" , "wall" , "event", "notification"

but, it's just an idea :)

(sorry for my english)

Another way to do it would be to create an http client and web activity specifically
for Google services.  It would take care of the authentication and notify the user of
when a certain service was being accessed, allowing the user to accept, deny, or
accept always.  Just an idea.

Biggest hole in Android.  Quit ignoring the hard problems and get this solved, 
Google!  If the big G ever really wants devs to move to the rest of their infra for 
app creation (e.g., wave, gae, gdata, etc.) this stupid situation needs to get 
resolved. I will never ever ever ever enter my uname/pwd into a 3rd-party app, and 
neither will any other user that isn't an idiot.

Agreed that it's the biggest hole in the API.  I'm still at a loss as to why this 
wasn't one of the first things IN the API...  a company formed around web-based 
services, releases an API which for all intents (no pun intended) and purposes closes 
off the use of many of their services in third-party apps.  Sure, we can always ask 
the user for their credentials...and why not ask them for their credit card details 
and internet banking credentials while we're at it?

Honestly, I think this is indicative of a bigger problem.  It seems so obvious to me 
and many others that there are big opportunities being missed here.  Google are so 
well placed to take on the iPhone, but it's decisions like this which make me go and 
start reading the development docs on the Apple site.

Sorry, but doesn't google allow applications to get the oauth token by following
standard protocol.  Your application should not ever ask the user for confidential
information, but instead pass them to trusted Google servers to authenticate, the
result is a usable access token.

I am grateful that Google doesn't allow apps to just borrow access from other apps,
and based on the oauth protocol i don't even think that is possible.

SO I think you (commenters of this thread) should just read up on the google APIs and
do things the right, and trusted way.

@OlliTech:

"Your application should not ever ask the user for confidential
information, but instead pass them to trusted Google servers"

=> And how do I pass the user's credentials to a Google server without asking the
user for them ?


"i don't even think that is possible."

=> If it is not possible, how does the apps made by google (GMail, GTalk, Maps, Web
browser when browsing google web apps...) do it ?

As a user, I don't want to be putting my user details into something else every time
I use a third-party utility. I want third-party utilities to be able to use the same
mechanism Google's own products use to authenticate themselves - i.e. using the
details I put into the phone when I activated it!

I think OlliTech is saying to use something like
http://code.google.com/apis/accounts/docs/OAuthForInstalledApps.html - where you
replace step 7 with a redirect to something like myandroidapp://blah which then has
the oauth token on it.  You write an Intent filter in your app for this url and
capture the token.  I've done it, and it works, but the user experience ends up just
as bad as asking for the username/password directly in the app because the user has
to type their username and password into the web browser.

I'd rather have an app permission for 'google auth token' so I can send the user to
step 5 directly where they can grant access or deny without having to retype their
google account username and password.  They can then manage the oauth access from
their google account as they do now for other apps.  

Then if they want to deny access to an app, they revoke access from their google
account page, and do not have to change their password and reauth all other
applications since they only type in their password to a trusted google application
or website.

dherbst is 100% right! we should have a deny or allow button in our appz

It looks like the Android SDK 2.0 is prepared to fix this:
http://developer.android.com/reference/android/accounts/AccountManager.html

It all now depends on whether the Google Services will use this mechanism to share tokens.

Hi,

there seems to be a solution there (I didn't try it though)...

http://donpark.org/blog/2009/01/24/android-client-side-oauth