> 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