In current design, entries with zeros are preserved after
addition/subtraction. These entries are not very useful
and lead to difficulty of verifying the result of
addition/subtraction.
However, change the behavior in the original NetworkStats
is considered risky in current stage.
Thus, this change provide a function that could remove these
empty entries in tests.
Test: atest FrameworksNetTests
Bug: 152827872
Bug: 150644692
Change-Id: I40a76935d55712b8083ee1e17e137a8a4ef5e029
Merged-In: I40a76935d55712b8083ee1e17e137a8a4ef5e029
(cherry picked from commit 6c7bef3064)
If the app user quick switches to is of a
different orientation than that of previous
app, draw a home handle in the previous
orientation so user knows they can continue
swiping there.
Fixes: 150250451
Test: QuickSwitched between apps of different
orientation and saw that it home handle is
drawn in old orientation.
Change-Id: I743e7d3d31b250124c402bed203b3b37c8cfeb26
- If the task is previously not visible or has no visible children at
the point when we start controlling it in the task org, hide the task
until we send taskAppeared to ensure that the task org can reparent
and show it otherwise we could see a flash of the task.
This happens mainly from two cases:
- when starting a new task with a given win mode, we show it and wait
for first draw before notifying the task org
- when transitioning into pip from swipe up, the activity is hidden
and when it requests to enter pip is made visible again
Since we are hiding the task w/ the pending transaction, we also need
to defer all task org callbacks until that's applied to ensure proper
lifecycle of the calls.
- Also skip app transitions for task org tasks for now
Bug: 152809695
Bug: 152134460
Test: Open a bubble, ensure that we don't see the task in fullscreen
first. Enter pip, ensure that we don't see flash of the task
before SysUI can fade it in.
Test: atest PipAnimationControllerTest
Test: atest TaskOrganizerTests
Test: atest SplitScreenTests
Change-Id: If51e98cd007faef35e99acd31b27b20eebbea010
am skip reason: Change-Id I22182d90b0057df67fbd6d20785da23d6c17dcf3 with SHA-1 c8048daed2 is in history
Change-Id: I0d5375b98bac66de51cfe1a5398ca591f3a31562
Once a new Request is in flight, we probably don't want to display the
old responses.
This prevents a VIEW_ENTERED flow from displaying the suggestions
(either as a dropdown or as inline chips) if there is a pending request
for the same partition. Thus fixing a bug where the suggestions may be
rendered twice - once from the VIEW_ENTERED update and again from the
Fill Request succeeding (see http://b/152620157#comment7). An example of
how this may occur:
1. User taps on a View that previously showed suggestions.
2. App manually triggers autofill, which issues a new fill request.
3. The Session is updated with VIEW_ENTERED (due to (1)).
Session#requestShowInlineSuggestionsLocked returns false because of the
pending request. The system fallsback to drawing the dropdown UI.
4. FillRequest from (2) completes. This hides the dropdown and shows
inline chips.
An alternative is to exit the VIEW_ENTERED flow when there's a pending
request for the same view. This should also fix the bug, but is no
longer necessary with the current fix. The advantage of the current
approach is that the VIEW_ENTERED update logic and the request logic are
less coupled.
Fix: 152620157
Test: manual
Test: atest android.autofillservice.cts
Change-Id: Id15887ffdf28d0a3ea32e1f68ffd81f994f93187
