beyond S people can not access the DATA_ROAMING API from Settingss.Ideal
way to use this is from TelephonyManager.
Test: manual.
Bug: 172467621
Change-Id: I5bbdd886599ff0ecf66eb72beb78456adc4d632c
Revert "Update smartspace shadow"
Revert "Update app icon shadows"
Revert submission 17935777-lightDarkDetection
Reason for revert: Talked with Adam Cohen, white shadows are controverstial and we'd need to escalate to senior UX if we want to ship. James would rather do it in U timeframe, will flag to UXers we work with that the opportunity to escalate is available if needed.
Reverted Changes:
Ia91221427:Update light/dark detection.
Ie12d3d054:Update app icon shadows
Icc88c3496:Update smartspace shadow
Change-Id: I7d6b972d29b328a7d5ca7ac7241156b6e51a2cd6
Or the smallest screen width dp could be the same as the
display size.
Bug: 230035382
Test: verify sw config of an embedded activity
Change-Id: Ic085c6ed134c2787a26fd2b02b4345b04fb693e6
Merged-In: Ic085c6ed134c2787a26fd2b02b4345b04fb693e6
(cherry picked from commit 9cee26e261)
While starting an activity with FLAG_ACTIVITY_CLEAR_TOP, the
existing activity could also be finished and therefore the new
activity is added on the same TF of the top running activity.
However, the top running activity could be on a TF which is
different from the cleared activity.
Bug: 233860721
Test: start Settings' shortcut activity
Test: atest TaskTests
Change-Id: I5607a2737e7d0d5986adf14f44f169791da3d38a
By the original design, we register the activity event in the
ActivityManagerService. After getting the activity event, we will
query current visible activities and report them to Assistant.
Assistant will start to get direct actions of those visible
activities. But sometimes they can not get the direct actions
due to the stage of activity lifecycle before onStart().
We will postpone the request direct actions a few times
before onStart().
Bug: 224789902
Test: atest CtsVoiceInteractionTestCases
Change-Id: If7cd52c5ba749523e575c0be5595e8f20704c4f2
Currently the cloned windows is avaialbe from window list,
however the node info from the cloned window is incorrect.
To avoid confusion, we would drop them for a short term solution.
Bug: 230300971
Test: manually test with switchaccess
adb shell dumpsys accessibility to observe the window list
Change-Id: I7a03376567698a493c9eb5e26d1f3390aacdb408
Even if the brightness is the same we still need to invoke any listeners
as just the act of setting the brightness has side effects, like
clearing the temporary brightness. Skipping these callbacks mean we can
possibly get stuck in a state where we don't adjust the brightness at
all until the next time a user touches the brightness slider -- this
persists even through screen off.
Fixes: 218600709
Test: Manual
Change-Id: I918636a61424a51f9d22d32fd692beb6eb2b8f2d
As IME window will be hidden by AsyncFadeAnimationController when
receiving IME show request in IMMS side during fixed-rotation.
we could remove the previous logic from CL[1] in case snapshot starting
window surface may not apply fixed-rotation when IME snapshot visible in
the first place, since in CL[2] has already removed the disable
fixed-rotation when animating snapshot starting window with IME visible.
[1]: Idfdf129adbfbee6634d8a27aa78da1f631bd213b
[2]: Iceaedbfdb75e68e9f7fb8fd4a1bf8f35a779797e
Bug: 230733128
Test: 1. Launch a portrait app which keeps showing IME. (e.g. Chrome)
2. Return to home be home key or swiping.
3. Hold the device in landscape.
4. Launch the app again.
The app should show in landscape directly and IME will
fade-in when it is drawn in landscape.
Change-Id: Ieb656aaa9f76d0f5dcc5487a6602e528ec771552
Remember the latest InlineSuggestionsRequestCallback coming from the
autofill service, so that its autofill session can be invalidated
when the IME process is unbound or stopped.
Test: atest InlineWebViewActivityTest#testAutofillOneDataset
Bug: 226240255
Change-Id: I49cf295b95cec33b7eb404eab62b900014d09e26
(cherry picked from commit 33dc7f89c8)
Merged-In: I49cf295b95cec33b7eb404eab62b900014d09e26
This reverts commit 012cace2ee.
Reason for revert: This CL depends on ag/17823648, which is not merged into qt-qpr1-dev.
Change-Id: I503bcc1e979dd4db941cb7754f63a0dc35ce9682
When creating a VirtualDisplay for a VirtualDevice, we need to do some
extra work like setting up for input injection, creating a
DisplayWindowPolicyController, and grabbing a wakelock to keep the
display awake. Some parts of this extra work end up calling back into
the DisplayManagerService from another thread, but since we're already
holding the mSyncRoot lock we sometimes get into situations where
those threads get blocked trying to acquire mSyncRoot, while holding a
lock that another thread ends up needing like the global window
manager one, so we get deadlock.
The fix in this CL is to break up the extra work the
VirtualDeviceManagerService needs to do into two parts: one part that
happens before the VirtualDisplay is created, and one part
after. Neither of these needs mSyncRoot to be held.
Fixes: 230544802
Test: atest CreateVirtualDisplayTest
Change-Id: I6a6e03f816567579510b3f1ef0705375549a3c88
