In the past android:customTokens=true authenticators were required to handle
their own token caching. This is detrimental for battery when high traffic
authenticators are constantly spinning up processes to start services to do
file io to check their own caches. This change allows authenticator
implementers to optionally let the framework do some of the work for them by
providing the framework with a expiration time.
The AccountManagerService will make a best effort to re-use the cached
token if possible.
Bug: 21530782
Change-Id: I16a7edba36a220e3891e55cf61c725c2be863323
Fixing lots of bugs related to the ChooseAccount Activities.
1. Fix jank which is seen when no accounts are present on the device.
2. After addition of the account, return to the user.
3. Don't crash when the user provides null to allowableAccountTypes.
4. Updated documentation of AccountManager#newChooseAccountIntent.
5. Fix NPE.
Bug: 13104800
Bug: 17926560
Bug: 9626001
Change-Id: I0d1913e46560cfb458526a7c930a38049602d8f1
Storing last successful sign-in/authentication timings, and providing that
information as extra's in updateCredentials and confirmCredentials.
Also, adding a new api: AccountManager#accountAuthenticated(Account).
Change-Id: Icd0dac35b13d61bc28a2e045b96caefffeb353be
Adding the copyAccountToUser method which copies an account
along with its credentials to a different user.
Also an extra in the public api to identify the account to migrate
during provisioning.
Bug: 17716971
Change-Id: I2f29f1765ba0d360a3894b13ef86253b7c7d3284
API for querying accounts visible to a specific package.
Improve API and docs for device owner.
Bug: 8657158
Change-Id: I01b8701534f64b383391508a49ae93ed21f22ae0
Note that this change still leaves things in an imperfect state. Now instead
of ANR with an NPE it will reshow the Choose account activity and then on the
second back, it will go away. So the user isn't hosed. But it is still a sloppy
experience. Basically the bug fix reveals another not quite as bad bug
(see https://b/8661942).
Bug: 8151602
Change-Id: I44b188f5940d464c2dd81dd0b6b7cae3c189becd
This covers the scenario where an app doesn't find an account of the
required type and requests the account manager to add one of that
type.
Bug: 8537648
Change-Id: I4d9c8842c2d90aa668f16034d3db007dc61714b8
Make sure that apps that have access to restricted accounts can see them.
If they don't have access, they shouldn't be able to add a new account either.
Show an error message in the account picker if the user/app is not authorized.
Change-Id: I117c0b14d7d06c5ac4e66506df156b174567f5f3
Add a new error code to AccountManager and remove the check for
limited user during add account to allow Authenticators to seed
account during limited profile startup.
Change-Id: I5a73def9fc3baeb8e6de1b42e923829c335e1668
Adds the ability for apps to export some restrictions. The restrictions
are presented in Settings based on the restriction type. The user's
selections are stored by UserManagerService and provided to the
target user's application as a list of RestrictionEntry objects which
contain the key, value(s).
Also introduce a manifest entry for system apps to request that the
app be automatically installed in all users, so that they cannot be
deselected by the owner user.
Shared account filtering for non-whitelisted apps.
Change-Id: I15b741e3c0f3448883cb364c130783f1f6ea7ce6
API and preliminary implementation for sharing primary user accounts with a secondary user.
AbstractAccountAuthenticator has new methods to retrieve and apply a bundle of credentials
to clone an account from the primary to a restricted secondary user. The AccountManagerService
initiates the account clone when it starts up the user and detects that the user has
a shared account registered that hasn't been converted to a real account.
AccountManager also has new hidden APIs to add/remove/get shared accounts. There might be
further improvements to this API to make shared accounts hidden/visible to select apps.
AccountManagerService has a new table to store the shared account information.
Added ability in PackageManager to install and uninstall packages for a secondary user. This
is required when the primary user selects a few apps to share with a restricted user.
Remove shared accounts from secondary users when primary user removes the account.
Change-Id: I9378ed0d8c1cc66baf150a4bec0ede56f6f8b06b
This helps reduce the pressure on framework.jar, and makes it clear
that it should only be used by the system_server.
Bug: 7333397
Change-Id: I0858904239535380fbf30562b793e277d8c3f054
Bug: 7473142
Provide hidden methods in AccountManager for querying accounts and
authenticating for a specific user. Lockscreen is running in the
system process. Allow only system process to access accounts across
users.
Also make sure to launch the lock settings screen on the just reset
user using startActivityAsUser()
Change-Id: Ifefc0039ba2b51396b8bd0268f36d5271a3d8676
Instead of explicitly scanning OWNER accounts, move to using the
"user starting" call path for consistency.
Bug: 7358086
Change-Id: Ied3289a074aafa48259d828db1d68804912589b3
Allow accounts to be loaded when a user is stopped, but always
validate accounts against a freshly queried PMS cache when the user
actually starts.
Bug: 7276595
Change-Id: I0382064c73123c243bc6f6e5da8fc3d0a8b73442
RegisteredServicesCache is used to track account authenticators and
sync adapters, which can vary based on user. This change requires
that callers now provide a userId when making cache requests. It
continues persisting into a single file for now, which is keyed based
on UID.
It now watches for package broadcasts from all users, and scans
packages on-demand. It changes cache callers to provide a relevant
userId, and evicts cache entries when users are stopped.
Changes SyncManager to only work with accounts from running users,
only kicking off pending syncs once a user is started.
Bug: 7276595, 7316150
Change-Id: I79466a84aa69aa37e4bd9691c5d6221d3662ff29
Also fix a bunch of system services that should be doing this. And
while doing that, found I needed to fix PendingIntent to evaluate
USER_CURRENT at the point of sending, not creation.
Note that this may end up with us having some notification shown to
non-primary users that lead to settings UI that should only be for
the primary user (such as the vpn notification). I'm not sure what
to do about this, maybe we need a different UI to come up there or
something, but showing the actual notification for those users at
least seems less broken than not telling them at all.
Change-Id: Iffc51e2d7c847e3d05064d292ab93937646a1ab7
Activities which help select an account gather the list of accounts only during create and dont update it agian. When a user moves out of the account selection activity by clicking home page, deletes an accout in the background and comes back to the earlier accout selection activity, the deleted account still exists as an option. This cl fixes this by updating the account list on resume.
Bug: 7135608
Change-Id: Idc9a2fa6451b032310c0ad66f6db0e2f0967feeb
Environment.getUserSystemDirectory(int userId)
Use it all relevant places that was hardcoding it.
Also, wipe out the user's system directory when user is removed, otherwise old state
might be transferred to a new user.
Change-Id: I788ce9c4cf9624229e65efa7047bc0c019ccef0a
Replaced all remaining places that used it with explicit user
specification.
While doing this, I ran into stuff that was creating PendingIntent
objects (that now need to specify the explicit user they are for),
which are also posting notifications... but have no way to specify
the user for the notification.
So the notification manager in the system process now also gets a
formal concept of a user associated with the notification, which
is passed in to all the necessary aidl calls. I also removed the
old deprecated aidl interface for posting/cancelling notifications,
since we now always need a user supplied.
There is more work that needs to be done here, though. For example
I think we need to be able to specify USER_ALL for a notification that
should be shown to all users (such as low storage or low battery).
Along with that, the PendingIntent creation needs to be tweaked to
be able to handle USER_CURRENT by evaluating the user at the point the
pending intent is sent.
That's for another change, however.
Change-Id: I468e14dce8def0e13e0870571e7c31ed32b6310c
