Fix to avoid showing a quickshare chip based on outdated information.
Resets the pending interaction if the user tapped the old quickshare
chip, since we won't get updated information for that chip.
A future change in QPR3 will fix the logic around retrieving the
quickshare data, so we don't hit this edge case in the first place.
Test: manual; verified that taking two screenshots in quick
succession that result in a quickshare chip no longer showed
two chips at the same time
Bug: 258732618
Change-Id: I70b4914068ee883c95345bbc8e3e04fc334394cf
The old method of removing unused subscriptions from the repo cache was
causing a CME
Test: DemoMobileConnectionsRepositoryTest
Test: MobileConnectionsRepositoryTest
Fixes: 261706421
Change-Id: I4977aa47591a7d4888c176e420cc1a0c7f783591
Check for either of the proto 1 or proto 2 flag to be enabled when
guarding logic that is common for both prototypes.
Bug: 260645044
Test: manual, build sysui, check desktop mode 1 works
Change-Id: Iba1d4f84032b1e059dcd100f64f20fec79e43113
The exact fix is the one line change in PipTransition. The example:
The landscape PiP activity is expanding to fullscreen portrait.
So at the end of animation, the task needs to keep the 90 degree
transform. Otherwise it cannot match the area of portrait display.
And then display will continue to update to landscape seamlessly
and the default finish transaction will reset the rotation transform.
The other changes are just small cleanup on the way.
Bug: 260925940
Test: Enable shell transition.
Use Chrome to play a Youtube video in fullscreen landscape.
Enter PiP mode by swiping to home.
Press the PiP window to expand to fullscreen landscape.
There should be no flickering by inconsistent orientation.
Change-Id: I241eb8fc59af4733794a0e0b4d4438e59edbfe10
We currently only need 2 bits from `SubscriptionInfo`: subscriptionId
and isOpportunistic. This CL moves those into a `SubscriptionModel`
class and updates all of the usages.
Test: existing tests
Bug: 249790009
Change-Id: I87686213e68b199b7d4c998f02d6687dcb276a27
Preivously, Keyguard would try to authenticate after a cancellation
too quickly so the HAL would drop the attempt.
Repro steps:
1. User press power key
2. Keyguard cancel 1st authentication and send cancellation reqeust to HAL
3. HAL is dealing with cancelation request
4. Keyguard runs 2nd authentication.
5. HAL report cancellation to keyguard and cancel 2nd authentication.
6. Fingerprint does not respond to user's touch.
Bug: 261565425
Test: atest KeyguardUpdateMonitorTest
Test: verified locally on device - attempt side FPS after pressing
the power button (on or off)
Change-Id: If84b8765622e47872b6492eaf09c0e46aeabdf27
Also rename `subscriptionModelFlow` to `connectionInfo`, which is more
clear given that `MobileConnectionRepository` is the provider of that
information.
This paves the way to remove `SubscriptionInfo` from our internal
representation in lieu of a `SubscriptionModel` based off of it
Test: tests in tests/src/com/android/systemui/statusbar/pipeline/mobile/*
Bug: 261029387
Change-Id: If4bd3e31d2f8a7400e31e4acd8776750eee22ad6
Move the entire lookup into `MobileMappings` to the
repository layer. So when network types come down, they are immediately
transformed into `ResolvedNetworkType` objects and given a key at that
moment, using the default mobile mapping config
This allows us to A) better insulate us from external depenencies and B)
implement a very trivial mapping for Demo mode. TBD on whether or not we
should allow switching to use the real mobile mappings implementation
Test: tests in tests/src/com/andrdoid/systemui/statusbar/pipeline/mobile/*
Bug: 261185097
Change-Id: I727ad3ca823f3eb225a56f371aa3cef46c340f57
One nuance of this is that a new keyguard session
will start if the user is on the lock screen and then
double presses the power button to launch camera due to the
following sequence of events:
[0ms] user is on the lock screen in KG session #1
[1ms] first power button press => device starts to
go to sleep, so new keyguard session begins KG session #2
[2ms] second power button press => camera is launched,
screen stays on instead of finishing going to sleep
Test: enable SessionTracker logs, see start and end
boundaries of Keyguard is update to include a new session
when the device goes to sleep
Test: atest SessionTrackerTest
Bug: 242628816
Change-Id: I40bdf7f746b7086bc9683f816e00913cd0fd49bf
Test: manual test on SFPS devices:
Switch to 2nd user and setup Fingerprint Unlock. SFPS indicator
shows at the EDU screen.
Test: atest SideFpsControllerTest
Bug: 259029157
Change-Id: I5cf464608032edf4fd07ee2bfb6b457616d19c1d
Merged-In: I5cf464608032edf4fd07ee2bfb6b457616d19c1d
(cherry picked from commit d40e081bd4)
Adds support for the new mobile pipeline's demo mode to the old front
end. Note that this is kind of hacky because we actually don't have to
do anything to support demo mode, since it's implemented entirely at the
level of the repository. However, due to the fact that the old
implementation of demo mode added a special view, `DemoStatusIcons`,
that overlays the regular icons, we have to suport the new pipeline in
_that_ icon container.
Test: manual
Bug: 249790009
Change-Id: Ib02a1eb6f6abaec113a15045f9bd0b151d2a773f
If asTaskFragment() is null, the window container can be
DisplayContent, DisplayArea, WindowToken, ActivityRecord.
Because DisplayArea and WindowToken rely on DisplayContent,
while ActivityRecord relies on task, only the parent container
of activity needs the crop.
Otherwise such as WallpaperWindowToken may be cropped unexpectedly
if it has a rotation transform.
Fix: 261704203
Test: Enable shell transition.
Launch landscape app and back to portrait home.
Wallpaper should not be half black.
Change-Id: Id262090c64814370e3f215acdf670d7b4d6ee1e9
Before, we always read the next app requested color. Now, we read the
backdrop color from next app requested animation, which is the requested
color if set, or the color in the animation XML if there is no override
color.
Bug: 241043533
Test: verify with resource color
Change-Id: I0687078a1cbcb46e71ab269059911072eb7046fd
This CL removes the old implementation of the QS footer actions. The new
implementation was turned on in http://ag/20139744 and didn't cause any
regression.
The tests that were removed in this CL are test cases that are already
tested in FooterActionsViewModelTest or FooterActionsInteractorTest.
Bug: 242040009
Test: atest QSFragmentTest
Test: atest QSSecurityFooterTest
Test: atest FooterActionsViewModelTest
Test: atest FooterActionsInteractorTest
Change-Id: I88413727a5f6ca37deea6333c411c1b9b7bffeeb
