CLOSE_SYSTEM_DIALOGS may not be sent if the user turns off and on the
screen quickly, resulting in systemui dialogs being displayed over the
lock screen. Dismissing these system dialogs when the SCREEN_OFF
broadcast is sent prevents this bug.
Change-Id: I097d0997d1538002b23bdd8f7aa32ecf4d32e0d4
Fixes: 78915648
Test: manual
@removed APIs are not part of the public SDK but we do not want
to block access to them. Use the recently added removed-dex.txt
list of @removed API signatures and merge it into the hidden API
light greylist programmatically.
Note that due to Doclava's rule precedence, @removed APIs which
override a public SDK method are considered public and are
whitelisted. We have to intersect removed-dex.txt with private-dex.txt
to satisfy the rule that light greylist is a subset of private-dex.txt.
Bug: 78182899
Test: make out/target/common/obj/PACKAGING/removed-dex.txt
Change-Id: I44e54c405fc667d54a990b9ded1de8456802545e
Since Ic5b5f6ca687db8b5d842f0ab20eac70f1fd2f85e, the magnifier can be
the child of a diffent surface than the one its content is copied from.
This initially led to much code duplication accross different methods,
making the code quite difficult to understand. This CL performs a small
refactoring, removing some of the TODOs and making the code a bit
cleaner.
Bug: 78876353
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Ifa26f94ba2e4983446f058f016af6010c1017ea7
The position of the magnifier surface is always clamped inside its
parent surface. As of Ic5b5f6ca687db8b5d842f0ab20eac70f1fd2f85e, we are
always trying to make the magnifier surface a child of the main
application window, if possible (before, if the magnified view was a
SurfaceView, we were making the magnifier a child of the SurfaceView's
surface). However, the CL did not also update the clamping, continuing
to clamp to the SurfaceView space when the magnified view was a
SurfaceView (even if the magnifier was child of the main window). This
was making the magnifier window to be wrongly positioned on the screen
when the magnified view is a SurfaceView. The current CL fixes this.
Bug: 78876353
Test: manual testing
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I63f2b185f58e62e8ad6eadf788e641fb1de07b04
The CL fixes the magnifier's behavior when its parent window has
positive insets in its surface:
- we compute the content copy coordinates sent to the pixel copy request
relative to the surface the content is copied from. We were clamping
them inside the visible region of the magnified view as returned by
belonging to the view which is magnified. However, the method returns
coordinates relative to the window. Therefore, the CL offsets the
visible rectangle with the window insets, to account for them.
Otherwise, when the insets were non-zero, on a text line we were
allowing the magnifier to display content from the left outside of the
text line, while a certain region at the end of the text line could have
never been magnified
- when clamping against the visible view region, when the surface we
copy from is a SurfaceView, #getGlobalVisibleRect is still returning
coordinates relative to the main window, whereas the coordinates we are
trying to clamp are relative to the surface of the SurfaceView. In order
to make the visible rectangle relative to the surface of the SurfaceView
instead, this CL negatively offsets the visible rectangle with the
SurfaceView position in the parent surface
- the selection/insertion handles are hidden when they overlap the
magnifier. To check this, we intersect the magnifier rectangle with the
rectangle of each handle. However, when we were performing this check,
the magnifier rectangle was relative to the surface, whereas the
handles' rectangle was relative to the main window. The CL negatively
offsets the magnifier position with the surface insets, to make both
rectangles relative to the window.
Bug: 78621162
Test: manual testing
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I0d749c1abb38520fe8fc477d22d6523f470e9abc
Currently when the user taps on a smart reply button from a locked
screen, we ask for a pattern/password and then close the notification
shade. This is inconsistent with the unlocked case and with how inline
replies are handled.
Set mLeaveOpenOnKeyguardHide to true when handling smart reply clicks.
Also simplify and rename the method in KeyguardDismissHandler to make
this new behaviour clearer.
Bug: 77841506
Test: Tap on a smart reply from the lockscreen, then unlock.
Change-Id: If1dab2a4b0d93a512c27e6d8a870289f64c7b63d
CL Iba8869ce6e4f401a8e420ad83ab459d25bbbaae0 added Doclava support
to generate a list of @removed API. Add a rule which builds that
list.
Bug: 78182899
Test: make out/target/common/obj/PACKAGING/removed-dex.txt
Merged-In: Ifa912f8751025b7de24a982a1a227a9c27d18267
Merged-In: I80860c2b9f7213db65d0a9ca65bd645187aa0ce0
Change-Id: I688c14e0d2fbfafe9ac212e6abdc3593cb744ef9
The view parent of "Clear all" button's view parent is FooterView.
FooterView has the paddingEnd that is 8dp. The "Clar all" button's
view parent is a Framelayout with android:layout_width="match_parent".
Because the layout parameter of Framelayout tells FooterView
"match_parent" and FooterView's super class is ExpandableView doesn't
consider the FooterView's paddings, the "Clear all" button right
boundary is cut off by FooterView.
To use paddingStart + paddingEnd instead of 0 padding in the onMeasure
phase. After considerating the padding of Expandableview-self padding,
the children of ExpandableView doesn't have the wrong drawing area.
The left boundary of "Manage notifications" should align with the left
bottom round corner end of the notification list. The first charactor
of "Manage notifications" should align the any of the first charactor
of the notification. The alignment is 16dp defined in
notification_content_margin_start.
The right boundary of "Clear all" should align with the right bottom
round corner end of the notification list. The total of padding that
counted from right boundary of notification list to the right text
boundary should be 16dp defined in notification_content_margin_end.
Bug: 77631994
Test: atest SystemUITests
Change-Id: I64a3489891bee993a1a2a0fd29e8d65823a36d63
Have the captive portal app and the MMS service use this new permission
to bypass private DNS.
Bug: b/78494660
Test: manual: captive portal login & MMS sending works
Change-Id: I0a4a8d0105becf6957fd44099bd84eca51e6716f
Introduce new app op mode that uses uid state to determine whether
the caller has access. This will determine what noteOp() and
startOp() return, based on the state of the uid.
Bug: 78480444
Test: atest FrameworksServicesTests:AppOpsServiceTest
Test: atest CtsPermissionTestCases:AppOpsTest
Change-Id: I12b744b74f3129782dbda9567043f5170919b5d3
Merged-In: I55fd74023cc4dae8151372e28c3afc7d259c7a1c
When using 3rd party launcher, the home stack is not merged with
overview then when minimizing, it will not be secondary split screen
stack. Then the primary stack will be presumed invisible even though
it is on the screen. The added check will make sure that the docked
stack is visible when minimizing.
Test: use 3rd party launcher, minimize
Change-Id: I5837ac6339352cae926c970f7453f5564abafb70
Fixes: 77818300
Wallpapers were barely visible on lock screen because value was set to
70%. The unlocked scrim (on the notification shade) was kept at 70% to
improve readability.
Also fixed a bug where scrim opacity wouldn't be overridden via overlay.
Bug: 63868547
Test: visual
Test: atest ScrimControllerTest
Change-Id: I17f277c917dc55604762420c0027b552993f1916
Adding the tile to your active set will start a continuous memory tracker,
updating the tile every minute with the latest pss value. Tapping the tile
will pull a full heap dump, zip it, and share it via ACTION_SEND.
Additionally, @integer/watch_heap_limit can be set to the heap size (in KB)
at which ActivityManager will automatically generate a heap dump and notify
the user when it's ready.
Available only on IS_DEBUGGABLE builds. Supplies limited. Order now!
Bug: 76208386
Test: atest com.android.systemui.util.leak.GarbageMonitorTest
Test: runtest systemui
Change-Id: I0434dd7dc330784c750469b013e40b31ef92638d
Ensure QS tile columns are symmetrical for LTR and RTL layouts. Also
ensure that opening QS customizer does not shift tile positions.
Change-Id: I647e5af41ed505ed01420d8b735652bd80a1661e
Fixes: 79110384
Test: visual
When packages or components are enabled/disabled, PackageManager
broadcasts ACTION_PACKAGE_CHANGED. Currently, overlay paths are being
updated whenever this action is recieved, but this is cauing black
screen flashes because the active apps are having their overlay paths
reconfigured.
This change makes it so only overlays becoming enabled or disabled cause
the overlay paths to be updated.
Bug: 78508043
Test: Tested Instagram, adding a fingerprint, and adding a new user and
observed no screen flashes.
Change-Id: I3168f4a1e7187c8c1659fb169bae841783b7279f
