onServiceDisconnected method after unbinding the service
Bug: 155120232
Test: atest BluetoothHostTest#testMapClose
Change-Id: I324b4ea6654261eb67d5ec184f6b3456ba3d1aa4
This allows listener know task's orientation request change before
handling display rotation through IDisplayWindowRotationController if
they can register a local TaskStackListener.
Bug: 150409355
Test: atest WmTests:TaskStackChangedListenerTest#testNotifyTaskRequestedOrientationChanged
Change-Id: Id7bfc3e63329ce26d454b7e9c143e084e04dd365
* Before this change, the suggestionRoot would intercept all touch
events so that it can optionally forward them to the IME process
to support scrolling, no touch event will be sent to the child
view through the regular event dispatching process.
* With this change, we move the touch event transferring (to IME)
logic from SuggestionRoot's onTouchEvent to dispatchTouchEvent.
Now the touch events before a scroll is detected will be sent to
the child chip view, and only the touch events after a scroll is
detected will be sent to the IME.
* This patch also move the OnClickListener and OnLongClickListener
from the root view to the chip view, since the touch events now
either goes to the chip view or to the IME process.
* Note that in order to achieve this, given that we can't change
the API, and there is existing OnLongClickListener registered
to the chip view, we have to add a @hide API to the View to
get the existing OnLongClickListener and attach a new one to the
chip view, such that we can do the additional work of sending
the long click event to IME, when the view is long clicked.
* This patch should also fix the a11y talkback mode bug where
double-tapping on the view doesn't autofill the value.
Double-tap and hold also works that it triggers the attribution
dialog.
Test: atest CtsAutoFillServiceTestCases (sanity test)
Bug: 155245913
Bug: 154149807
Change-Id: I6f7be1ea5c0955969abb4ccae0cb421423095c4d
Previously, we generally required fully qualified names for referring
to inner class constructors (like #Notification.Builder()) despite that
not being valid javadoc. Now, we properly support #Builder() syntax and
the old syntax will error.
Bug: 6963924
Test: make doc-comment-check-docs
Exempt-From-Owner-Approval: cherry-picked from master
Change-Id: Ib2e4360493275b79c72487ee1cb173bb5e0fd35f
Merged-In: Ib2e4360493275b79c72487ee1cb173bb5e0fd35f
(cherry picked from commit 4c4aa41272)
These were previously being suppressed by doclava but with this change,
all failures are fixed and the suppression logic has been removed.
To fix the issues, there were a few possible changes made:
- broken reference to a public API (such as incorrect parameters): fixed
- unnecessary @link inside an @see tag: fixed
- @see referring to an @hide or @SystemApi: reference removed
- broken references to inner class constructors
- worked around by fully qualifying the constructor
Bug: 6963924
Test: make doc-comment-check-docs
Exempt-From-Owner-Approval: cherry-picked from master
Change-Id: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
Merged-In: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
(cherry picked from commit e0624c7a40)
There are specific cases where a package should be ignored by
whoever is parsing it, either because the device was configured to
ignore it, or the device doesn't support it.
While mostly used for testing, this adds a skip method to
ParseInput and a matching install error code to explicitly express
this case during parsing.
Bug: 155420149
Test: atest com.android.server.pm.parsing
Change-Id: I7eff53544341e21108d9d027f3afe75a1e845f40
To prevent low-priority refresh rate considerations from overriding the
app frame rate as specified via the new setFrameRate() api, split the
display refresh rate range into "primary" and "app request" ranges. The
primary range includes the low priority considerations, while the app
request range removes two lower priority considerations.
In general, surface flinger will keep the display refresh rate within
the primary range, but layers with frame rate settings via the
setFrameRate() api may cause surface flinger to pick a refresh rate
outside the primary range. Surface flinger will never choose a refresh
rate outside the app request range specified by display manager.
Bug: 148978562
Test: - Added a new unit test to DisplayModeDirectorTest to verify that
display manager strips lower priority considerations when
deciding the app request range.
- Added a new unit test to RefreshRateConfigsTest to verify
RefreshRateConfigs handles the primary vs app request range
correctly.
- Manual test: Confirmed that with the "force 90Hz refresh rate" option
turned on, we don't switch to 60Hz when playing a 60Hz video.
- Manual test: Confirmed that with the "force 90Hz refresh rate" option
turned on, when an app calls setFrameRate(60), we stay at 60Hz.
- Manual test: Modified a Pixel 4 XL to prefer 60Hz in low brightness,
entered low brightness, and confirmed we don't touch boost to 90Hz.
- Manual test: Confirmed that Maps stays at 60Hz on Pixel 4.
- Manual test: Turned on verbose logs in RefreshRateConfigs.cpp,
confirmed they look good.
- Manual test: Inspected dumpsys output, confirmed the primary and
app request refresh rate ranges are printed correctly.
Change-Id: I2a7f5ded0831c90b9b1ac09d941963a63b824098
Clean up various code paths to correctly use the "packageName" option to
limit its output to only information about that package.
Also do a little re-arranging of the output to cleanup a bit recent
stuff that was added, so the end of the output is still the important
high-level summary of process states.
Bug: 155437855
Test: manually inspected various "dumpsys activity" output.
Change-Id: I2ebe6f7ab3d433281993eb3959d375e2e53e0df9
