ag/1542219 introduced a regression where if the display was the default
display, the configuration would still be adjusted as if it were
a non-default display. This fixes that logic to only adjust the
configuration if the display is non-default.
Bug:32133693
Test: cts-tradefed run cts --module CtsServicesHostTestCases --test android.server.cts.ActivityManagerAppConfigurationTests#testConfigurationUpdatesWhenRotatingToSideFromDocked
Change-Id: Ib2fda8c1651609efa9d20b3e2dace8a122864916
Fix a bug where the DisplayMetrics wouldn't be updated for a Resources
object on the default display. Since multi-window, we want to update
all Resources.
This didn't always manifest itself due to recreation of assets, which
would force an update of DisplayMetrics. Re-use of an AssetManager from
the cache would expose the bug.
Bug:32133693
Bug:31998629
Test: cts-tradefed run cts --module CtsServicesHostTestCases
Change-Id: Ic51ab82710517b87eb995ccf982085dba876ad58
To a notification listener, snoozing will appear as a cancel
(with reason snoozed) followed by a post (when the snooze period
ends).
Apps can repost a snoozed notification, but the updates will not be shown
to the user until the snooze period ends.
Snoozing is canceled if the posting app or a notification listener
cancels the notification.
Any notification listener can snooze a notification. Technically apps
can snooze their own notifications also, though that's not public.
In this iteration snoozed notifications will be lost on device reboot.
Test: included. Also, various post, snooze, update, cancel tests with
a listener.
Bug: 30997603
Change-Id: I568a6448196f0992a17d20a4dac296321ec5092b
Ignore every filesystem entity that is not a regular file or directory.
In particular, we now ignore not only symlinks but also sockets, pipes,
et cetera.
Bug 32143362
Change-Id: If51b54df1f7a643af145eb15bf12d389d19f8780
The copy constructor of Notification.Action.Builder did not copy
the mAllowGeneratedReplies field.
Change-Id: I40fbe8950ee2232e2589ab3930a32bfbebe9fc89
Fixes: 31766718
Test: runtest --path $T/cts/tests/app/src/android/app/cts/NotificationTest.java
The admin can instead use the value of 0 to reset to default.
Test: runtest --path frameworks/base/services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Bug: 31430135
Change-Id: I0d6b29ca4eca65d7ca72a8975a0c28c9050a946c
(cherry picked from commit 943aabd11c)
The admin can instead use the value of 0 to reset to default.
Test: runtest --path frameworks/base/services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Bug: 31430135
Change-Id: I0d6b29ca4eca65d7ca72a8975a0c28c9050a946c
MessagingStyle expects the field userReplyName to be non-null, but the
documentation doesn't describe it as such. This updates the documentation
to say the field is required, and adds a NonNull annotation.
This has no behavior changes.
BUG:31747744
Change-Id: If832d059c276e856fba366dabfa8a5821bb63054
Problem as introduced in the refactor to change how configuration works
in activity manager in ag/1460784. With the new change we don't call back
into window manager to set new configuration if there are no changes.
The new change is correct, however window manager was relying on this to
unfreeze the display since the rotation changed.
We now have activity manager return if it updated the configuration to
window manager when the rotation changes do window manager can decide
if it needs to perform additional actions like unfreezing the display.
Bug: 31916697
Test: CTS and Manual testing.
CTS: cts-tradefed run commandAndExit cts-dev --module CtsServicesHostTestCases --test android.server.cts.ActivityManagerDockedStackTests
Manual: Launch an app that suports all orientations and rotate it from
landscape to seascape.
Change-Id: I36ddeff1ccc9f6089227147b117a865571b8571e
When we dismiss the dialog as opposed to hide it, it is removed
from the local WindowManagerGlobal's list of ViewRoots. Thus it stops
receiving configuration changes. When first adding a ViewRoot it will
pull the configuration from the context, but in this case
we are reusing one which has already been added and removed
and no such action will occur.
Bug: 31004614
Change-Id: Ie247bcf1a14caf4a42413c6813e337aa4c88e3e4
Bug 29992842
This is the same thing we do in ActivityThread#deliverResults
before calling Activity#dispatchActivityResult.
Test: Ic5510f1b3c3c453ca9035b167ce5379e9023be20
Change-Id: I3bb94572f13d8c9a7537dfa51e436702c00f5701
