ZenModeHelper was only considering a subset of all notification usage
types. The code was also iterating over the usage values, expecting
them to be contiguous, which will break with the addition of new
usage values.
The update consists in:
- defining in AudioAttributes an array of expected usage types
- defining the suppression behavior for each usage type
- have ZenModeHelper query the behavior for each usage in
order to apply the corresponding muting behavior.
Bug 29009099
Change-Id: If884dda6297f125c60c5775c757df4f782e22e53
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
Currently PointerController starts listening to display events
immediately (in its constructor) and never explicitly removes
the callback. The reference dangling from the looper
prevents the PointerController instance from being deleted
when all the clients have released their references.
As a result, when USB or BT mouse is disconnected,
the mouse stays frozen on screen and only goes away
after a 15 sec inactivity timeout.
This change introduces an intermediary LooperCallback
which holds only a weak reference to PointerController.
The pointer now disappears immediately upon mouse
disconnect.
Bug: 30824220
Change-Id: I5f7208dbfa381b3e21f248cc0da402f307faa184
Only defer transactions originating from repositionChild. There is
no guarantee the frame we are suggested to synchronize to will ever
arrive and synchronizing WM originated transactions to this can
interfere with implementation of system policy. Anyway this code
originally was fixing a case where transactions pushed by pulling
down the notification shade, would interrupt animating SurfaceView's
by pushing an undeferred transaction for those SurfaceView's. This
doesn't seem to be occuring anymore even without this code. Furthermore
even if it was occuring, we should prevent transactions from pushing
updates for Surfaces where nothing has really changed, rather than
attempt to chain the deferred transactions.
Bug: 31293950
Bug: 27098060
Bug: 28858420
Change-Id: Ifb83fe78bb4e7d18376e53a743709648aa1e03bc
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
This CL splits rematching in two parts: first rematch requests,
then rematch listens. This will allow us to change a network's
capabilities depending on what requests are on that network, and
properly dispatch callbacks depending on those capabilities.
The behaviour changes are as follows:
- Before this CL, callbacks for requests and listens were sent
intermingled. After this CL, all request callbacks will be
grouped together, and all listen callbacks will be grouped
together.
- Before this CL, the order was:
1. Send onLost callbacks.
2. If applicable, switch the default network.
3. Send onAvailable callbacks.
After this CL, the order is:
1. Send onLost callbacks for requests.
2. If applicable, switch the default network.
3. Send onLost callbacks for listens.
4. Send onAvailable callbacks for listens.
5. Send onAvailable callbacks for requests.
These changes shouldn't affect any apps because:
1. The order of callbacks continues to be first all onLost,
then all onAvailable.
2. Both the old and the new code send callbacks in no particular
order. Thus, the possible ordering combinations of callbacks
in the new code are a strict subset of the possible ordering
combinations of the old code.
3. The default network is switched before any onAvailable
callback is sent.
4. Even though the new code does not send all onLost callbacks
before switching the default network, even before this CL
there was no guarantee that those callbacks would be received
before the default network switch anyway, because callbacks
are asynchronous.
Bug: 23113288
Change-Id: Ia08900c50db9ff43895047e2f4f36b6c6c31a1f9
The code snippet in the "View the Video" section now uses consistent
naming for the variable that represents the Intent containing the URI
of the video to play.
Bug: 25068669
Change-Id: Ibb1a454d647e8ab6cccfe9a8b0efd4fb5c986290
The ACTION_VIEW intent contained a content path that was inconsistent
with each of the other examples on the Intent reference page. Added
the "people" directory to the content path to remedy this issue.
Bug: 26405268
Change-Id: Ieb4f67e072338a108b9775d3bafad3d0773533d2
Added note that, if a device doesn't have a SIM card, its IP address
determines the current country, and therefore whether to filter paid
apps on Google Play.
Bug: 3128012
Change-Id: I18d1f5ef195d0102b4c835932d3e813b8d5d89ca
