Android AccountManager使用疑问及跨应用凭证共享实现咨询

Hi there! Let's walk through each of your questions and your follow-up scenario clearly:

Question 1: What do setAccountAuthenticatorResult(Bundle) and onResult(Bundle) do? #

These methods are core to the standard AccountManager callback flow between your AbstractAccountAuthenticator service and the system's AccountManager:

• onResult(Bundle) is called on an AccountAuthenticatorResponse object to send the final result of an authenticator operation (like addAccount or getAuthToken) back to AccountManager. This result typically includes key details such as the created Account object, error codes, or success flags.
• setAccountAuthenticatorResult(Bundle) is used in your authentication Activity (like AuthenticatorActivity in your code example) to package up the result data before finishing the Activity. This data then gets passed to AccountManager via the attached AccountAuthenticatorResponse.

Your app runs without them because you're directly using AccountManager.addAccountExplicitly(...) to create the account, skipping the formal result notification step. But this bypasses the system's expected flow—components that rely on knowing the operation's outcome (like the Activity that initiated addAccount) won't get a proper callback, and system features like account sync might behave unpredictably.

Question 2: What's the purpose of onRequestContinued()? #

This method tells AccountManager that the authentication request isn't finished yet and needs to keep running. It's critical for multi-step authentication flows:

• For example, if your login process first asks for a username/password, then requires a 2FA code in a separate Activity, you'd call onRequestContinued() before launching the 2FA screen.
• It prevents AccountManager from timing out the request or marking it as failed while the user completes additional verification steps.

Question 3: Will the Activity that triggered addAccount call onActivityResult after account creation? #

It depends on how you implement the addAccount flow:

• If your addAccount returns a Bundle with AccountManager.KEY_INTENT (like your code), AccountManager launches that Intent's Activity. When you properly set the authenticator result (using setAccountAuthenticatorResult) and finish the Activity, AccountManager will pass the result back to the original calling Activity via onActivityResult.
• If you skip setting the authenticator result (like your current setup), the calling Activity won't get an onActivityResult callback—so it can't confirm if the account was created successfully or failed.

Question 4: Who receives the extra parameters added to the Intent in addAccount? #

Those extra parameters are received directly by the Activity you're launching with the Intent—in your example, that's AuthenticatorActivity.

Inside AuthenticatorActivity, you'd retrieve them with code like:

String accountType = getIntent().getStringExtra(AuthenticatorActivity.ARG_ACCOUNT_TYPE);
boolean isAddingNewAccount = getIntent().getBooleanExtra(AuthenticatorActivity.ARG_IS_ADDING_NEW_ACCOUNT, false);

These parameters let the Activity customize its behavior (e.g., pre-filling the correct account type field, adjusting UI for new account creation vs. existing account login).

Follow-Up: Impact of skipping result notifications & validity of your implementation #

Your goal of sharing credentials across shared-signature apps using a custom authenticator service is totally valid—this is exactly the kind of use case AccountManager was designed for. However, skipping the result notifications has notable downsides:

1. No feedback to calling components: The Activity that initiated addAccount() can't confirm if the account was created successfully (it won't get an onActivityResult callback), making error handling and user feedback harder.
2. System integration issues: Features like the system's Account Settings UI, account sync adapters, or other system services that rely on authenticator results might not work as expected. They depend on the standard result flow to update their state.

Is your implementation "correct"? #

It works for your immediate use case, but it doesn't follow official AccountManager best practices. To fix it, after calling addAccountExplicitly(...) in your login flow:

1. Create a Bundle with key result data (at minimum, include AccountManager.KEY_ACCOUNT_NAME and AccountManager.KEY_ACCOUNT_TYPE).
2. Call response.onResult(resultBundle) (using the AccountAuthenticatorResponse passed via the Intent) to send the result back to AccountManager.
3. Finish your AuthenticatorActivity—this triggers AccountManager to send the result to the original calling Activity via onActivityResult.

This ensures the entire system is aware of the account creation and behaves consistently.

内容的提问来源于stack exchange，提问作者JonZarate