For each runtime permission we have an app op to toggle the
permission for legacy apps as they cannot handle permission
revocations. We were lacking an app op for get_accounts
which prevented the user from controlling access to accounts
regardelss that they change the state of the permission
toggle in the UI. Even worse the permission UI is written
with the assumption that every runtime permission has an
app op and as a result revoking the contacts group (if the
app requests the get_accounts permission) is reset back to
allowed in the UI.
bug:23854618
Change-Id: I9e3f9bfeb320bed561d718db99ee285915d5701b
First, getAccounts*() will now return all available accounts depending
on both GET_ACCOUNTS grants and signature matching. This is different
from before where a caller of getAccounts() would need GET_ACCOUNTS to
get any accounts, but if that same caller called getAccountsByType, they
might have gotten back accounts if they shared a signature with the same
developer.
Second, cleaned up some NPEs and javadoc.
This change was motivated by progress on the cts tests.
Change-Id: I2f36226780e074fdf58214b46de3b79d8319ace1
Currently, the docs for AccountManager are somewhat misleading and may
cause developer errors. To avoid them, we are properly documenting it.
Bug: 21924096
Change-Id: If775a54a09219b0f1623d2ff903085b9d12aa863
The javadoc for newChooseAccountIntent says that a null
value for the allowableAccounts parameter is valid and
an acceptable default. This CL makes sure that when this
parameter is null, a NullPointerException is not thrown.
Bug: 22475546
Change-Id: Ieb0d67dd02628e1ae5629499b3be3c6382efc9aa
Related to recent permissions and system health changes. This change
will make it so that calls to AccountManager#getAccountsByType will work
for the owning account authenticator even if they don't have
permissions. This is pretty fundamental to having a working
authenticator and it doesn't make sense to have it be disabled (or have
authenticators hack around the framework).
Also changed how TokenCache works so that memory usage is still
predictable (no more than 64kb) but token caching won't be at the mercy
of garbage collection. This is important for writing stable cts tests.
Change-Id: Ib31b550616b266ee5a04eb26b04ba0023ca0cb83
We should not modify lastAuthenticated timestamp in authenticator
specific api's, as some of the calls maybe used by authenticators
for internal maintainance/upgrade. Only modify the timestamp when
calls effecting accounts is made to non-authenticator developer api's.
Bug: 21959561
Change-Id: I7b2d0c875957b263c4d9b203fe1f33042a65a58f
Requires updating the docs in AccountManaager as well as the logic in
AccountManagerService.
MANAGE_ACCOUNTS, USE_CREDENTIALS, and AUTHENTCATE_ACCOUNTS are going
away. Where AUTHENTCATE_ACCOUNTS was required we now do signature
matching.
GET_ACCOUNTS is kept but has been grouped under contacts.
Bug: 20136477
Change-Id: Iabbb76dce8d1efc607c1f107911d7ddab598a481
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
