Also refactoring the class to make it easier to test and
chaning behavior where the current behavior seemed poorly
defined.
Refactoring:
- Combined all handlers into one.
- Simplified animation to use a ValueAnimator.
- Eliminated ACCESSIBILITY_DISPLAY_MAGNIFICATION_AUTO_UPDATE
setting. Move rest of settings reading into mockable class.
- Move callbacks from WindowManager into the main class.
- Pulled out my instrumented Handler from the
MotionEventInjectorTest into its own class so I can reuse
it.
Behavior changes:
- Always constraining out-of-bounds values rather than
refusing to change them.
- Constraining offsets on bounds changes. We previously
left them alone, even if they were out of bounds.
- Keeping track of the animation starting point. We were
interpolating between the current magnification spec
and the final one. This change means the magnification
animates to a different profile.
Test: This CL adds tests. I've also run a11y CTS.
Bugs: 31855954, 30325691
Change-Id: Ie00e29ae88b75d9fe1016f9d107257c9cf6425bb
Test: Enable in SysUI tuner, drag PIP. This is only experimental to help
figure out what UX we want to keep.
Change-Id: I0d6f2f0c5909d6a76aae4a8fb84c5076f6996fdd
Test: Enable SysUI tuner, tap once on PIP to interact with the activity.
This is only experimental behaviour, and
android.server.cts.ActivityManagerPinnedStackTests will be updated
accordingly if we keep this behavior.
Change-Id: I278ab8c360c44718cfcac0fd761f476a875f9b15
There was some window animation jank because we ran a layout during
the animation, as the SysUI animations are slightly faster, so we
collapsed the window already during the animation which caused
a layout which caused window animation jank.
Bug: 32057734
Change-Id: I296f961be8cfc39b08859b7d3d41f1e81b2eaaa3
- Unifying logic to ensure that the PIP is moved consistently as its
movement bounds are shifted. This is done by adding a snap fraction
which is a fraction relative to one set of movement bounds, and applied
to a new movement bounds. This is flexible to work with all of the
current snap modes being tested.
- Fixing issue where you can drag out of bounds when touching the PIP
before the IME shows.
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testPinnedStackOffsetForIME
Change-Id: Ie68c1ca599f6196726b8224585974a0972b93701
Signed-off-by: Winson Chung <winsonc@google.com>
- Move SettingsLibTests to tests/integ
- Create a new robotests directory for SettingsLib.
- Add test cases for CategoryManager#backwardCompatCleanupForCategory
Bug: 32382487
Test: make RunSettingsLibRoboTests
Change-Id: I7ef5921ce8c47a3e1e7209be1abc97ea549a2378
Window tokens can now only be on one display, so we now require clients
that want to add/remove window tokens to specify the display they would
like the token to be created on. This simplifies the token handling code
in WM and will be useful moving forward for clients that want to add
windows to external displays.
Test: Existing tests pass
Change-Id: I6b2d8d58a913b3624f1a9a7bebbb99315613f103
- Detect whether an app is using old key, new key, or a mix of both.
-- If app is using new keys, skip. They are already in the new IA.
-- If app is using old/new keys mixed, skip. Using both type of keys
implies the app wants to support old/new platform.
-- If app is using old keys only, map their tiles to new categories.
Bug: 32382487
Test: new unit tests
Change-Id: I3bbd09c531a97801dc382661a8bb10d0391bc177
* changes:
The big keyguard transition refactor (6/n)
The big keyguard transition refactor (5/n)
The big keyguard transition refactor (4/n)
The big keyguard transition refactor (3/n)
The big keyguard transition refactor (2/n)
The big keyguard transition refactor (1/n)
Durring a connect call disconnect from all other pbap devices rather
than from the device you are trying to connect to.
bug: 28406739
Change-Id: Ic0b651f32a0da18950fbc190b1d4503d69ebd203
(cherry picked from commit bdd24942e47811ffe6bb9814934e6b08a8190e7e)
Add MAP client code into packages/apps/Bluetooth. Changes here are to
define the MAP MCE interface and enable its selection when running on a
device that is also running a PBAP client (Car Kitt).
Bug: 30467210
Change-Id: Ifa2cdea7d67f63a2b5f3d971df8ec6d321dc5fee
(cherry picked from commit 433b3054847951e8e7b3864d11990604a66b8651)
The provider now published a system service, through which you
can do direct shell commands. The commands are a copy of what
the existing "settings" command does (in a follow-up, that will
be converted to a simple script that calls this).
Also improved a few things in the provider:
- Don't allow implicit creation of settings data for users that
don't exist.
- Improve dump to include the package name that applied each setting
and remove misleading stuff from historical data (and this is now
available through "dumpsys settings" instead of the provider dump).
Test: manual
Change-Id: Id9aaeddc76cca4629d04cbdcbba6a311e942dfa6
Cleanup:
- Make sure all the state is nicely dumped.
- Remove some unused stuff.
- Fix a flicker when occluded -> unlocked
Bug: 32057734
Change-Id: Id87e26adccef740d608b325c2dc1f6db14dd4ec3
The heart of this change are two things:
1) Instead of using the force hide mechanism to hide windows behind
Keyguard, we actually make the activities invisible in activity manager.
2) When Keyguard is going away, we change the visibilities in activity
manager and run an app transition.
At the very core we move the responsibility of hiding activities to
ActivityStack, which checks whether Keyguard is showing, and then
hides all non-show-when-locked activities. For that, we need to check
whether any window of an activity has SHOW_WHEN_LOCKED set. We
introduce a callback from WM -> AM in case these Keyguard flags have
changed.
Furthermore, we decide whether to occlude Keyguard in KeyguardController,
which just checks whether the top activity has SHOW_WHEN_LOCKED set. When
this state changes, we prepare an occlude/unocclude app transition, and
in PWM we just inform the Keyguard about the animation so SysUI can play
along this animations in a mostly synchronized manner.
Since we now use an app transition when unlocking the phone, we get
lockscreen launch animations for free - window manager automatically
waits until the activity is drawn, or directly executes the transition
if there is nothing to animate. Thus, we can remove all the infrastructure
around "waitingForActivityDrawn".
The logic to show/hide non-app windows is moved to policy, and we add the
ability to run animations on non-app windows when executing an app
transition.
Test:
1) runtest frameworks-services -c com.android.server.wm.AppTransitionTests
2) Manually test unlocking Keyguard:
2a) Without security
2b) With security
2c) With security but trusted
2d) Portrait while activity behind is in landscape
3) Test launching things from Keyguard
3a) Without security
3b) With security
3c) Launch camera without security
3d) Launch camera with security
3e) Launch camera with securtiy and trusted
3f) Launch voice affordance
4) Set no notifications on lockscreen, drag down, make sure you get
the correct animation
5) Test clicking "emergency" on bouncer
5b) Test "Emergency info" on emergency dialer
5c) Test clicking edit button on emergency info, should show pattern on
Keyguard
Bug: 32057734
Change-Id: Icada03cca74d6a612c1f988845f4d4f601087558
- Apps cannot update their channel settings after creation.
- Importance is required when creating a channel.
- Some method name changes.
- Ranker can't modify fields a user has changed.
- High and Max importance mean the same thing.
- The default channel adopts app wide settings on creation.
- The default channel is limited to importance low once target api is post n mr1
unless the user changed it.
Test: runtest --path frameworks/base/services/tests/servicestests/src/com/android/server/notification
Change-Id: I73c449a6abe6d709046de79c5c54339cb2edf0b8
