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
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
