> My phone didn't prompt me to allow access. I have seen that behaviour
> before though. Probably when I was hacking around with it a while ago.

> You might be right about the cert. I used the same one to sign both
> apps. I might try again with a different cert for each app.

> On Mar 4, 9:09 pm, Mariano Kamp <mariano.k...@gmail.com> wrote:
> > This whole Auth 2.0 thing is a total mess. Did you test it on Android
> 2.0.1
> > devices? It didn't crash for you there? Can you support hosted accounts?

> > I think I will give up on this until Google documents how to use their
> > implementation (the Google one, not the Android framework). There is just
> > already too much time sunk here.

> > Anyway, regarding your actual issue, did the Auth mechanism ask you twice
> to
> > allow access to the selected account? I am not quite sure how it
> determines
> > the caller, but maybe it might not be the calling app, but the
> certificate
> > it was signed with that makes the difference. Did you use the same
> > certificate to sign both apps?

> > On Thu, Mar 4, 2010 at 9:35 PM, ubikdroid <markst3v...@googlemail.com
> >wrote:

> > > I think I might have found an issue with using AccountManager in
> > > Android 2.x devices. I have 2 apps in the market that use Google
> > > Reader: Reader Widget Pro and Reader Widget Free. I was updating them
> > > both to use AccountManager and the new authentication method. I
> > > noticed that on my Nexus One when one application (say the Free one)
> > > obtained a token using AccountManager.getAuthToken() with the service
> > > set to "reader" the other app (say the Pro one) was unable to obtain a
> > > token afterwards. Even using AccountManager.invalidateAuthToken in the
> > > first app did not work. Sample code:

> > > AccountManagerFuture<Bundle> accFut =
> > > accountManager.getAuthToken(acct, "reader", false, null, null);
> > > try {
> > >        if(accFut != null && accFut.getResult() != null){
> > >                Bundle bundle = accFut.getResult();

> > >                authToken = bundle.getString("authtoken"); // This key
> is no
> > > longer
> > > in the bundle for the 2nd app
> > >        } else {
> > >                Log.e(TAG, "accFut null");
> > >        }
> > > } catch (OperationCanceledException e) {
> > >        e.printStackTrace();
> > > } catch (AuthenticatorException e) {
> > >        e.printStackTrace();
> > > } catch (IOException e) {
> > >        e.printStackTrace();
> > > }

> > > I don't know if this is supposed to happen but I will cross post this
> > > with the android dev google group. It could mean big problems if
> > > several apps are trying to get auth tokens for the same service on the
> > > same phone. One application could prevent others from working. I will
> > > stick to the old GoogleLoginServiceBlockingHelper method in my apps
> > > for now.

> > > On Feb 11, 9:03 am, ubikdroid <markst3v...@googlemail.com> wrote:
> > > > Thanks for the heads up Brad.
> > > > Can you answer these questions please?

> > > > 1.) Will there be an overlap where both the SID cookie and the new
> > > > header will work for authorization?

> > > > 2.) Can the auth token obtained from getCredentials() in Android be
> > > > used in this new header? Seehttp://
> > > groups.google.com/group/android-developers/browse_thread/threa...

> > > > 3.) Can the auth token obtained from AccountManager.getAccounts() in
> > > > Android 2.0+ be used in this new header? Seehttp://
> > > groups.google.com/group/android-developers/browse_thread/threa...

> > > > Thanks
> > > > Mark

> > > > On Feb 11, 12:12 am, Brad Hawkes <bhaw...@google.com> wrote:

> > > > > Hello friends,

> > > > > We just wanted to let you know about changes coming for Reader
> > > > > authentication. We will be changing the details for how our normal
> web-
> > > > > browsing experience handles authentication. This change will break
> > > > > clients that are based on using the SID cookie to communicate with
> > > > > Reader (this seems to be many current clients). To ensure that your
> > > > > app continues to be able to access Reader data you should
> transition
> > > > > to using ClientLogin to access Reader. This is the general
> mechanism
> > > > > that is preferred for communication with many Google services.
> Details
> > > > > of how to use ClientLogin, along with some libraries that are
> > > > > available:
> http://code.google.com/apis/gdata/docs/auth/clientlogin.html

> > > > > Here is a quick summary of how to make this change:
> > > > > For those apps that area already obtaining authentication
> fromhttps://
> > >www.google.com/accounts/ClientLoginyoushouldget back as
> > > > > part of your response an Auth= value. For every request you send to
> > > > > Reader you should provide that value as a HTTP header and things
> will
> > > > > work as usual.
> > > > > The header format is: Authorization:GoogleLogin auth=[value
> obtained
> > > > > from ClientLogin]

> > > > > Also please keep in mind that both SID cookies and Auth tokens do
> > > > > expire. You should store your Auth token, but if you start to get
> 401
> > > > > errors you may need to obtain a new Auth token. You should not do
> > > > > retries on 401 errors unless you have obtained a new Auth token.

> > > > > Thanks for your attention.

> > > > > Brad Hawkes
> > > > > Google Reader Team

> On Thu, Mar 4, 2010 at 10:24 PM, ubikdroid <markst3v...@googlemail.com>wrote:

>> Hi Mariano, I don't have an Android 2.0.1 device to test
>> unfortunately. Just my N1 and G1. I haven't tried hosted accounts.

>> My phone didn't prompt me to allow access. I have seen that behaviour
>> before though. Probably when I was hacking around with it a while ago.

>> You might be right about the cert. I used the same one to sign both
>> apps. I might try again with a different cert for each app.

>> On Mar 4, 9:09 pm, Mariano Kamp <mariano.k...@gmail.com> wrote:
>> > This whole Auth 2.0 thing is a total mess. Did you test it on Android
>> 2.0.1
>> > devices? It didn't crash for you there? Can you support hosted accounts?

>> > I think I will give up on this until Google documents how to use their
>> > implementation (the Google one, not the Android framework). There is
>> just
>> > already too much time sunk here.

>> > Anyway, regarding your actual issue, did the Auth mechanism ask you
>> twice to
>> > allow access to the selected account? I am not quite sure how it
>> determines
>> > the caller, but maybe it might not be the calling app, but the
>> certificate
>> > it was signed with that makes the difference. Did you use the same
>> > certificate to sign both apps?

>> > On Thu, Mar 4, 2010 at 9:35 PM, ubikdroid <markst3v...@googlemail.com
>> >wrote:

>> > > I think I might have found an issue with using AccountManager in
>> > > Android 2.x devices. I have 2 apps in the market that use Google
>> > > Reader: Reader Widget Pro and Reader Widget Free. I was updating them
>> > > both to use AccountManager and the new authentication method. I
>> > > noticed that on my Nexus One when one application (say the Free one)
>> > > obtained a token using AccountManager.getAuthToken() with the service
>> > > set to "reader" the other app (say the Pro one) was unable to obtain a
>> > > token afterwards. Even using AccountManager.invalidateAuthToken in the
>> > > first app did not work. Sample code:

>> > > AccountManagerFuture<Bundle> accFut =
>> > > accountManager.getAuthToken(acct, "reader", false, null, null);
>> > > try {
>> > >        if(accFut != null && accFut.getResult() != null){
>> > >                Bundle bundle = accFut.getResult();

>> > >                authToken = bundle.getString("authtoken"); // This key
>> is no
>> > > longer
>> > > in the bundle for the 2nd app
>> > >        } else {
>> > >                Log.e(TAG, "accFut null");
>> > >        }
>> > > } catch (OperationCanceledException e) {
>> > >        e.printStackTrace();
>> > > } catch (AuthenticatorException e) {
>> > >        e.printStackTrace();
>> > > } catch (IOException e) {
>> > >        e.printStackTrace();
>> > > }

>> > > I don't know if this is supposed to happen but I will cross post this
>> > > with the android dev google group. It could mean big problems if
>> > > several apps are trying to get auth tokens for the same service on the
>> > > same phone. One application could prevent others from working. I will
>> > > stick to the old GoogleLoginServiceBlockingHelper method in my apps
>> > > for now.

>> > > On Feb 11, 9:03 am, ubikdroid <markst3v...@googlemail.com> wrote:
>> > > > Thanks for the heads up Brad.
>> > > > Can you answer these questions please?

>> > > > 1.) Will there be an overlap where both the SID cookie and the new
>> > > > header will work for authorization?

>> > > > 2.) Can the auth token obtained from getCredentials() in Android be
>> > > > used in this new header? Seehttp://
>> > > groups.google.com/group/android-developers/browse_thread/threa...

>> > > > 3.) Can the auth token obtained from AccountManager.getAccounts() in
>> > > > Android 2.0+ be used in this new header? Seehttp://
>> > > groups.google.com/group/android-developers/browse_thread/threa...

>> > > > Thanks
>> > > > Mark

>> > > > On Feb 11, 12:12 am, Brad Hawkes <bhaw...@google.com> wrote:

>> > > > > Hello friends,

>> > > > > We just wanted to let you know about changes coming for Reader
>> > > > > authentication. We will be changing the details for how our normal
>> web-
>> > > > > browsing experience handles authentication. This change will break
>> > > > > clients that are based on using the SID cookie to communicate with
>> > > > > Reader (this seems to be many current clients). To ensure that
>> your
>> > > > > app continues to be able to access Reader data you should
>> transition
>> > > > > to using ClientLogin to access Reader. This is the general
>> mechanism
>> > > > > that is preferred for communication with many Google services.
>> Details
>> > > > > of how to use ClientLogin, along with some libraries that are
>> > > > > available:
>> http://code.google.com/apis/gdata/docs/auth/clientlogin.html

>> > > > > Here is a quick summary of how to make this change:
>> > > > > For those apps that area already obtaining authentication
>> fromhttps://
>> > >www.google.com/accounts/ClientLoginyoushouldget back as
>> > > > > part of your response an Auth= value. For every request you send
>> to
>> > > > > Reader you should provide that value as a HTTP header and things
>> will
>> > > > > work as usual.
>> > > > > The header format is: Authorization:GoogleLogin auth=[value
>> obtained
>> > > > > from ClientLogin]

>> > > > > Also please keep in mind that both SID cookies and Auth tokens do
>> > > > > expire. You should store your Auth token, but if you start to get
>> 401
>> > > > > errors you may need to obtain a new Auth token. You should not do
>> > > > > retries on 401 errors unless you have obtained a new Auth token.

>> > > > > Thanks for your attention.

>> > > > > Brad Hawkes
>> > > > > Google Reader Team

> I think I will give up on this until Google documents how to use their
> implementation (the Google one, not the Android framework). There is just
> already too much time sunk here.

> Anyway, regarding your actual issue, did the Auth mechanism ask you twice to
> allow access to the selected account? I am not quite sure how it determines
> the caller, but maybe it might not be the calling app, but the certificate
> it was signed with that makes the difference. Did you use the same
> certificate to sign both apps?

> On Thu, Mar 4, 2010 at 9:35 PM, ubikdroid <markst3v...@googlemail.com>wrote:

> > I think I might have found an issue with using AccountManager in
> > Android 2.x devices. I have 2 apps in the market that use Google
> > Reader: Reader Widget Pro and Reader Widget Free. I was updating them
> > both to use AccountManager and the new authentication method. I
> > noticed that on my Nexus One when one application (say the Free one)
> > obtained a token using AccountManager.getAuthToken() with the service
> > set to "reader" the other app (say the Pro one) was unable to obtain a
> > token afterwards. Even using AccountManager.invalidateAuthToken in the
> > first app did not work. Sample code:

> > AccountManagerFuture<Bundle> accFut =
> > accountManager.getAuthToken(acct, "reader", false, null, null);
> > try {
> >        if(accFut != null && accFut.getResult() != null){
> >                Bundle bundle = accFut.getResult();

> >                authToken = bundle.getString("authtoken"); // This key is no
> > longer
> > in the bundle for the 2nd app
> >        } else {
> >                Log.e(TAG, "accFut null");
> >        }
> > } catch (OperationCanceledException e) {
> >        e.printStackTrace();
> > } catch (AuthenticatorException e) {
> >        e.printStackTrace();
> > } catch (IOException e) {
> >        e.printStackTrace();
> > }

> > I don't know if this is supposed to happen but I will cross post this
> > with the android dev google group. It could mean big problems if
> > several apps are trying to get auth tokens for the same service on the
> > same phone. One application could prevent others from working. I will
> > stick to the old GoogleLoginServiceBlockingHelper method in my apps
> > for now.

> > On Feb 11, 9:03 am, ubikdroid <markst3v...@googlemail.com> wrote:
> > > Thanks for the heads up Brad.
> > > Can you answer these questions please?

> > > 1.) Will there be an overlap where both the SID cookie and the new
> > > header will work for authorization?

> > > 2.) Can the auth token obtained from getCredentials() in Android be
> > > used in this new header? Seehttp://
> > groups.google.com/group/android-developers/browse_thread/threa...

> > > 3.) Can the auth token obtained from AccountManager.getAccounts() in
> > > Android 2.0+ be used in this new header? Seehttp://
> > groups.google.com/group/android-developers/browse_thread/threa...

> > > Thanks
> > > Mark

> > > On Feb 11, 12:12 am, Brad Hawkes <bhaw...@google.com> wrote:

> > > > Hello friends,

> > > > We just wanted to let you know about changes coming for Reader
> > > > authentication. We will be changing the details for how our normal web-
> > > > browsing experience handles authentication. This change will break
> > > > clients that are based on using the SID cookie to communicate with
> > > > Reader (this seems to be many current clients). To ensure that your
> > > > app continues to be able to access Reader data you should transition
> > > > to using ClientLogin to access Reader. This is the general mechanism
> > > > that is preferred for communication with many Google services. Details
> > > > of how to use ClientLogin, along with some libraries that are
> > > > available:http://code.google.com/apis/gdata/docs/auth/clientlogin.html

> > > > Here is a quick summary of how to make this change:
> > > > For those apps that area already obtaining authentication fromhttps://
> >www.google.com/accounts/ClientLoginyoushouldget back as
> > > > part of your response an Auth= value. For every request you send to
> > > > Reader you should provide that value as a HTTP header and things will
> > > > work as usual.
> > > > The header format is: Authorization:GoogleLogin auth=[value obtained
> > > > from ClientLogin]

> > > > Also please keep in mind that both SID cookies and Auth tokens do
> > > > expire. You should store your Auth token, but if you start to get 401
> > > > errors you may need to obtain a new Auth token. You should not do
> > > > retries on 401 errors unless you have obtained a new Auth token.

> > > > Thanks for your attention.

> > > > Brad Hawkes
> > > > Google Reader Team

> On Thu, Mar 4, 2010 at 10:24 PM, ubikdroid <markst3v...@googlemail.com>wrote:

>> Hi Mariano, I don't have an Android 2.0.1 device to test
>> unfortunately. Just my N1 and G1. I haven't tried hosted accounts.

>> My phone didn't prompt me to allow access. I have seen that behaviour
>> before though. Probably when I was hacking around with it a while ago.

>> You might be right about the cert. I used the same one to sign both
>> apps. I might try again with a different cert for each app.

>> On Mar 4, 9:09 pm, Mariano Kamp <mariano.k...@gmail.com> wrote:
>> > This whole Auth 2.0 thing is a total mess. Did you test it on Android
>> 2.0.1
>> > devices? It didn't crash for you there? Can you support hosted accounts?

>> > I think I will give up on this until Google documents how to use their
>> > implementation (the Google one, not the Android framework). There is
>> just
>> > already too much time sunk here.

>> > Anyway, regarding your actual issue, did the Auth mechanism ask you
>> twice to
>> > allow access to the selected account? I am not quite sure how it
>> determines
>> > the caller, but maybe it might not be the calling app, but the
>> certificate
>> > it was signed with that makes the difference. Did you use the same
>> > certificate to sign both apps?

>> > On Thu, Mar 4, 2010 at 9:35 PM, ubikdroid <markst3v...@googlemail.com
>> >wrote:

>> > > I think I might have found an issue with using AccountManager in
>> > > Android 2.x devices. I have 2 apps in the market that use Google
>> > > Reader: Reader Widget Pro and Reader Widget Free. I was updating them
>> > > both to use AccountManager and the new authentication method. I
>> > > noticed that on my Nexus One when one application (say the Free one)
>> > > obtained a token using AccountManager.getAuthToken() with the service
>> > > set to "reader" the other app (say the Pro one) was unable to obtain a
>> > > token afterwards. Even using AccountManager.invalidateAuthToken in the
>> > > first app did not work. Sample code:

>> > > AccountManagerFuture<Bundle> accFut =
>> > > accountManager.getAuthToken(acct, "reader", false, null, null);
>> > > try {
>> > >        if(accFut != null && accFut.getResult() != null){
>> > >                Bundle bundle = accFut.getResult();

>> > >                authToken = bundle.getString("authtoken"); // This key
>> is no
>> > > longer
>> > > in the bundle for the 2nd app
>> > >        } else {
>> > >                Log.e(TAG, "accFut null");
>> > >        }
>> > > } catch (OperationCanceledException e) {
>> > >        e.printStackTrace();
>> > > } catch (AuthenticatorException e) {
>> > >        e.printStackTrace();
>> > > } catch (IOException e) {
>> > >        e.printStackTrace();
>> > > }

>> > > I don't know if this is supposed to happen but I will cross post this
>> > > with the android dev google group. It could mean big problems if
>> > > several apps are trying to get auth tokens for the same service on the
>> > > same phone. One application could prevent others from working. I will
>> > > stick to the old GoogleLoginServiceBlockingHelper method in my apps
>> > > for now.

>> > > On Feb 11, 9:03 am, ubikdroid <markst3v...@googlemail.com> wrote:
>> > > > Thanks for the heads up Brad.
>> > > > Can you answer these questions please?

>> > > > 1.) Will there be an overlap where both the SID cookie and the new
>> > > > header will work for authorization?

>> > > > 2.) Can the auth token obtained from getCredentials() in Android be
>> > > > used in this new header? Seehttp://
>> > > groups.google.com/group/android-developers/browse_thread/threa...

>> > > > 3.) Can the auth token obtained from AccountManager.getAccounts() in
>> > > > Android 2.0+ be used in this new header? Seehttp://
>> > > groups.google.com/group/android-developers/browse_thread/threa...

>> > > > Thanks
>> > > > Mark

>> > > > On Feb 11, 12:12 am, Brad Hawkes <bhaw...@google.com> wrote:

>> > > > > Hello friends,

>> > > > > We just wanted to let you know about changes coming for Reader
>> > > > > authentication. We will be changing the details for how our normal
>> web-
>> > > > > browsing experience handles authentication. This change will break
>> > > > > clients that are based on using the SID cookie to communicate with
>> > > > > Reader (this seems to be many current clients). To ensure that
>> your
>> > > > > app continues to be able to access Reader data you should
>> transition
>> > > > > to using ClientLogin to access Reader. This is the general
>> mechanism
>> > > > > that is preferred for communication with many Google services.
>> Details
>> > > > > of how to use ClientLogin, along with some libraries that are
>> > > > > available:
>> http://code.google.com/apis/gdata/docs/auth/clientlogin.html

>> > > > > Here is a quick summary of how to make this change:
>> > > > > For those apps that area already obtaining authentication
>> fromhttps://
>> > >www.google.com/accounts/ClientLoginyoushouldget back as
>> > > > > part of your response an Auth= value. For every request you send
>> to
>> > > > > Reader you should provide that value as a HTTP header and things
>> will
>> > > > > work as usual.
>> > > > > The header format is: Authorization:GoogleLogin auth=[value
>> obtained
>> > > > > from ClientLogin]

>> > > > > Also please keep in mind that both SID cookies and Auth tokens do
>> > > > > expire. You should store your Auth token, but if you start to get
>> 401
>> > > > > errors you may need to obtain a new Auth token. You should not do
>> > > > > retries on 401 errors unless you have obtained a new Auth token.

>> > > > > Thanks for your attention.

>> > > > > Brad Hawkes
>> > > > > Google Reader Team

> Stefan, I also tried yours 2.2..9 with the same effect that I see
> (afterward it seems to just hang "Retrieving Account Details") :

> V/BeyondPod( 2062): --- BeyondPod Global WiFi WakeLock released!  (21 ms.
> since last trace)   [BeyondPodApplication]
> D/dalvikvm( 1244): GC freed 8769 objects / 505928 bytes in 146ms
> E/WindowManager( 1170): Unknown window type: 2008
> I/ActivityManager( 1170): Starting activity: Intent {
> act=android.intent.action.MAIN flg=0x10100000
> cmp=mobi.beyondpod/.ui.views.Splash }
> D/dalvikvm( 1517): GC freed 2388 objects / 109448 bytes in 107ms
> W/ResourceType( 1230): No package identifier when getting name for resource
> number 0x00000000
> E/JavaBinder( 1230): *** Uncaught remote exception!  (Exceptions are not
> yet supported across processes.)
> E/JavaBinder( 1230): android.content.res.Resources$NotFoundException:
> String resource ID #0x0
> E/JavaBinder( 1230): at
> android.content.res.Resources.getText(Resources.java:200)
> E/JavaBinder( 1230): at
> android.content.res.Resources.getString(Resources.java:253)
> E/JavaBinder( 1230): at
> android.content.Context.getString(Context.java:149)
> E/JavaBinder( 1230): at
> com.google.android.googleapps.GoogleLoginService$AccountAuthenticatorImpl.g etAuthTokenLabel(GoogleLoginService.java:586)
> E/JavaBinder( 1230): at
> android.accounts.AbstractAccountAuthenticator$Transport.getAuthTokenLabel(A bstractAccountAuthenticator.java:155)
> E/JavaBinder( 1230): at
> android.accounts.IAccountAuthenticator$Stub.onTransact(IAccountAuthenticato r.java:123)
> E/JavaBinder( 1230): at android.os.Binder.execTransact(Binder.java:287)
> E/JavaBinder( 1230): at dalvik.system.NativeStart.run(Native Method)

> Guys, btw., your login integrations look really nice.

> Anyway, given that at least (2/3) of our implementations are also not
> working on Android 2.0, not for Google Apps accounts, not for re-login, to
> use them it was necessary to decompile proprietary Google classes to know
> what parameters too set, the Google provided GUIs look like prototypes and
> that there is absolutely zero documentation ... maybe it is a hint that
> despite the pressure to have such a solution, it is just not ready for prime
> time.

> Maybe Android 2.2 will be better and maybe there will be documentation or
> at least the officially open sourced Google provided apps (Contacts,
> Calendar, ...) will use the new API without relying on closed source bits.

> On Thu, Mar 4, 2010 at 10:26 PM, Mariano Kamp <mariano.k...@gmail.com>wrote:

>> I'll download your widget to a 2.0.1 widget tomorrow and feed back.

>> On Thu, Mar 4, 2010 at 10:24 PM, ubikdroid <markst3v...@googlemail.com>wrote:

>>> Hi Mariano, I don't have an Android 2.0.1 device to test
>>> unfortunately. Just my N1 and G1. I haven't tried hosted accounts.

>>> My phone didn't prompt me to allow access. I have seen that behaviour
>>> before though. Probably when I was hacking around with it a while ago.

>>> You might be right about the cert. I used the same one to sign both
>>> apps. I might try again with a different cert for each app.

>>> On Mar 4, 9:09 pm, Mariano Kamp <mariano.k...@gmail.com> wrote:
>>> > This whole Auth 2.0 thing is a total mess. Did you test it on Android
>>> 2.0.1
>>> > devices? It didn't crash for you there? Can you support hosted
>>> accounts?

>>> > I think I will give up on this until Google documents how to use their
>>> > implementation (the Google one, not the Android framework). There is
>>> just
>>> > already too much time sunk here.

>>> > Anyway, regarding your actual issue, did the Auth mechanism ask you
>>> twice to
>>> > allow access to the selected account? I am not quite sure how it
>>> determines
>>> > the caller, but maybe it might not be the calling app, but the
>>> certificate
>>> > it was signed with that makes the difference. Did you use the same
>>> > certificate to sign both apps?

>>> > On Thu, Mar 4, 2010 at 9:35 PM, ubikdroid <markst3v...@googlemail.com
>>> >wrote:

>>> > > I think I might have found an issue with using AccountManager in
>>> > > Android 2.x devices. I have 2 apps in the market that use Google
>>> > > Reader: Reader Widget Pro and Reader Widget Free. I was updating them
>>> > > both to use AccountManager and the new authentication method. I
>>> > > noticed that on my Nexus One when one application (say the Free one)
>>> > > obtained a token using AccountManager.getAuthToken() with the service
>>> > > set to "reader" the other app (say the Pro one) was unable to obtain
>>> a
>>> > > token afterwards. Even using AccountManager.invalidateAuthToken in
>>> the
>>> > > first app did not work. Sample code:

>>> > > AccountManagerFuture<Bundle> accFut =
>>> > > accountManager.getAuthToken(acct, "reader", false, null, null);
>>> > > try {
>>> > >        if(accFut != null && accFut.getResult() != null){
>>> > >                Bundle bundle = accFut.getResult();

>>> > >                authToken = bundle.getString("authtoken"); // This key
>>> is no
>>> > > longer
>>> > > in the bundle for the 2nd app
>>> > >        } else {
>>> > >                Log.e(TAG, "accFut null");
>>> > >        }
>>> > > } catch (OperationCanceledException e) {
>>> > >        e.printStackTrace();
>>> > > } catch (AuthenticatorException e) {
>>> > >        e.printStackTrace();
>>> > > } catch (IOException e) {
>>> > >        e.printStackTrace();
>>> > > }

>>> > > I don't know if this is supposed to happen but I will cross post this
>>> > > with the android dev google group. It could mean big problems if
>>> > > several apps are trying to get auth tokens for the same service on
>>> the
>>> > > same phone. One application could prevent others from working. I will
>>> > > stick to the old GoogleLoginServiceBlockingHelper method in my apps
>>> > > for now.

>>> > > On Feb 11, 9:03 am, ubikdroid <markst3v...@googlemail.com> wrote:
>>> > > > Thanks for the heads up Brad.
>>> > > > Can you answer these questions please?

>>> > > > 1.) Will there be an overlap where both the SID cookie and the new
>>> > > > header will work for authorization?

>>> > > > 2.) Can the auth token obtained from getCredentials() in Android be
>>> > > > used in this new header? Seehttp://
>>> > > groups.google.com/group/android-developers/browse_thread/threa...

>>> > > > 3.) Can the auth token obtained from AccountManager.getAccounts()
>>> in
>>> > > > Android 2.0+ be used in this new header? Seehttp://
>>> > > groups.google.com/group/android-developers/browse_thread/threa...

>>> > > > Thanks
>>> > > > Mark

>>> > > > On Feb 11, 12:12 am, Brad Hawkes <bhaw...@google.com> wrote:

>>> > > > > Hello friends,

>>> > > > > We just wanted to let you know about changes coming for Reader
>>> > > > > authentication. We will be changing the details for how our
>>> normal web-
>>> > > > > browsing experience handles authentication. This change will
>>> break
>>> > > > > clients that are based on using the SID cookie to communicate
>>> with
>>> > > > > Reader (this seems to be many current clients). To ensure that
>>> your
>>> > > > > app continues to be able to access Reader data you should
>>> transition
>>> > > > > to using ClientLogin to access Reader. This is the general
>>> mechanism
>>> > > > > that is preferred for communication with many Google services.
>>> Details
>>> > > > > of how to use ClientLogin, along with some libraries that are
>>> > > > > available:
>>> http://code.google.com/apis/gdata/docs/auth/clientlogin.html

>>> > > > > Here is a quick summary of how to make this change:
>>> > > > > For those apps that area already obtaining authentication
>>> fromhttps://
>>> > >www.google.com/accounts/ClientLoginyoushouldget back as
>>> > > > > part of your response an Auth= value. For every request you send
>>> to
>>> > > > > Reader you should provide that value as a HTTP header and things
>>> will
>>> > > > > work as usual.
>>> > > > > The header format is: Authorization:GoogleLogin auth=[value
>>> obtained
>>> > > > > from ClientLogin]

>>> > > > > Also please keep in mind that both SID cookies and Auth tokens do
>>> > > > > expire. You should store your Auth token, but if you start to get
>>> 401
>>> > > > > errors you may need to obtain a new Auth token. You should not do
>>> > > > > retries on 401 errors unless you have obtained a new Auth token.

>>> > > > > Thanks for your attention.

>>> > > > > Brad Hawkes
>>> > > > > Google Reader Team

> On 5 March 2010 09:09, Mariano Kamp <mariano.k...@gmail.com> wrote:

> > Mark, I tried on 2.0.1/Milestone and didn't run into the same error my
> > implementation hits. The currently released Widget in the Market sports the
> > new authentication? I selected "use account on this phone" or similar.

> > Stefan, I also tried yours 2.2..9 with the same effect that I see
> > (afterward it seems to just hang "Retrieving Account Details") :

> > V/BeyondPod( 2062): --- BeyondPod Global WiFi WakeLock released!  (21 ms.
> > since last trace)   [BeyondPodApplication]
> > D/dalvikvm( 1244): GC freed 8769 objects / 505928 bytes in 146ms
> > E/WindowManager( 1170): Unknown window type: 2008
> > I/ActivityManager( 1170): Starting activity: Intent {
> > act=android.intent.action.MAIN flg=0x10100000
> > cmp=mobi.beyondpod/.ui.views.Splash }
> > D/dalvikvm( 1517): GC freed 2388 objects / 109448 bytes in 107ms
> > W/ResourceType( 1230): No package identifier when getting name for resource
> > number 0x00000000
> > E/JavaBinder( 1230): *** Uncaught remote exception!  (Exceptions are not
> > yet supported across processes.)
> > E/JavaBinder( 1230): android.content.res.Resources$NotFoundException:
> > String resource ID #0x0
> > E/JavaBinder( 1230): at
> > android.content.res.Resources.getText(Resources.java:200)
> > E/JavaBinder( 1230): at
> > android.content.res.Resources.getString(Resources.java:253)
> > E/JavaBinder( 1230): at
> > android.content.Context.getString(Context.java:149)
> > E/JavaBinder( 1230): at
> > com.google.android.googleapps.GoogleLoginService$AccountAuthenticatorImpl.g etAuthTokenLabel(GoogleLoginService.java:586)
> > E/JavaBinder( 1230): at
> > android.accounts.AbstractAccountAuthenticator$Transport.getAuthTokenLabel(A bstractAccountAuthenticator.java:155)
> > E/JavaBinder( 1230): at
> > android.accounts.IAccountAuthenticator$Stub.onTransact(IAccountAuthenticato r.java:123)
> > E/JavaBinder( 1230): at android.os.Binder.execTransact(Binder.java:287)
> > E/JavaBinder( 1230): at dalvik.system.NativeStart.run(Native Method)

> > Guys, btw., your login integrations look really nice.

> > Anyway, given that at least (2/3) of our implementations are also not
> > working on Android 2.0, not for Google Apps accounts, not for re-login, to
> > use them it was necessary to decompile proprietary Google classes to know
> > what parameters too set, the Google provided GUIs look like prototypes and
> > that there is absolutely zero documentation ... maybe it is a hint that
> > despite the pressure to have such a solution, it is just not ready for prime
> > time.

> > Maybe Android 2.2 will be better and maybe there will be documentation or
> > at least the officially open sourced Google provided apps (Contacts,
> > Calendar, ...) will use the new API without relying on closed source bits.

> > On Thu, Mar 4, 2010 at 10:26 PM, Mariano Kamp <mariano.k...@gmail.com>wrote:

> >> I'll download your widget to a 2.0.1 widget tomorrow and feed back.

> >> On Thu, Mar 4, 2010 at 10:24 PM, ubikdroid <markst3v...@googlemail.com>wrote:

> >>> Hi Mariano, I don't have an Android 2.0.1 device to test
> >>> unfortunately. Just my N1 and G1. I haven't tried hosted accounts.

> >>> My phone didn't prompt me to allow access. I have seen that behaviour
> >>> before though. Probably when I was hacking around with it a while ago.

> >>> You might be right about the cert. I used the same one to sign both
> >>> apps. I might try again with a different cert for each app.

> >>> On Mar 4, 9:09 pm, Mariano Kamp <mariano.k...@gmail.com> wrote:
> >>> > This whole Auth 2.0 thing is a total mess. Did you test it on Android
> >>> 2.0.1
> >>> > devices? It didn't crash for you there? Can you support hosted
> >>> accounts?

> >>> > I think I will give up on this until Google documents how to use their
> >>> > implementation (the Google one, not the Android framework). There is
> >>> just
> >>> > already too much time sunk here.

> >>> > Anyway, regarding your actual issue, did the Auth mechanism ask you
> >>> twice to
> >>> > allow access to the selected account? I am not quite sure how it
> >>> determines
> >>> > the caller, but maybe it might not be the calling app, but the
> >>> certificate
> >>> > it was signed with that makes the difference. Did you use the same
> >>> > certificate to sign both apps?

> >>> > On Thu, Mar 4, 2010 at 9:35 PM, ubikdroid <markst3v...@googlemail.com
> >>> >wrote:

> >>> > > I think I might have found an issue with using AccountManager in
> >>> > > Android 2.x devices. I have 2 apps in the market that use Google
> >>> > > Reader: Reader Widget Pro and Reader Widget Free. I was updating them
> >>> > > both to use AccountManager and the new authentication method. I
> >>> > > noticed that on my Nexus One when one application (say the Free one)
> >>> > > obtained a token using AccountManager.getAuthToken() with the service
> >>> > > set to "reader" the other app (say the Pro one) was unable to obtain
> >>> a
> >>> > > token afterwards. Even using AccountManager.invalidateAuthToken in
> >>> the
> >>> > > first app did not work. Sample code:

> >>> > > AccountManagerFuture<Bundle> accFut =
> >>> > > accountManager.getAuthToken(acct, "reader", false, null, null);
> >>> > > try {
> >>> > >        if(accFut != null && accFut.getResult() != null){
> >>> > >                Bundle bundle = accFut.getResult();

> >>> > >                authToken = bundle.getString("authtoken"); // This key
> >>> is no
> >>> > > longer
> >>> > > in the bundle for the 2nd app
> >>> > >        } else {
> >>> > >                Log.e(TAG, "accFut null");
> >>> > >        }
> >>> > > } catch (OperationCanceledException e) {
> >>> > >        e.printStackTrace();
> >>> > > } catch (AuthenticatorException e) {
> >>> > >        e.printStackTrace();
> >>> > > } catch (IOException e) {
> >>> > >        e.printStackTrace();
> >>> > > }

> >>> > > I don't know if this is supposed to happen but I will cross post this
> >>> > > with the android dev google group. It could mean big problems if
> >>> > > several apps are trying to get auth tokens for the same service on
> >>> the
> >>> > > same phone. One application could prevent others from working. I will
> >>> > > stick to the old GoogleLoginServiceBlockingHelper method in my apps
> >>> > > for now.

> >>> > > On Feb 11, 9:03 am, ubikdroid <markst3v...@googlemail.com> wrote:
> >>> > > > Thanks for the heads up Brad.
> >>> > > > Can you answer these questions please?

> >>> > > > 1.) Will there be an overlap where both the SID cookie and the new
> >>> > > > header will work for authorization?

> >>> > > > 2.) Can the auth token obtained from getCredentials() in Android be
> >>> > > > used in this new header? Seehttp://
> >>> > > groups.google.com/group/android-developers/browse_thread/threa...

> >>> > > > 3.) Can the auth token obtained from AccountManager.getAccounts()
> >>> in
> >>> > > > Android 2.0+ be used in this new header? Seehttp://
> >>> > > groups.google.com/group/android-developers/browse_thread/threa...

> >>> > > > Thanks
> >>> > > > Mark

> >>> > > > On Feb 11, 12:12 am, Brad Hawkes <bhaw...@google.com> wrote:

> >>> > > > > Hello friends,

> >>> > > > > We just wanted to let you know about changes coming for Reader
> >>> > > > > authentication. We will be changing the details for how our
> >>> normal web-
> >>> > > > > browsing experience handles authentication. This change will
> >>> break
> >>> > > > > clients that are based on using the SID cookie to communicate
> >>> with
> >>> > > > > Reader (this seems to be many current clients). To ensure that
> >>> your
> >>> > > > > app continues to be able to access Reader data you should
> >>> transition
> >>> > > > > to using ClientLogin to access Reader. This is the general
> >>> mechanism
> >>> > > > > that is preferred for communication with many Google services.
> >>> Details
> >>> > > > > of how to use ClientLogin, along with some libraries that are
> >>> > > > > available:
> >>>http://code.google.com/apis/gdata/docs/auth/clientlogin.html

> >>> > > > > Here is a quick summary of how to make this change:
> >>> > > > > For those apps that area already obtaining authentication
> >>> fromhttps://
> >>> > >www.google.com/accounts/ClientLoginyoushouldgetback as
> >>> > > > > part of your response an Auth= value. For every request you send
> >>> to
> >>> > > > > Reader you should provide that value as a HTTP header and things
> >>> will
> >>> > > > > work as usual.
> >>> > > > > The header format is: Authorization:GoogleLogin auth=[value
> >>> obtained
> >>> > > > > from ClientLogin]

> >>> > > > > Also please keep in mind that both SID cookies and Auth tokens do
> >>> > > > > expire. You should store your Auth token, but if you start to get
> >>> 401
> >>> > > > > errors you may need to obtain a new Auth token. You should not do
> >>> > > > > retries on 401 errors unless you have obtained a new Auth token.

> >>> > > > > Thanks for your attention.

> >>> > > > > Brad Hawkes
> >>> > > > > Google Reader Team

> We just wanted to let you know about changes coming for Reader
> authentication. We will be changing the details for how our normal web-
> browsing experience handles authentication. This change will break
> clients that are based on using the SID cookie to communicate with
> Reader (this seems to be many current clients). To ensure that your
> app continues to be able to access Reader data you should transition
> to using ClientLogin to access Reader. This is the general mechanism
> that is preferred for communication with many Google services. Details
> of how to use ClientLogin, along with some libraries that are
> available:http://code.google.com/apis/gdata/docs/auth/clientlogin.html

> Here is a quick summary of how to make this change:
> For those apps that area already obtaining authentication fromhttps://www.google.com/accounts/ClientLoginyou should get back as
> part of your response an Auth= value. For every request you send to
> Reader you should provide that value as a HTTP header and things will
> work as usual.
> The header format is: Authorization:GoogleLogin auth=[value obtained
> from ClientLogin]

> Also please keep in mind that both SID cookies and Auth tokens do
> expire. You should store your Auth token, but if you start to get 401
> errors you may need to obtain a new Auth token. You should not do
> retries on 401 errors unless you have obtained a new Auth token.

> Thanks for your attention.

> Brad Hawkes
> Google Reader Team

> We just wanted to let you know about changes coming for Reader
> authentication. We will be changing the details for how our normal web-
> browsing experience handles authentication. This change will break
> clients that are based on using the SID cookie to communicate with
> Reader (this seems to be many current clients). To ensure that your
> app continues to be able to access Reader data you should transition
> to using ClientLogin to access Reader. This is the general mechanism
> that is preferred for communication with many Google services. Details
> of how to use ClientLogin, along with some libraries that are
> available:http://code.google.com/apis/gdata/docs/auth/clientlogin.html

> Here is a quick summary of how to make this change:
> For those apps that area already obtaining authentication fromhttps://www.google.com/accounts/ClientLoginyou should get back as
> part of your response an Auth= value. For every request you send to
> Reader you should provide that value as a HTTP header and things will
> work as usual.
> The header format is: Authorization:GoogleLogin auth=[value obtained
> from ClientLogin]

> Also please keep in mind that both SID cookies and Auth tokens do
> expire. You should store your Auth token, but if you start to get 401
> errors you may need to obtain a new Auth token. You should not do
> retries on 401 errors unless you have obtained a new Auth token.

> Thanks for your attention.

> Brad Hawkes
> Google Reader Team

> I'm currently changing my Google Reader app Unread to use the new
> authentication method, but while testing it I think I found a problem.
> I'm requesting the first set of cookies like this:

> $ curl -s 'https://www.google.com/accounts/ClientLogin'-d
> accountType=GOOGLE -d Email=exam...@googlemail.com -d Passwd=example -
> d service=reader

> This works fine, I get SID, LSID and Auth. However, when I try to
> request the token needed for Google Reader, only SID seems to work,
> not Auth:

> $ curl -shttps://www.google.com/reader/api/0/token-b Auth=$AUTH
> <html><head><title>403 Forbidden</title>
> [...]
> Your client does not have permission to get URL <code>/reader/api/0/
> token</code> from this server.
> [...]

> $ curl -shttps://www.google.com/reader/api/0/token-b SID=$SID
> [returns token code]

> I also tried GOOGLE_OR_HOSTED for accountType, no change.

> On Feb 11, 1:12 am, Brad Hawkes <bhaw...@google.com> wrote:

> > Hello friends,

> > We just wanted to let you know about changes coming for Reader
> > authentication. We will be changing the details for how our normal web-
> > browsing experience handles authentication. This change will break
> > clients that are based on using the SID cookie to communicate with
> > Reader (this seems to be many current clients). To ensure that your
> > app continues to be able to access Reader data you should transition
> > to using ClientLogin to access Reader. This is the general mechanism
> > that is preferred for communication with many Google services. Details
> > of how to use ClientLogin, along with some libraries that are
> > available:http://code.google.com/apis/gdata/docs/auth/clientlogin.html

> > Here is a quick summary of how to make this change:
> > For those apps that area already obtaining authentication fromhttps://www.google.com/accounts/ClientLoginyoushould get back as
> > part of your response an Auth= value. For every request you send to
> > Reader you should provide that value as a HTTP header and things will
> > work as usual.
> > The header format is: Authorization:GoogleLogin auth=[value obtained
> > from ClientLogin]

> > Also please keep in mind that both SID cookies and Auth tokens do
> > expire. You should store your Auth token, but if you start to get 401
> > errors you may need to obtain a new Auth token. You should not do
> > retries on 401 errors unless you have obtained a new Auth token.

> > Thanks for your attention.

> > Brad Hawkes
> > Google Reader Team

> -Brad

> On Wed, Feb 10, 2010 at 4:33 PM, Nick Bradbury <nick.bradb...@gmail.com>wrote:

>> Thanks for the update, Brad.  Do you have any idea of when this change
>> will be required (ie: when the SID cookie method will stop working)?
>> I can certainly change authentication in the next build of FeedDemon,
>> but would prefer to release that build in a few weeks rather than
>> straight away.

>> - Nick

> Mihai

> On Wed, Feb 10, 2010 at 8:38 PM, Brad Hawkes <bhaw...@google.com> wrote:

>> Sorry I forgot to mention that. Our current plan will be activate this
>> change in early April. We want to give everyone sufficient time to make the
>> changes.

>> -Brad

>> On Wed, Feb 10, 2010 at 4:33 PM, Nick Bradbury <nick.bradb...@gmail.com>wrote:

>>> Thanks for the update, Brad.  Do you have any idea of when this change
>>> will be required (ie: when the SID cookie method will stop working)?
>>> I can certainly change authentication in the next build of FeedDemon,
>>> but would prefer to release that build in a few weeks rather than
>>> straight away.

>>> - Nick

> Mihai

> On Wed, Feb 10, 2010 at 8:38 PM, Brad Hawkes <bhaw...@google.com> wrote:
> > Sorry I forgot to mention that. Our current plan will be activate this
> > change in early April. We want to give everyone sufficient time to make the
> > changes.

> > -Brad

> > On Wed, Feb 10, 2010 at 4:33 PM, Nick Bradbury <nick.bradb...@gmail.com>wrote:

> >> Thanks for the update, Brad.  Do you have any idea of when this change
> >> will be required (ie: when the SID cookie method will stop working)?
> >> I can certainly change authentication in the next build of FeedDemon,
> >> but would prefer to release that build in a few weeks rather than
> >> straight away.

> >> - Nick