* changes:
Fixed measuring of messages with excess space
Fixed the handling of oneToOne conversations for certain apps
Improved the messaging transformation
Implemented animations for messaging changes
Refactored clipping util to be used in core
Improved the headsup notification for messages
Redesigned the messaging style
Fixed a bug where images weren't transforming properly
Certain apps were using specific white-spaces in order to get
an effect they wanted on the old messaging style. We're now
fixing that to ensure that the transition is smoothed
Test: manual send messages using multiple apps
Bug: 63708826
Change-Id: Ie8628c5b394b974f3dfcbbc6f26a7f50bc60a7b9
Previously the heads up notifications and also the collapsed versions were not
displaying in the new style.
They are now displayed in the new style of heads up notifications.
Test: add messaging notification in heads up
Bug: 63708826
Change-Id: I041584cd6ee740fd8c59f332f727ed83c89e777f
The layout now looks much more recognizable
as a messaging template and enables us to
prepare for more useful functionality.
Test: Send messages and observe display
Bug: 63708826
Change-Id: I896b3692a1e84976e8fd37cf37611ddb1d358fb9
Until now, userdebug and eng builds have tracked StrictMode
violations on all system apps, including prebuilts that we have no
control over, which results in a lot of unactionable noise.
This CL narrows the set of enabled apps to only "bundled" system
apps, which gives us a much higher chance of burning these violations
down to 0 and keeping them there. We don't have a good proxy for an
app being "bundled", so we detect it based on being in the "android."
or "com.android." package namespace.
Clean up the entire flow of applying StrictMode defaults to make it
much more human-readable. This resulted in us fixing a bug where
StrictMode was never actually enabled for jank-sensitive threads in
system_server!
Relax I/O checks in a few places where we know we're interacting with
procfs or sysfs. Add internal "allow" methods that avoid object
allocation by returning raw mask.
Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.cts.StrictModeTest
Bug: 68662870
Change-Id: I536e8934fbcdec14915fcb10995fc9704ea98b29
showSlice was being called which would clear the content observer, instead
specify slice and reinflate within setSlice(uri) method.
Test: Have a slice, call notifyContentChanged on the uri, note that it
updates
Change-Id: I5ce8af2867114b9d053f1623bc4a47dfabe961fc
Allows a privileged app to set standby bucket states for apps.
Bug: 63527785
Test: adb shell am set-standby-bucket com.example.foo 0
Change-Id: I613f8872ae816e39b167aad1c289187362aa6094
Necessary information for a shortcut is label, icon, intent. This alters
how that information is retrieved from a Slice and falls back to using
the app icon / title / intent if any of the information is missing from
the slice ensuring that there is always an actionable shortcut.
Also adds notion of HINT_HIDDEN, allowing apps to exclude parts of a slice
from being visible in a template, note when creating a shortcut HINT_HIDDEN
is ignored.
Test: Manual with SlicesApp, test different varients of having HINT_TITLE
and not having HINT_TITLE on an action / icon / label as well as
not having an icon / label / or action.
Bug: 68378574
Change-Id: I1de9e502204dfb7fd83a7ec7622e8fd464146cfd
Allows a privileged app to set standby bucket states for apps.
Bug: 63527785
Test: adb shell am set-standby-bucket com.example.foo 0
Change-Id: I069546555e1b370247f8cd45b2f4c32e6abe15ed
On standalones, stay in vr mode until the Power Policy Service notifies
us it has switched to standby mode.
We still have a few issues elsewhere in the code, so the "stay in vr
mode" functionality is only enabled if the system property
"persist.vr.use_standby_to_exit_vr_mode" is set to true, which you can
do like this:
$ adb shell setprop persist.vr.use_standby_to_exit_vr_mode true
Bug: 65248224
Test: - Confirmed on a standalone that doffing leaves us in vr mode for
5 minutes, then we get a notification that we've entered standby, and we
exit vr mode. Confirmed we enter vr mode again when we don the device.
- Confirmed no behavioral change on phones, as expected.
Change-Id: I41d62761fe8c2fc7630f0615732453669cb25f06
This changelist removes checks that enforce that only fullscreen,
opaque activities may request orientation changes. An application
may itself be compatible with the change and update their SDK level.
However, it is possible they use a library that has not itself been
updated and still leverages this feature for non-fullscreen
activities.
Change-Id: Ie1d300e3531fc8c588d2124dea698e4a876713c2
Fixes: 68684796
Test: bit FrameworksServicesTests:com.android.server.wm.AppWindowTokenTests
- Move the task stack listener wrapper into the shared lib, along with some
other AM calls.
Bug: 67510855
Test: Launch recents
Change-Id: Icb5ea78ec42d4b76a1c531ce336dd9a3f07a9629
Tablets have the ability to dock to the right side in landscape. This
change supports minimized mode for right dock side.
Test: run-test CtsActivityManagerDeviceTestCases
android.server.am.ActivityManagerDockedStackTests#
testMinimizedFromEachDockedSide
Change-Id: Ie879bdf7bf74226c0ceda9295f9de2004fd6a9b5
Fixes: 68017311
LockTask was first designed to be single-task only. It was later
expanded to multi-task use cases in a rather flawed manner. Many aspects
of the implementation overlook the implications of more than one locked
tasks, and sometimes completely ignore the LockTask-unaware apps.
For example, LockTask-unaware apps are not registered in
LockTaskController's list of locked tasks, although they can be launched
in LockTask mode as long as they are whitelisted. As a consequence,
these unregistered tasks are not finished when their whitelist
authorization is removed.
In this patch, we make sure LockTask-unaware apps are also registered,
and introduce the notion of a root task, thus providing a genuine
multi-task experience with LockTask.
Bug: 66130096
Bug: 66132035
Test: bit FrameworksServicesTests:com.android.server.am.LockTaskControllerTest
Test: cts-tradefed run cts-dev -m DevicePolicyManager --test com.android.cts.devicepolicy.DeviceOwnerTest#testLockTask_deviceOwnerUser
Test: manual, by using TestDPC > Start kiosk mode
Change-Id: I68a26d2198fa3991f85ae1e7a6acae5981c34db5
Renamed a few functions related to moveTaskToDockedStack to use the new
notion of split screen primary windows instead of docked stack. Most of
the calls that use moveTaskToDockedStack are renamed.
Test: go/wm_smoke
Bug: 68017311
Change-Id: I73df051a9261d213b3415ac132962d91ec632e0a
- Only the recents component package can launch the overview activity
directly, and if an assist data receiver is provided, then assist data
will be proxied to the caller.
Bug: 67864419
Test: com.android.server.am.RecentTasksTest
Test: com.android.server.am.AssistDataRequesterTest
Test: CtsVoiceInteractionTestCases
Change-Id: Icdd7e6716a84c11e9262ce5453f7d39ae7d8ce77
- This logic will also be used when the recents component is started to
fetch assist data associated with the current activity.
Bug: 67864419
Test: com.android.server.am.AssistDataRequesterTest
Test: CtsVoiceInteractionTestCases
Change-Id: I4cb3c2536a104d7071bc0a1fd6e31dfc2c0ce8d0
This API is useful to improve the autofill performance for the scenarios where
the service knows it cannot autofill an app or activity.
Bug: 67867469
Test: cts-tradefed run commandAndExit cts-dev -m CtsAutoFillServiceTestCases -t android.autofillservice.cts.LoginActivityTest#testFillResponseAuthWhenAppCallsCancel
Change-Id: I58e3eb5714db840104e699d614e750c03e26e8ca
Fixes several issues with the way PendingIntents are being whitelisted
from background check with Notifications. Most visibly, this causes the
whitelisting not to work on Notifications that use the DecoratedContentViewStyle,
but there are some conditions where the whitelisting breaks for regular
notifications too.
- After a Notification is rebuilt with Notification.Builder, the set
of PendingIntents in the notification was not rebuilt.
This broke the whitelisting whenever a PendingIntent is added after
the Notification was already sent once. Workaround for broken platform
releases: always use a fresh Notification object, or clone before
sending.
- Fixes PendingIntent.writePendingIntentOrNullToParcel to invoke the
OnMarshalListener.
This broke whitelisting for any PendingIntents attached to custom
RemoteViews. Workaround for broken platform releases: Also attach
the PendingIntent to the Notification's extras.
- Changes RemoteViews to keep the parcel cookies that were present
during unparceling, such that they can be reapplied when it gets
cloned.
This broke whitelisting for any PendingIntents attached to a
DecoratedContentViewStyle *even if added to extras*. Workaround
for broken platform releases: none.
- Fixes Notification.whitelistToken mistakenly being static.
There's an unlikely race condition where the field could be
overriden with null by an incoming notification right as another
notification is sent out. Workaround for broken platform releases:
none.
Test: runtest -x core/tests/coretests/src/android/app/NotificationTest.java && runtest -x core/tests/coretests/src/android/widget/RemoteViewsTest.java
Bug: 68218899
Change-Id: I02e44040604a1d24422340611ae9e0332a611800
