When the docked stack is minimized and we are unminimizing it
due to a request to start it's currently paused top activity,
it is possible for the new intent not do be delivered immediately
because it isn't resumed due to another activity been launched in
the system (Recents) which is resumed instead. So, the user won't
see the effect of the new intent until they touch the docked activity
causing it to get the new intent and resume.
We now deliver new intents to the top activity in the docked stack if
it is in a minimized state. Then on the client side we temporarily
resume the activity and pause it again to guarantee onResume is called
after onNewIntent.
Bug: 31371093
Change-Id: Ib1764ccf5efc9d6498ce6cc8a34236c79fc07dad
Previously it would almost always force SearchView to become 0
when height mode was UNSPECIFIED.
Bug: 31302290
Change-Id: Icd2116b84951b1b967666147dbc5762d996408e6
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
getMaxAvailableHeight is ignoring the top insets, while
findDropDownPosition is not. This is causing getMaxAvailableHeight
to return a fits above position that findDropDownPosition will think
is too large.
Bug: 31048766
Change-Id: Ifa57cb4ebe0944c701a6f38b58d4f144d8b9199c
There may be a pending selection from a previous filter() call, but the
current filter() call may return an empty string without posting a new
pending selection.
Bug: 31049172
Change-Id: I2cb88b3283a3705b6c85d61f26951c35d2b0acd2
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
There is no functional change. This is to support adding new types of zygotes
that all operate using the same protocol.
Bug: 21643067
(cherry picked from commit 94e824bc1b)
Merged-In: Ie673ee816cae34ac20ffb8c774ec3e6461c3fd0a
Change-Id: I104e6133a90dc93a9854836b5e92d3cd542163a3
Like a normal (foreground) request, a background request is only
satisfied by one network and will keep that network up. Unlike a
foreground request, when a network only has background requests,
it will linger, and after lingering is complete, it will become
a background network.
Future CLs will cause the system to treat background networks
differently, e.g., by requiring different permissions.
Bug: 23113288
Change-Id: I40f735269dad1042eb04fea15e64584fc903ccb3
