When a null window background is set, we want to use the
fallback drawable for resizing.
Bug: 28801472
Change-Id: Ia616d7aa18b0d7aa2c7081a85ce7551ecfeca5b3
the src attributes were being modified by the devsite parser,
so i renamed those attributes then rename them again at runtime.
bug: 28801246
Change-Id: I34d0dff8fa7f430226dd1d12fccb2cdbeda365db
am: 1669d42808
* commit '1669d42808251eebddfe5e176eb8d322b84df636':
Never set resized while not drag resizing for pinned stack.
Change-Id: I5da72476c63c5f368e7ff8c1269308d206761ffd
Because of an underflow the alpha could actually become 0xff instead
off 0 which would be visible as a black scrim. This was because of
our local updating of animators.
Change-Id: I4201a4bbfbc7cbf32819f4814c165d0e11adaadb
Fixes: 28840532
am: 2486cb2c89
* commit '2486cb2c8978003d2b5cfa7e8169019421582cb0':
Fixed a bug where the chronometer was invisible
Change-Id: Ib495f096b5b2bc758ce7224fae33ba1a44c027a2
The devices with USB PD support can have the data role and the power role of
their USB-C port reversed. Ensure the title of the notification and the content
of the USB selection dialog is correct in this case.
Testing done on Ryu with the following accessories:
- legacy A-C cable
- USB-C charger (5X)
- USB-PD charger (Zinger)
- Pixel 2 (in both roles)
- Type-C Macbook (in both roles)
- Nexus 5X (in both roles)
- Apple AV HDMI accessory
- LG USB-C screen/dock
- Honeybuns dock
Bug: 28310685
Bug: 24137353
Change-Id: Id7f358c40d8714fae68ca98a7eb067f62f18b0af
(cherry picked from commit 0be6800b0f)
am: 0676196be2
* commit '0676196be2657fdf265fa7ad1eae3eecf1bbfebc':
Fixed a bug where the chronometer wasn't updating the time
Change-Id: I16327b27bcfce8eaeb18cbddd420bb134cff1e45
TalkBack is seeing crashes that I can only explain by our assumption
that window layer is unique in all cases. TalkBack reports that it
happens during animation, so I assume that the layer may repeat
transiently.
Reducing our dependence on this assumption by traversing the list of
windows sorted by layer without assuming that the list has the same
length as the list of unsorted windows.
Also documenting the undefined behavior of SparseArray when indexing
beyond its bounds. The undefined behavior itself is intentional for
performance reasons.
Bug: 28679528
Bug: 28815817
Change-Id: I0c9f90b0b458b4cde465f603ba204fe6691e5c2c
It's not necessary in the pinned stack and interferes with the
animation. It's not enough to just check getBoundsAnimating, as
we turn that off prior to the final resize so that we unmute
notifications to the client.
Bug: 28559097
Change-Id: Iae180c8a8ca0585184efcf24e7677557a33678eb
This method is a helper for internal use only.
+ Updated docs for QUOTA_OCCUPIED, QUOTA_TOTAL, and QUOTA_UNAVAILABLE.
Change-Id: Ib146926cd2bff50affe970a0123bcbec62ac3e70
Fixes:28842445
am: b5b03bc450
* commit 'b5b03bc450235ffa85ac636da460b61f1e99bff1':
Mapping up/down of legacy Gps vs. Gnss Status
Change-Id: I2ff6c7714ecca01cb75176452cdbd2ec969fc937
am: 090bf55130
* commit '090bf551308e68b1b2a996c959b608cabd025c5c':
While turning OFF do not honor ON requests.
Change-Id: I528c640a9bc482fbbec3b11eef6569c93a632b76
Native stack does not handle being put from OFF -> ON state without
doing a complete cleanup. Hence instead of going from start -> ON -> OFF
-> cleanup it goes start -> ON -> OFF ->ON -> ... usually leads to race
conditions down the road in native.
This patch is a workaround so that we can throw away the requests if we
are in currently "turning off" phase. The side-effect would be that user
will need to turn it ON again. The race happens when the turn OFF time
is longer but usually it is found to be close to order of seconds hence
the wait should be bounded.
Bug: b/28318203
Change-Id: I14f6633f31311e5b561e1dcbc8a9d6d2a5dd6fdc
As pointed out here:
https://code.google.com/p/android/issues/detail?id=69834
registerApp() causes onClientRegistered() to happen before autoConnect
is set. This patch fixes that.
Bug: 28861330
Change-Id: Ie1174c0f224f5084178439420b383164d22d542c
