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
Filter ordering allows automatic disambiguation between multiple filters
that matching a pattern. Ordering currently only works for EphemeralResolveInfo
objects.
Bug: 30837021
Change-Id: Ia217218c7c7d159dbd75d7733c45556e690d06d2
Added RegisteredServicesCache.updateServices method which allows callers
to request an update to services for which package has been updated.
Added a call to updateServices in getAuthenticatorTypesInternal
Test: Manually tested update flow on test authenticator with an artificial
delay in broadcast handling
Bug: 30979262
Change-Id: I499b2ee0be53fed01201c56068d929b6d621a78e
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
In the new design, the ephemeral installer can be returned from
queryIntentActivities which means any intent resolution could potentially
return the installer. Additionally, the new design calls for a platform
defined broadcast receiver that receives the status from the ephemeral
installer. This receiver then starts the final intent -- either to launch
the ephemeral application or to launch the fallback.
For more detail, see go/ephemeral-design
Bug: 30805203
Bug: 30273584
Change-Id: I6644bbb4f180d2d22c63af04b9857577516344a9
(cherry picked from commit 8e2d9d1d90)
Add getKeyAttestationApplicationId and the Parcelables
KeyAttestationPackageInfo and KeyAttestationApplicationId,
needed by keystore.
Bug: 22914603
Change-Id: I89a88cd9cd80e9b132ca67fc452e9cae8b8ad241
* While parsing the packages.xml file, don't call getPackagesLPw(); we'll
never find a package unless something has gone horribly wrong. Instead,
build the PackageSetting like a sane person and add it to internal
structures.
* Add methods to create a proper copy of the PackageSetting object and
not just the data from one class in the middle of the hierarchy.
* Stop converting Sets into Lists back into Sets when creating
IntentFilterVerificationInfo objects
* Remove the name argument when adding a package setting; it should always
be the name in the package setting
Bug: 30219944
Change-Id: I7fa2c540621fb5d70a59b15919bfd31d8465e25d
When fetching system services early during boot, if the underlying
binder interface hasn't been published yet, we end up caching a
manager class that is broken for the remainder of the process
lifetime, and innocent downstream callers end up using the broken
cached manager.
Fix this by using an explicit exception to quickly abort manager
creation when the underlying binder is missing. The exception is
only used to skip the remainder of the manager creation, and it
doesn't actually crash the process.
Bug: 28634953
Change-Id: I0cb62261e6d6833660704b93a11185aa11a2ac97
Simply getting package settings could changes stored state. Break out
the majority of the method to modify local variables and not change
any stored state. The top-level getPackageLPw() method will still
mutate stored state. This will be changed in a future CL.
Also add a set of tests to verify the behaviour of updatePackageSetting()
Bug: 30219944
Change-Id: I3360a36ce238e816246ee8ca7ecabfbbcdf0b89d
