in ChooseAccountActivity, its visibility doesn't get updated.
However, it is supposed to be updated to USER_MANAGED_VISIBLE.
Bug: 62067445
Test: manual
Change-Id: I2fb942a96d07dff06a53bc48a16ff337c50f3a26
Most @SystemApi methods should be protected with system (or higher)
permissions, so annotate common methods with @RequiresPermission to
make automatic verification easier.
Verification is really only relevant when calling into system
services (where permissions checking can happen on the other side of
a Binder call), so annotate managers with the new @SystemService
annotation, which is now automatically documented.
This is purely a docs change; no logic changes are being made.
Test: make -j32 update-api && make -j32 offline-sdk-docs
Bug: 62263906
Change-Id: I2554227202d84465676aa4ab0dd336b5c45fc651
1) Include KEY_ACCOUNT_NAME and KEY_ACCOUNT_TYPE.
2) Only send the broadcast to packages which were able to see the
account.
Test: manual, APCT.
Bug:37280078
(cherry picked from commit cbbc99f762)
Change-Id: I3c323e545628199903313096f93654687fa8f22b
AccountManagerService sends an intent with the action when account of any type is removed or renamed.
Test: manual, APCT.
Bug: 37280078
Change-Id: I53b1bb9d6cde1edba5c37ecf3e4e13d748b19005
for callers with READ_CONTACTS permission.
Test: manual
Bug: 36983643
Change-Id: I1239a30a71cb13ce9ffff6f38b8506e9686abe4d
(cherry picked from commit d7e7a74179)
Use accounts order from getAccounts() method instead of
getAccountsAndVisibilityForPackage(), which is unpredicteble (not linked
HashMap)
Test: manual
Bug: 34684498
Change-Id: Idbd4dc1a4f7d5b5b8a1329b27f01a0793a64245d
(cherry picked from commit b2f1263b25)
This will be used to help document the expected behavior of various
broadcast actions defined by the OS.
Also add logic to PackageParser that will then yell at developers
whose manifests are making bad assumptions about which broadcasts
they'll receive.
Test: builds, boots
Bug: 35925551
Change-Id: I059c2bf8aa3ce53d9ff18dcc263db7620cd14bd6
In AccountManagerService.getAccountsAsUser, we check if opPackageName
belongs to calling uid by calling AppOpsManager.checkPackage. But when
AccountManagerService.getAccountsAsUser is called from
AccountManagerService.addSharedAccountsFromParentUser, we're using the
opPackageName from system context instead of calling context.
Bug: 35258008
Test: cts-tradefed run singleCommand cts-dev --module CtsMultiUserHostTestCases \
-t android.host.multiuser.CreateUsersPermissionTest#testCanCreateRestrictedUser
Change-Id: I5c425d9314beb86f7c64a5b5c64b7d879711879a
Use package name instead of uid.
Check calling package name in getAccounts methods.
Bug: 34841115, 34841115
Test: cts tests, manual tests.
Change-Id: I8a9e6aea5e2b6677be4bc414836b842239c5b6ac
Remove no longer used functions and in-memory visibility table.
Add stubs for new methods.
Actual implementation will be added in follow up CLs.
Bug: https://b.corp.google.com/issues/33046496
Test: manual tests, cts tests.
Change-Id: I990759b20c57df70bc944e27b84e59b9f77b9bd4
Many activities in core were using the
material theme which would result in teal
colors on all devices. These themes have
all been changed to DeviceDefault so that
the color will be more suited to whatever
device the user has.
Test: Manual Inspection
Bug: 31623421
Change-Id: I6847023c4fb57a1c3384a1f8e483cd740229458f
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: I3b52bff720655f695ad0c58d420eb35ef93161b9
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
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
