We keep track which process saw and account to whitelist
the app for future access as an optimization to avoid
prompting the user for account access approval. Some apps
use SefeParcelable where the parcels are marshalled
which does not allow the parcel to contain IBinders.
To avoid this we are switching from account tracker remote
objects to unforgeable tokens.
bug:31162498
Change-Id: I19916b54afd0b47e57c517145aa6b1ff17154144
Sync adapters without an account access cannot run until the
user approves the account access (for the case the account
access is not allowed by other policy such as being singed
with the same cert as the authenticator). If the sync adapter
does not have permission to access the account we ask the
user to grant access and take a note. This CL adds backup
for the explicit user grants.
bug:31162498
Change-Id: I31e3f3d010475352c7c54255ac2d3a2fed4d0c72
Sync adapters without an account access cannot run until the
user approves the account access (for the case the account
access is not allowed by other policy such as being singed
with the same cert as the authenticator). However, if the
sync adapter package already got the account from another
app which means it already saw the account we white-list
the sync adapter app to access the account as it already
saw it - the bird is out of the cage.
bug:31162498
Change-Id: I2b72f3b0d6307561ed68db2f2e9c900b15e8d098
It was possible for a sync adapter without accounts access to
see the account which it is supposed to sync which can be used to
identify the user. This change ensures that only sync adapters
with account access can run (which results in seeing the account),
otherwise we involve the user to approve access only to this account.
A sync adapter can access an account if one of these is true:
- it is signed as the authenticator for this account
- has the GET_ACCOUNTS permission
- has an auth token for the account
- it is a preinstalled app (system or privileged)
The main thing we need to figure out is if the extra prompts
for giving access to a sync adapter to the account create too
much friction.
bug:28163381
Change-Id: Ie083bb681b5a2aed81ca5f6a062193a175fad77e
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
There is a problem of AccountManager that onAccountsUpdated() is
called back even after the OnAccountsUpdatedListener is unregistered.
It may cause application crash.
For example, when rotating a tablet 180 degree with Settings apk
running, com.android.settings.Settings is re-launched 2 times
successively. (Destroy->Create->Destroy->Create)
It repeats adding&removing OnAccountUpdatedListener.
When dialog was being opened in the following cases,
NullPointerException at BackStackRecord.getBreadCrumbTitle()
was happened on 10 inch tablet which has 2 panes on Settings.
* Settings > Language&input > Language
* Settings > Language & input > Text-to-speech output > Speech rate
* Settings > Wi-Fi > Menu > Advanced > Keep Wi-Fi on during sleep
* Settings > Wi-Fi > Menu > Wi-Fi Direct > Rename device
This fix prevents the undesirable callback.
Change-Id: I081f69c90539cca821cf686b4587495135f375e4
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
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
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
