getCurrentInputMethodSubtype() acquires InputManagerService.mMethodMap
within its body. There seems to be no reason for holding
InputMethodManager.mH to call getCurrentInputMethodSubtype(). Holding mH
can cause potential deadlock b/w two threads acquiring mH and mMethodMap
in different orders.
Bug: 31247871
Bug: 31273203
Bug: b.android.com/218423
Change-Id: I20cf2c20f49b1b02c0f7a18257b49d4bcc081b5d
This change adds a new pathMatch attribute to the intent-filter tag
that supports a subset of regular expression syntax. Supported
tokens include dot (.) and set ([]) and supported modifiers include
zero-or-more (*), one-or-more(+) and ranges ({}).
Change-Id: I2ec3bc8a9eb3e94d21caf34a1ed0f3fd3fb33a35
Bug: 30805203
This patch adds a way to configure devices so that a validated network
that becomes unvalidated is not penalized in the network scoring and
selection logic.
The intent is to prevent devices configured to do so from switching to a
lower scoring network such as cellular networks when a higher scoring
network such as wifi networks loses internet connectivity.
Bug: 31075769
Change-Id: Ie7e0f2607d214a178367fedfbef6c44768fa00a4
Work profile challenge is shown by intercepting normal activity launching and
replacing it with the confirm credential activity. For direct boot aware
activities, they should be able to be displayed when the work profile is
still locked, so add a conditional in the activity intercepting logic to bypass
work challenge in this case.
Also launching work profile activities from notification is handled specially
in order to avoid dismissing the notification if the work challenge is canceled,
so add similar logic there to allow direct boot aware activity to go through.
Bug: 30296144
Change-Id: Ib6395271cee2d4781009bb08d50351d73824de0c
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
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
