When we freeze the screen, we really don't want the overlay to appear
on the screenshot - otherwise this will lead to it rotating with the
screen content. This means the overlay currently disappears during the
transition. We cannot just draw it over the screenshot, because it
might be in inconsistent state.
We fix this by temporarily undoing the effects of the screen rotation
transform on the overlay's window token. Then, once the window has
performed relayout and is redrawn in the new orientation, we switch to
that representation. This is mostly seamless rotation, with the
difference that we force it always, and it must also work for 180
degree rotation (which regular seamless rotation does not).
Do not merge, because we want to harmonize seamless rotation and the
newly added forced seamless rotation in Q.
Also move the rounded corner overlay from the display overlay layer
to the root of the hierarchy such that it can draw over the screen
off animation's ColorLayer.
Bug: 79112140
Test: Enable display cutout overlay, rotate phone to all orientations, ensure that emulated display cutout never flashes or disappears.
Test: atest CoordinateTransformsTest
Change-Id: I90451c14dc28daa3f90a74c3117548fead25af3f
With the introduction of the surface hierarchy, the seamless rotation
behavior in WSA is no longer correct: it also applies the WindowState's
offset, which leads to that being applied twice.
Instead of doing that, we simply rotate the WSA surface within the place
that WindowState dictates now.
Finally, the location of the WindowState itself also needs to be
transformed into the new orientation.
Fixes: 109927566
Test: atest CoordinateTransformsTest
Test: atest 'WindowStateTests#testSeamlesslyRotateWindow'
Change-Id: I9fb27a0a8a2bddc6ec88a4fcce6d6ea00929fb91
This is sufficient to wire up time detection from telephony
to the new service without breaking time detection.
This cherry-pick contains a small change: to use
SystemClock.elapsedRealtime() instead of the newer
SystemClock.elapsedRealtimeClock() with Clock.millis().
Bug: 78217059
Test: atest FrameworksServicesTests:com.android.server.timedetector
Test: atest FrameworksCoreTests:android.util.TimestampedValueTest
Merged-In: Id7175878dc22e5272c31f3e478af4b0e4183b62b
Change-Id: Id7175878dc22e5272c31f3e478af4b0e4183b62b
(cherry picked from commit 24836bfb15)
This is a do-nothing TimeDetectorService that can be
populated in following commits. A temporary method has been
added so the service has one method.
Unit tests can be run with:
atest FrameworksServicesTests:TimeDetectorServiceTest
Test: build / boot
Test: See above
Merged-In: I9e4eac70b944441f34491315cd1ce7fa2b9ae150
Change-Id: I9e4eac70b944441f34491315cd1ce7fa2b9ae150
(cherry picked from commit feeee682a2)
There's always been a possibility for IME to be visible even after the
screen was turned off. This was normally harmless because the IME was
placed behind the lock screen. The lock screen was opaque so it would
cover the IME, even in the case with AOD. However, with AOD live
wallpaper, the lock screen can now be transparent. This causes the IME
to be shown in between the wallpaper and lock screen.
To prevent IME from showing, several things needed to change.
1. The flag that was sent from sysui to AM is now propagated to WM. If
AOD is showing, IME should be hidden.
2. That flag sometimes is not a guarantee because AOD could be exiting,
but still shown on screen. Instead, also rely on the
mWindowManagerDrawComplete since that's only true when the windows have
completed drawing. The IME only needs to be shown if the other windows
on screen have drawn.
Test: Open IME and allow screen to timeout. When AOD turns on with
live wallpaper, IME is hidden.
Test: Within 5 seconds after AOD is turned on, turn screen on. Screen
turns on without IME flicker.
Fixes: 79658086
Change-Id: Ife93bdfde8ba2914930497356c0e16ebd629c507
In ActivityStackSupervisor#ensureVisibilityAndConfig() we first
update visibility of all activities to be able to properly calculate
configuration on the next step. However, we need to make sure the
latest config is applied whenever a client becomes visible.
To prevent making making activities visible without latest config
this CL defers messages to client in first visibility calculation
pass.
Bug: 76011287
Test: ActivityLifecycleTests
Test: ActivityManagerAppConfigurationTests
Change-Id: I978fc800322fb502545650b9f2eece96cd9c7f40
If an app crashes during Keyguard transition, make sure to keep
Keyguard transition
Test: AppTransitionTests
Test: go/wm-smoke
Change-Id: I80b80952f93d2b5611754f05a3dc333905cd1c86
Fixes: 80132133
* changes:
Force-update the orientation of before sending to client
Update visibility and config at the same time
Don't update configuration for invisible windows
Don't let top activity to influence the orientation
OpEntry.duration was being used to indicate that the
operation was still running if -1 is returned. A recent
change caused a regression.
Adding a new mRunning field in OpEntry to explicitly
hold the running state, even when partial duration is
updated.
Change-Id: Ib29f4c903f990aaa202e84f964959aedfc24abdb
Fixes: 80242152
Test: atest FrameworksServicesTests:AppOpsActiveWatcherTest
Test: Launch maps and verify the location icon is visible
in the status bar
Due to earlier refactorings, now allow-in-power-save-except-idle apps
are getting the flag ALLOW_WHILE_IDLE_UNRESTRICTED, which should not
happen. Restricting to user whitelisted app ids as was the case in O.
Test: atest com.android.server.AppStateTrackerTest
atest android.alarmmanager.cts.AppStandbyTests
Also, manually,
adb shell cmd deviceidle whitelist +<package-name>
Then verify the app id appears in App state tracker dump in
adb shell dumpsys alarm
Bug: 74773710
Change-Id: I6fdce33446e1374c6672ce98769aa8b5844effa9
An activity shouldn't influence the orientation of the device
just because it is currently on top, since it may be in the process
of being removed or covered by something else.
Bug: 76011287
Test: ActivityManagerAppConfigurationTests
Test: AppWindowTokenTests
Change-Id: Ie0660f9c935ab95100c107fa1331ef1c10898626
This reverts commit c50f47d970.
Fixes: 79465234
Reason for revert: Google still does it using private APIs and apps were relying on this behavior, not good for the ecosystem.
Change-Id: I62e2b4cd1e6e562fcdd89c97e599bcdade83381a
Exemption given to a sync request made by a foreground app (including
PROCESS_STATE_IMPORTANT_FOREGROUND).
At the schedule time, we promote the sync adapter app for a higher bucket:
- If the device is not dozing (so the sync will start right away)
promote to ACTIVE for 1 hour.
- If the device is dozing (so the sync *won't* start right away),
promote to WORKING_SET for 4 hours, so it'll get a higher chance to be started once the
device comes out of doze.
- When the sync actually starts, we promote the sync adapter app to ACTIVE for 10 minutes,
so it can schedule and start more syncs without getting throttled, even when the first
operation was canceled and now we're retrying.
Test: atest cts/tests/tests/syncmanager/
Test: Manual test with "requestsync -f" and "am set-standby-bucket", while checking
"dumpsys usagestats"
Test: settings put global app_idle_constants \
exempted_sync_scheduled_nd_duration=1,exempted_sync_scheduled_d_duration=2,exempted_sync_start_duration=3
and check "dumpsys usagestats" and make sure the constants are properly updated.
Fixes: 72443754
Change-Id: I233d8e4be85769150830bac798abc04810f4cc7b
If a profile or device owner is present, package manager does not
support calls to PM#setPackagesSuspended. So if there were already
suspended packages, they need to be unsuspended when a PO or DO is
added.
Test: atest com.android.server.pm.SuspendPackagesTest
Bug: 79980390
Change-Id: Ib79d95ccc25eef534fdcd540d3d6ea75c31982a7
ColorDisplayService doesn't start listening for changes until the end
of user setup, and color mode was previously unintialized at service
setup, so restored settings were ignored.
Bug: 79591550
Test: atest FrameworksServicesTest:ColorDisplayServiceTest
Change-Id: I00baed15e1248572d3dfd8f251dee7dc5a355a6c
Settings passes null into getHashFactor() when a profile user has
unified challenge. In this case getHashFactor() needs to derive the real
profile password before it can calculate the hash factor.
Bug: 80077655
Test: runtest frameworks-services -c com.android.server.locksettings.SyntheticPasswordTests
Change-Id: Ifa1d88818b58f914fd3560bb6ef44012facde87b
Fixes an issue where input intended for the keyguard could end up going
to a different display.
To prevent this, make sure that only the default display can get focused
when the keyguard is showing.
Change-Id: I6463c44aedca06930d2c9bda7c45ffd93141308c
Fixes: 71786287
Test: atest DisplayContentTests
Also fixing method for requiring both MANAGE_USERS
and INTERACT_ACROSS_USERS_FULL permissions.
Fixes: 80001332
Bug: 25935510
Test: unit test
Change-Id: If10166b4379ddc6a5f004eab77fa1f93abf6ac2a
Updates that change notification text will only be counted if the
user sees the update, so apps that are silently keeping their
notification data fresh will not be punished.
Test: runtest systemui-notification
Change-Id: I3d494417e92296ad9a1742db2ab949132ebac18f
Fixes: 78643290
Don't constantly get the current assistant/home, only get them when
we expect we may be out of date.
Test: uiservicestests
Change-Id: I60226f57b3788dac63609f7cc9a5a4b72cfce7a6
Fixes: 72749787
When backing up network policies, we write null for policies that are
null or are inferred. When restoring, this sends null policies to be set
which results in a NPE.
Bug: 79961560
Test: 1) atest NetworkPolicyManagerServiceTest
2) Manual: adb restore using backup set with null policies does not
crash
Change-Id: I450685e38acae0658ea984b86ca8b17ca27a71a6
Incoming and outgoing call phone numbers are visible in the phone state
broadcast and via the PhoneStateListener. To enhance user privacy, change
to require the READ_CALL_LOG permission in order to receive the call
phone numbers.
This means to see phone numbers:
1. android.intent.action.PHONE_STATE - requires READ_PHONE_STATE and
READ_CALL_LOG permission.
2. PhoneStateListener#onCallStateChanged - now required READ_CALL_LOG
permission.
To support this new behavior, added sendBroadcastAsUserMultiplePermissions
method to context to allow sending the broadcast to all users while
requiring the two permissions.
Bug: 78650469
Test: Created PHONE_STATE broadcast receiver in test app and verified that
when no permissions are granted, the phone number is empty for incoming
and outgoing calls.
Test: Granted Phone state permission to test app and verified that phone
number is not populated.
Test: Granted test app read call log permission and verified that phone
number is populated.
Test: Created PhoneStateListener in test app and verified that when no
permissions are granted, phone number is empty for incoming and outgoing.
calls.
Test: Granted read call log permission to test app and verified that both
the incoming and outgoing numbers are populated.
Change-Id: I857ea00cc58a0abbb77960643f361dd6dd9c8b56
ActionBarOverlayLayout used to drop WindowInsets, extract the content insets
as a rect, and then dispatch a modified rect to the content view; this because
there was no way to retarget the WindowInsets to the content view, and the
WindowInsets were not truly immutable. That means however, that other kinds of
insets than the content insets do not get dispatched, such as the display cutout.
To fix this, we add APIs to inset WindowInsets, make them immutable. Note that
a similar change is needed for the support lib.
Bug: 79733300
Test: atest ActionBarOverlayLayoutTest
Change-Id: I6a69d8462163ca5e66fdb53f83def6bc4063f8aa
UPDATE_APP_OPS_STATS lost the privilege to change app ops modes, so we
need to add this permission to the tests.
Test: atest com.android.server.job.BackgroundRestrictionsTest
Fixes: 79887147
Change-Id: I085c522cf3969a4cd7de7c47209eb83225b34254
Apparently comparing Spannables is dangerous because
the various Span classes do not implement .equals() in any
meaningful way, so all CharSequences must be converted to
flat Strings before being compared.
Lots of additional debug code remains, for the next time we
don't understand why an innocuous notification update
appears to be interruptive.
Test: atest com.android.server.notification.NotificationManagerServiceTest
atest com.android.server.notification.NotificationTest
Bug: 78643290
Change-Id: I1c282238687f28b5b197e28a4b878dc697049f4d
- When relaunching an activity in an existing task, allow the recents
component to launch all activity including those that are not exported
(since the recents component can not have START_ANY_ACTIVITY).
Bug: 73068266
Test: Open facebook, hit back to end the task, and try and relaunch from
Overview
Change-Id: I45e7ce339f83aadfb5a7faf5af51df97dd1414a5