Currently if View.setTooltipText is called while
the tooltip is being shown for that view, it will
update the displayed text. The tooltip then will
resize to wrap around the new text, but not change
its position. This looks confusing if the new text
is significantly shorter or longer.
Removing this functionality until proper
re-positioning is implemented.
Bug: 38491655
Test: android.view.cts.TooltipTest passes
Change-Id: I79689288185888854b992b89e19fe381d3ac50e4
This is required for migration scenario, where device(s) are already
paired(and thus no longer discoverable) but didn't go through companion
flow.
This also fixes a bug with filtering by mac address, which is also relevant to
the use-case of associating a specific device
Test: Pair with a device first, and call associate with a filter with its MAC
address and single device requested. Ensure the device is found.
Ensure only that device is ever returned when filtering by MAC address.
Bug: 62487084
Change-Id: Ic7cc6affc0648ad85b15620e8c3aba4b9fc91aa1
SearchView's focus should be preserved when entering or exiting
split-screen mode.
Fixes: 31444175
Test: Verified toggling split-screen preserves the focus.
Change-Id: If3a11a6877b4d091ac0559a5cc8775eef071de40
When the system detects a night mode change, it will reload the
resources and relayout the notifications.
Also, allow the text in the Notification to take night mode into
account. Add configuration to allow Android Auto embedded to not tint
certain elements of the UI.
Test: booted on phone and Android Auto headunit
Bug: 33210494
Change-Id: I261813e5795b047bdfc4f77b88e1b01cc72e3216
We normally prevent apps from allocating into the "reserved" cache
space, but this change makes an exception for an active camera app,
since the user is probably trying to capture an important memory.
This change only lets the active camera app clear up to half of the
reserved space, since we don't want to completely destroy the
experience of all other apps.
Test: manual app before/during/after active camera session
Bug: 38267830
Change-Id: Ie9e63884fb2638ca881e10b894629eea84601648
- Move the bounds animation onto the animation thread
- Remove existing code referencing the old sf-vsync choreographer
- Add ability for ValueAnimator subclasses to reference a different
AnimationHandler, which uses a different FrameCallbackProvider with the
sf-vsync choreographer in the animations that require it
- Ensure that PiP touch events are batched and sent aligned with the
sf-vsync
- Move GC onto its own thread to not block other BackgroundThread calls
Bug: 36371375
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: bit FrameworksServicesTests:com.android.server.wm.BoundsAnimationControllerTests
Test: go/wm-smoke
Change-Id: I6a41b35a4e4d4d6dbea82c2673452825fe3ffa58
Create a BatteryStatsWorker that internalizes the stats collection,
and returns a Future<?> so that uses-cases requiring synchronous
results can still wait on the async task.
Bug: 37645919
Bug: 38296815
Test: manual
Change-Id: I5b935e1877d9a17d2617f01478faa77e8a52a258
