Chromium Android - why does it require a platform account to sign in?

[Holger]

Hey everyone,

Running Chromium's sign in code complains about requiring Google Play (e.g. SigninManager.signIn()) --> This indicates that signing in without using Android platform accounts is not supported.
While I understand the reason for the existence of leveraging Android Auth (no extra login - very convenient! :D) - is there any reason why it is a hard requirement?
From what I can tell the whole signin component is compiled in on Android - could it be used to sign in without having an Android account?
E.g., why can't I sign in to Chrome with a Google account that is different from the accounts registered to my Android device?

In case that should be possible - any pointers on an easy way to implement this? :)

Thanks!
Holger

[Ted Choc]

On Tue, Aug 23, 2016 at 4:11 PM, 'Holger' via Chromium-dev <chromi...@chromium.org> wrote:

Hey everyone,

Running Chromium's sign in code complains about requiring Google Play (e.g. SigninManager.signIn()) --> This indicates that signing in without using Android platform accounts is not supported.
While I understand the reason for the existence of leveraging Android Auth (no extra login - very convenient! :D) - is there any reason why it is a hard requirement? 

From what I can tell the whole signin component is compiled in on Android - could it be used to sign in without having an Android account?
E.g., why can't I sign in to Chrome with a Google account that is different from the accounts registered to my Android device?

I'll start off by saying that I'm not expert on sync or signin, but I can speak to the more product-y decisions we made.

You basically hit the crux of the issue already, but I'll provide our justification.  Android, as opposed to the desktop ports of Chrome, is the first platform to have a system wide account manager (at least for managing Google accounts, which are required for signing into Chrome).  The two major product decisions for this behavior are:

1.) Consistency with other applications that use Google signin.  I'm not aware of any that allow Google accounts not listed in the system.

2.) Avoiding user confusion and UI complexity.  If Chrome were to expose an Account manager, you would have to do a mental dance every time you need to interact with the account (do I go to Android/Chrome, how do I turn off sync, etc...).

I don't believe there are any strong technical limitations, but there are some pretty strong product ones that make this something we are very unlikely to ever support on Google Chrome.

 

In case that should be possible - any pointers on an easy way to implement this? :) 

 

Thanks!
Holger

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Holger]

That makes absolute sense, thanks for the explanation Ted! :)
I can see how it would be undesirable for Chrome to add separate accounts. In the best case it would be hidden well and thus not really apply to point 2, but I presume the amount of effort required to implement it would even then not make it worthwhile. (and there would still be the inconsistency with other Google apps)

However, I'd still be interested in playing around with this locally, and any points on how to best approach this would be welcome! :)
(I'm absolutely fine with hardcoding my username and password somewhere to send out the sign in request - this is purely for testing whether or not it can be done. I also don't really care if the UI settings section recognizes whether or not I'm logged in, as long as the sync still works)

Thanks!
Holger

[Drew Wilson]

I think you may be able to do some of this without a ton of work - my recollection is that ProfileOAuth2TokenServiceFactory is the factory that creates a platform-specific ProfileOAuth2TokenService, which is the service that stores and generates OAuth2 tokens for the signed-in account. You'll want to build a version of Chromium that uses the desktop version of ProfileOAuth2TokenService instead of the Android version.

The big thing you'll probably be missing is the signin UI itself - not sure if some of those classes are missing on Android or not. You won't easily be able to hardcode your username and password, because we try pretty hard these days to drive people through a web flow for password entry (for various security and product reasons) - not even sure if it's possible to generate an OAuth2 refresh token from a raw username/password any more without going through a web flow.