Second attempt. Still need to add strict mode violation checks and
logging.
Bug: 21901286
This reverts commit bf33bd4d31.
Change-Id: I5d73343544c32ce4fc4c377ba44db8e677a1287d
Similar to first patch, but now using new "rethrowFromSystemServer()"
method which internally translates DeadObjectException into
DeadSystemException. New logic over in Log.printlns() now
suppresses the DeadSystemException stack traces, since they're
misleading and just added pressure to the precious log buffer space.
Add some extra RuntimeInit checks to suppress logging-about-logging
when the system server is dead.
Bug: 27364859
Change-Id: I05316b3e8e42416b30a56a76c09cd3113a018123
New API for an app to request creating a new user with
a given user name and seed account information for the
SetupWizard to use when that user is switched into.
Also adds system APIs to read the seed account data from
UserManager.
Bug: 22776757
Change-Id: I0bc3f11ee19c15e0ee2a908c88d98b13296cc30d
Also moved restricted profile create/setup logic from Settings to
UMS.createRestrictedProfile.
Bug: 24212155
Bug: 24303609
Change-Id: I0346a3368de53f4bb4b6e054349f19adac959d7f
Also moved restricted profile create/setup logic from Settings to
UMS.createRestrictedProfile.
Bug: 24212155
Bug: 24303609
Change-Id: I5f0d48bcbd3c0b51927926b874fd057c15ac5219
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: I12b83dfd22974d130e5b8e7a195421120813e2db
Refactor copyAccountUser to take an explicit user handle instead of
hardcode to owner. This requires refactoring one app that uses this
Api.
Bug: 19913735
Change-Id: Ib9b11d8155bea2a58974d09ec2d70bc756d46313
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
