This partially reverts the change that is suspected to be the cause of
b/117885969
This is to be reverted once the real cause is established.
Posting a temporary fix to unbreak the CTS test while figuring it out.
Fixes: 117885969
Test: atest CtsProviderTestCases:android.provider.cts.SmsBackupRestoreTest#testSmsBackupRestore
Change-Id: I7fd0b954d334501b050e9930643de4f6e41e229e
- Allow apps to learn if users chose the importance of a given
channel
- Allow the asst to query channels and channel groups of installed
apps
Change-Id: Ic65dfdc79d5135940c1debb101b849b5837d78b5
Fixes: 118140597
Test: runtest systemui-notification
Found two places where we forgot to remove TransitionListener in onTransitionEnd. I think it is important to clear it as if you reuse a transition object it will be leaked together with some views
Test: n/a
Bug: 64643817
Fixes in AndroidX: aosp/793641, aosp/795753
Change-Id: Iae0a9945a4158776f1a75c806c1f29efc049f96b
Add settingsSliceUri attribute for supporting live wallpaper inline-
control, public for AOSP live wallpaper to use.
Bug: 117200693
Test: atest tests/Internal/src/android/app/WallpaperInfoTest.java
Change-Id: Iffe9fbd9f49daf8a63d5745f91532de13b7288e3
When starting a process under instrumentation using this new
"--no-isolated-storage" flag, the process would be able to see the
full external storage.
Bug: 117229024
Test: adb shell am instrument --no-isolated-storage \
-e class android.media.cts.EncodeDecodeTest#testEncodeDecodeVideoFromBufferToBuffer720p \
-w android.media.cts/android.test.InstrumentationTestRunner
Change-Id: I7973b123cf4fc08e8ce2b05bd4c23fa41b1cdcdf
* changes:
Stopped starting and killing processes directly from ATMS (27/n)
Removed direct calls to AMS.broadcastIntentLocked from ATMS (26/n)
Removed references to ProcessRecord in ActivityStackSupervisor (25/n)
Some shell start activity commands set debug flags that requires us
to synchronously call into the process logic in AMS in the middle of starting
an acitivty in ATMS. To avoid dealock in this situation, we have the shell
commands go throuhg AMS to start activity which will in turn acquire the AMS
lock before calling into ATMS.
Bug: 80414790
Test: Existing tests pass
Change-Id: I407e0c6573cb903b9c2d2f635fd4d99ef833b026
Post messages to have processes started and killed instead which
should be okay.
Bug: 80414790
Test: Existing tests pass
Change-Id: Ia435aa815c36a84947ae0f76291b1d1f9222231d
The method is internal to AMS so can't be called directly from ATMS
which will be in a different package soon.
Bug: 80414790
Test: Existing tests pass
Change-Id: If36c7d9cb65e848101070f6b412c9067ee33741e
> Do not show starting window when using hero transition
> When running cross-task, only play the enter animation
> Allow transitions when using intent-sender
Bug: 113071278
Test: atest cts/tests/tests/transition/src/android/transition/cts/ActivityTransitionTest.java
atest cts/tests/tests/app.usage/src/android/app/usage/cts/ActivityTransitionTest.java
Change-Id: Id973d52412a9a2cde3ebcae3b718556c47dfff5d
Allows for better seperation of AMS and ATMS, also the method mostly
accessed internal variables in ProcessRecord so it make sense for it
to be in that class.
Also, move inputDispatchingTimedOut back to AM side because it involves
lots of process stuff.
Test: Existing test pass
Bug: 80414790
Change-Id: I45b98dc550ff121e9df4bf004b2667af2426b79d
The stack supervisor object should only be accessed through ATMS.
Test: Existing test pass
Bug: 80414790
Change-Id: I0648a95161a6a5c4ad714264d217c7f5e55852d7
Which processes to snapshot is controlled by a whitelist.
Benchmark for taking the snapshot:
https://docs.google.com/spreadsheets/d/1vG9ku8Uu8104CmKbO4cNeEKVeeByvHY--p0_dK1GAdA/edit?usp=sharing
(The difference between the first two sheets.)
~20ms constant cost plus ~4ms per process.
Bug: 115968899
Test: manually verified that statsd is included in the report
Change-Id: Iba680531c563ba28fae849e44044313866b2103f
When device identifier access was moved from a runtime permission to a
privileged permission device and profile owner access regressed by no longer
requiring consent to access the identifiers. With this change device and
profile owners will still need to have the READ_PHONE_STATE permission to
access identifiers.
Bug: 117611604
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases \
-t com.android.cts.devicepolicy.DeviceOwnerTest#testDeviceOwnerCanGetDeviceIdentifiers
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases \
-t com.android.cts.devicepolicy.ManagedProfileTest#testProfileOwnerCanGetDeviceIdentifiers
Change-Id: Ib2d86440c531eab075d010de183ccfa45c2443e5
This change makes touch ripples appear correctly on the action buttons
on media notifications. This involves the following changes:
- NotificationViewWrapper.onReinflated() sets the notification content
root's background to transparent rather than null when transferring the
background color to the NotificationBackgroundView. This gives the
ripples a surface to draw on.
- The RemoteViews for the media templates are changed to use a fixed
set of buttons instead of removing and re-adding them on every update.
This prevents the update caused by whatever action the tap invokes from
interrupting the ripples.
- A method is added to RemoteViews allowing the ripple color to be
specified. This allows us to change the ripple color to match the
foreground color of the controls, which is necessary for the ripples to
show up against a dark background.
Test: manual
Change-Id: I907f9a1a75efb48da496133ad357fc5150de4410
Fixes: 35856702
A new API for setting the Private DNS settings value programatically via
the DevicePolicyManager.
Since there are two separate settings for Private DNS, and the value
provided for the hostname needs to be validated, a new
DevicePolicyManager API is introduced.
Only a Device Policy Client in Device Owner mode may change these
settings.
The DPC may additionally set a user restriction (added in a separate CL)
to prevent the user from changing Private DNS settings.
Bug: 112982691
Test: atest com.android.cts.devicepolicy.DeviceOwnerTest#testPrivateDnsPolicy
Change-Id: I566437e4fe10e1346858149120c50b3c20ca073f
InputMethodManager has been a per-process singleton object. In order
to support behavior changes for multi-display support in Android Q,
however, InputMethodManager now needs to be per-display objects.
With this CL, context.getSystemService(InputMethodManager.class) will
start returning per-display InputMethodManager (IMM) instance.
Why?
There are two major reasons.
1. To support per-display focused window.
2. To support more simplified API for multi-session IME.
Currently per-process InputMethodManager instance directly receives
callback from ViewRootImpl upon windowFocusChanged, then it keeps
track of which Window is focused by storing its root view into
InputMethodManager#mCurRootView.
This design assumes that (within the same process) at most one Window
can have window focus, which is no longer true once we start
supporting per-display focused window (Bug 111361570).
Why we need to do this to support per-display focused window:
For traditional non multi-session IME cases (e.g. apps that use
Virtual Display APIs on phones), internal state of IMM can be easily
messed up once the system starts sending per-display
windowFocusChanged events to the same process, because IMM still
doesn't know that now each display has focused window. It is hard to
precisely predict what kind of issues we would see simply because such
a use case is most likely not expected in the original design.
Why we need to do this for multi-session IME:
For multi-session IME scenarios, in addition to the above concern in
InputMethodManager, the current design allows at most one IME session
per process. This means that if a process X is showing Activities to 3
different displays, only one Activity can interact with the
multi-session IME at the same time. If we do not change the current
design, the only way to work around is to ask app developers to
explicitly use different processes for each Activity, which may
require a lot of work (e.g. SharedPreference is not optimized for
multi-process use cases). This would also make multi-session IME
development complicated because the IME cannot know on which display
the IME is interacting until startInputOrWindowGainedFocus() is
actually called, and needs to do all the preparation and cleanup tasks
whenever startInputOrWindowGainedFocus() is called for a different
display than it's currently interacting with.
Alternative solutions considered:
Another possible approach is to update InputMethodManager singleton to
be able to maintain multiple mCurRootView and mServedView for each
display. This approach was abandoned because those fields and methods
are already marked as @UnsupportedAppUsage. I concluded that touching
@UnsupportedAppUsage things would have bigger compatibility risks than
per-display instance model.
Implementation note:
* Public APIs in IMM that take View instance as the first parameter
will verify whether the given View and IMM are associated with the
same display ID or not. If there is a display ID mismatch, such an
API call will be automatically forwarded to the correct IMM instance
IMM with a clear warning in logcat which tells that app developers
should use the correct IMM instance to avoid unnecessary performance
overhead.
* As a general rule, system server process cannot trust display ID
reported from applications. In order to enable IMMS to verify the
reported display ID, this CL also exposes display ID verification
logic from WMS to other system components via WindowManagerInternal.
* isInputMethodClientFocus() in WindowManagerService (WMS) is updated
to use top-focused-display to determine whether a given IME client
has IME focus or not. This is now necessary because with a recent
change [1] each display can have focused window. The previous logic
to check all the displays that belong to the given pid/uid [2] no
longer makes sense.
* Currently per-display InputMethodManager instances will not be
garbage collected because InputMethodManager#sInstanceMap keeps
holding strong references to them. Freeing those instances is
technically possible, but we need to be careful because multiple
processes (app, system, IME) are involved and at least system
process has a strict verification logic that lets the calling
process crash with SecurityException. We need to carefully
implement such a cleanup logic to avoid random process crash due to
race condition. Bug 116699479 will take care of this task.
Also to make sure that the performance regression (Bug 117434607) we
observed after my initial attempt [3] no longer exists, here are the
benchmark results with and without this CL.
testExpandNotificationsLatency on taimen-userdebug
without this CL:
results=[55, 46, 61, 67, 50, 48, 57, 50, 55, 63]
min:46.0, max:67.0, avg:55.2, median:55.0, std_dev:6.539
with this CL:
results=[45, 55, 58, 57, 47, 60, 59, 60, 56, 53]
min:45.0, max:60.0, avg:55.0, median:56.5, std_dev:4.980
[1]: I776cabaeaf41ff4240f504fb1430d3e40892023d
1e5b10a217
[2]: I8da315936caebdc8b2c16cff4e24192c06743251
90120a8b5b
[3]: I7242e765426353672823fcc8277f20ac361930d7
c53d78e992
Bug: 111364446
Fix: 115893206
Test: atest ActivityManagerMultiDisplayTests
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Test: No perf regression in LatencyTests#testExpandNotificationsLatency()
Change-Id: I78ad7cccb9586474c83f7e2f90c0bcabb221c47b
- Mirror a few more fields from ProcessRecord to WindowProcessController
- Moved mCheckedForSetup to ActivityStartController where it is actually used
- Move configuration and locale message processing to ATMS
- Switched dependency on ProcessRecord to WindowProcessController in a few places
Test: Existing test pass
Bug: 80414790
Change-Id: I7034fcb2f15defea81ad07a52d8f498da35f0760
ContextImpl has an internal rule that when ContextImpl#mDisplay is
null the Context is associated with the default display. The problem
is that, as discussed in Bug 117709581, when ContextImpl#mDisplay is
null ContextImpl#getDisplay() tries to get some non-null Display
object by making an IPC to the system server, which is redundant when
the display ID is the only thing that the caller wants to know.
By having an @hide method Context.getDisplayId(), we can ensure that
display ID can be obtained without any IPC. This enables us to
re-submit my CL [1] that aimed to instantiate InputMethodManager (IMM)
for each display but then got reverted due to a performance regression
(Bug 117434607).
There should be no developer-observable behavior change.
[1]: I7242e765426353672823fcc8277f20ac361930d7
c53d78e992
Fix: 117712745
Test: atest FrameworksCoreTests:android.content.ContextTest
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/tests/coretests/src/android/content/ContextTest.java
Change-Id: I2534530a5ce90e2620c5039d793a6454a0a1e154
The suspending app has more context about why a particular app was
suspended by the user, but we do not want to delegate the interception
of the suspended activity out of the system.
Hence allowing it further customizations to the dialog to make
it clearer.
Test: atest com.android.server.pm.SuspendDialogInfoTest \
com.android.server.pm.SuspendPackagesTest \
com.android.server.pm.PackageUserStateTest \
com.android.server.pm.PackageManagerSettingsTests \
com.android.server.am.ActivityStartInterceptorTest
atest GtsSuspendAppsPermissionTestCases GtsSuspendAppsTestCases
Bug: 112486945
Bug: 113150060
Change-Id: If9f4d14587a2b75bb572e7984a90e300a2c72d16
If a normal app does not have launcher icon, launcher api
will return app details activity instead, so user will
be noticed that the app is still installed.
Bug: 111348460
Test: Installed an app without launcher activity, an app icon is being
shown in launcher allapps, and it forwards user to app details page.
Change-Id: I9c17f5edfdefe19727145e7176d7e113286c997d
1. We now apply smart replies to the first action button that has
(freeform) remote input. For example, if the notification have
both reply and reply all buttons, smart replies will be applied
to the first button only.
2. Enforced getAllowGeneratedReplies check in system generated
smart replies.
3. Fixed an bug that smartRepliesAdded is not called for system
generated smart replies.
BUG: 111546109
BUG: 111406942
Test: atest com.android.server.notification.NotificationTest
Test: Check apps generated smart replies via Messenger
Test: Check system generated smart replies via Hangouts
Change-Id: I4db34f557f7e9988be612e4162347b86393d1faf
