Sync adapters that don't have account access cannot run until
the user explicitly approves in the UI. This is spammy given
the user may not use the app right away. This change doesn't
show the notificaiton until the app has run.
bug:31162498
Change-Id: I1f4f2d2e9426f78763590e8aa542b94d6e93e488
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)
- More unit tests
- LauncherApps.startShortcut() now supports sourceBounds
(again)
- Updated the javadoc.
Bug 30218829
Change-Id: Iae208ffd4911d149246ccfd0c4380544c2aafffc
Also fix b/30230996.
TODO: Support the sourceBounds argument to LauncherApps.
startShortcut().
Bug 30218829
Bug 30230996
Change-Id: Ibb6c59d5b7c0a320c21d09436d016d0eac94644f
starting a shortcut.
- Also add API surface to support launching multiple intents
- Also add SM.isRateLimitingActive() which was supposed to be
added but was not due to a bad rebase.
Bug 30218829
Change-Id: I82d60ec0df1e2b889538705f9f8870ee727dd55d
These methods were never meant to be public. Instead, developers
can use Context#createConfigurationContext().
Bug:30088019
Bug:29999297
Change-Id: I2b864136163deda0af99fa3bfe9ef4ee1077341a
Originally we always checked with PM for the default launcher,
which would take ~2ms.
Now we cache the result, and clears the cache when (any) preferred
activities change.
Bug 30126557
Change-Id: Iceef288cd372c8bb9b119aa493e5173d894f2302
If the primary user has a managed profile:
When setting the clipboard in the primary user:
The uris of the primary user's clipboard must not have an
embedded userId.
BUG:28572936
Change-Id: I1eb505c4518cc16a6513b950f6c2b1232a22426d
- Stop using a custom callback from AM to detect locale changes
and use the LOCALE_CHANGED broadcast instead.
- This would open up a chance where a publisher app fetches
its won manifest shortcuts after a locale change but
ShortcutManager hasn't updated string resources.
- So instead, at every entry point from ShortcutManager, check
if the locale has changed, and if so, update all resources
(and reset throttling).
- Do the same for package change events too. At every entry point
from ShortcutManager, check if the caller package has been updated,
or any target activities have been disabled. If so, rescan the
caller package.
- We do *not* do the same check at the LauncherApps entry points,
because the launcher should use the callback to listen to
shortcut changes.
- Also stopped using PackageMonitor for now because we want to
set a higher priority and changing PackageMonitor at this point
seems too much for DR.
Bug 29895275
Bug 30123329
Change-Id: Ib4a2f626a936c7328e2cc032324f5c3d1c3b9122
If we enter multi-window mode or load WebView
assets into a Resources object, then the underlying
AssetManager instance may change.
crbug.com/627586
Bug:30118654
Change-Id: I837637bdad5370809db7f060d7d8536b536cad9e
Originally the code used IIntentSender, but I had to switch to calling
startActivitiesInPackage() directly, because sendIntentSender() does
not support returning errors.
Bug 30035853
Change-Id: I5d7669c96a2f1805373c71aebf45b97ac1d01ff6
- Have PM to call the shortcut manager directly before sending a
pacakge broadcast.
- The shortcut manager will enqueue a task to handle a package
broadcast, which will be executed on Handler.
- At the entry points of all external facing methods, block until
all pending tasks are finished.
Bug 29895275
Change-Id: Ib29fa3c9c8d9b9e0ca5c8f1e9da2a390324960a4
Need to add MATCH_DISABLED_UNTIL_USED_COMPONENTS [and the deprecated
GET_DISABLED_UNTIL_USED_COMPONENTS] since those are used when building
the ApplicationInfo object.
Bug: 29824931
Change-Id: I09b24427222fed082f0946717826d2e0db857c7a
