In the previous implementation a batch of process/activity config
changes would effectively be executed out of order. When the server
would dispatch changes in config in quick succession the config change
items would update the pending configs first through the preexecute()
calls and then apply the activity config before the process config
is applied even though the process config was dispatched before the activity
config change item. See b/148639784 for more detail.
Fixes: 148639784
Test: ActivityThreadTest#testHandleActivityConfigurationChanged_EnsureUpdatesProcessedInOrder
Test: ActivityThreadTest#testHandleActivityConfigurationChanged_SkipWhenNewerConfigurationPending
Change-Id: I3c926076ac8dba73eb0471c7bc91313df519cf92
- Apps that have sent incomplete conversations only are allowed
into the conversation section, but not allowed to have full controls.
Users can also demote these apps entirely from the converstion space
- Once an app starts using complete notifications, it can no longer
be fully demoted out of the conversation space, it's only demoted on
a per conversation basis.
- If an app has sent full conversation notifications, and then sends
an incomplete one, the incomplete notification will not be shown in
the conversation space.
Test: atest
Bug: 155276427
Change-Id: Iba9b01c53949632b6db2834511165e3571387ac9
Previously ActivityTaskManagerService#resizeTask throws
IllegalArgumentException when the task windowing mode is not suitable for
resize. However caller cannot ensure the windowing mode before
acquiring window lock.
To descriminate windowing mode mismatch from programming errors
(e.g. Preconditions.check failures), the CL changes the way of reporting
windowing mode mismatch to returning boolean value.
Bug: 156196109
Test: None
Change-Id: I36f473899c4f6d7f5d5d25f081a57fe14ebbb1a8
- Haven't been able to repro, but we shouldn't crash system server
Bug: 154382448
Test: Just adding a destroyed check
Change-Id: I412ab1703602723511a6bd3c598d34b6ade68db7
Merged-In: I412ab1703602723511a6bd3c598d34b6ade68db7
Following the model for dumpsys gfxinfo, this patchset adds a
CacheBinder service that dumps cache state information from each
process.
Bug: 153661880
Test: adb shell dumpsys cacheinfo
Test: adb bugreport
Change-Id: Ie7cce70e56777a200e3e3e92ab895126b6f29032
* changes:
Send fixed rotation adjustments to the associated client
Add support to override display adjustments by token
Add fixed rotation display adjustments
This workaround was intended to silently fix EXDEV move failures due to
the /Android/data and /Android/obb bind mounts. However, the workaround
should be limited to moves to *and* from the emulated filesystem. For
moves from the emulated filesystem to another filesystem (or
vice-versa), this would never have worked in the first place, and we
want to give the app this feedback, so it knows it needs to do a more
expensive copy operation and can show this in the UI. We know some apps
(like DocsUI) already handle this.
Public volumes (eg /storage/ABCD-1234) don't need this workaround, since
they don't have the bind mounts. Private volumes that aren't primary
don't have these bind mounts either.
Bug: 146430607
Test: N/A
Change-Id: I7bfe88e07708fe044ce8df02000a97cfad19bdee
When an Activity is launched directly into split-screen mode, there
won't be any onMultiWindowModeChanged callback. Upon activity creation,
the current windowing mode should be part of the configuration, use
the windowing mode from that as initial values for both
isInPictureInPictureMode and isInMultiWindowMode.
Bug: 155811896
Bug: 156204380
Test: launch activity to split-screen secondary and verify
isInMultiWindowMode in dumpsys
Change-Id: I6061a2d5687b68a981abcf8b184bfb007cdcf501
All apps are profileable on debuggable builds, so enable binder
tracing during app startup on debuggable builds if binder tracing has
already been enabled.
Test: binder tracing shows up for new apps on userdebug
Bug: 156259316
Change-Id: I8cc6c2f711943c21b54f346a23ba7089dc9c9180
So the real information of display can be adjusted according
to the adjustments for the application started with fixed
rotation transform.
The enabling adjustments may be sent in different ways:
- Launch activity
The information is bundled with LaunchActivityItem.
- Resume activity or update non-activity window
Send a standalone FixedRotationAdjustmentsItem.
The disabling adjustments (null) are always sent by
FixedRotationAdjustmentsItem.
Bug: 147213487
Test: AppConfigurationTests#testRotatedInfoWithFixedRotationTransform
TransactionParcelTests#testFixedRotationAdjustments
Change-Id: I5238888a5c8352db83fc12749f4de2bfabf46026
This is the bridge to link customized adjustments to an activity
or window token.
The DisplayAdjustments in ResourcesImpl is associated with
ResourcesKey. The new usage requires to associate with token.
That is why the new field is added in Resources.
Bug: 147213487
Test: atest ResourcesManagerTest#testOverrideDisplayAdjustments
Change-Id: Ie79c331654d564aee7af8c6ce98a4c72dd3132b1
* changes:
Resources and strings for freezer settings
Settings option to enable/disable the app freezer
ActivityManager API to check availability of app freezer
A method to verify the availability of the app freezer is required for
configuration code running in places like the Settings app
Bug: 155465196
Change-Id: I5779d263536091689a099eec0815f207dfbbf6ad
Test: verified its workings through the developer options CL
This CL adds isDreaming to DreamMaanger and changes the way it starts a
dream to use IDreamManager.dream()
DreamManager is only used for testing. So far it has been using the
DreamManagerInternal.testDream() API to start the dream. This restricts
the amount of verification that can be done in the dream tests because
it doesn't put the device in a dreaming state -
IDreamManager.isDreaming() is always false.
IDreamManager.dream() puts the device in a dreaming state and enables
better testing.
Bug: 152994058
Test: atest DreamManagerServiceTests
Change-Id: Id4d947e83eabcafa9724764b8d063357c5f2cb49
Currently, there is
onOpNoted - tells listeners that noteOp has occurred
onOpActiveChanged - tells listeners that an op's 'active' state has
changed, i.e. that a successfull startOp or stopOp has happened
There was, however, no way of telling a listener that a startOp has
happened (regardless of whether it was successful). This cl introduces
it, via a OnOpStartedListener.
This is required by the ForegroundServiceAppOpSessionEnded atom,
which counts the number of accepted vs. rejected attempts, and
therefore also needs to know when a rejected start happened.
This cl also contains some cosmetic moving of code so that
startOperation() and noteOperationImpl() are almost
exactly parallel.
* Also *
This cl fixes a bug I discovered in stopWatchingNoted, in which
the callback wasn't fully removed. Consequently, if a callback
was unregistered and then re-registered, the re-registration would
mistakingly be ignored (in direct contradiction to the javadoc).
Test: atest UidAtomTests#testForegroundServiceAccessAppOp
Test: atest AppOpsStartedWatcherTest AppOpsActiveWatcherTest AppOpsNotedWatcherTest
Test: manually monitor: adb shell cmd stats print-logs && adb logcat -v uid -s statsd | grep "statsd : {" | egrep '\(256\)'
Bug: 152800926
Change-Id: Icdb9edf6b2b7c5807b339c1aabb32e882190b071
Revert "Add isUidActiveOrForeground for camera/audio to use."
Revert submission 10829580-isUidForeground
Reason for revert: In CameraService.cpp, before this change, around "am.isUidActive", there was up to 300 ms retry. After this change, the code could move forward fast without retry, but at "mAppOpsManager->startOpNoThrow" call, for the same reason as uid is not updated fast enough, "mAppOpsManager->startOpNoThrow" could also fail.
This CL does not really fix the root cause, but it changes the timing and now the code fails at "mAppOpsManager->startOpNoThrow" call.
Also the timing change may also cause recent multiple CTS test failures.
Bug: 154570809, 155032617, 154849083
Reverted Changes:
Iffed63293:Add isUidActiveOrForeground() for camera/audio to ...
I3685e0c8d:Add isUidActiveOrForeground() for camera/audio to ...
I51ed1fe78:Add isUidActiveOrForeground for camera/audio to us...
Change-Id: I07cbf45949d14489404cb304c80c9ba4276ebe63
This allows listener know task's orientation request change before
handling display rotation through IDisplayWindowRotationController if
they can register a local TaskStackListener.
Bug: 150409355
Test: atest WmTests:TaskStackChangedListenerTest#testNotifyTaskRequestedOrientationChanged
Change-Id: Id7bfc3e63329ce26d454b7e9c143e084e04dd365
Previously, we generally required fully qualified names for referring
to inner class constructors (like #Notification.Builder()) despite that
not being valid javadoc. Now, we properly support #Builder() syntax and
the old syntax will error.
Bug: 6963924
Test: make doc-comment-check-docs
Exempt-From-Owner-Approval: cherry-picked from master
Change-Id: Ib2e4360493275b79c72487ee1cb173bb5e0fd35f
Merged-In: Ib2e4360493275b79c72487ee1cb173bb5e0fd35f
(cherry picked from commit 4c4aa41272)
These were previously being suppressed by doclava but with this change,
all failures are fixed and the suppression logic has been removed.
To fix the issues, there were a few possible changes made:
- broken reference to a public API (such as incorrect parameters): fixed
- unnecessary @link inside an @see tag: fixed
- @see referring to an @hide or @SystemApi: reference removed
- broken references to inner class constructors
- worked around by fully qualifying the constructor
Bug: 6963924
Test: make doc-comment-check-docs
Exempt-From-Owner-Approval: cherry-picked from master
Change-Id: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
Merged-In: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
(cherry picked from commit e0624c7a40)
Clean up various code paths to correctly use the "packageName" option to
limit its output to only information about that package.
Also do a little re-arranging of the output to cleanup a bit recent
stuff that was added, so the end of the output is still the important
high-level summary of process states.
Bug: 155437855
Test: manually inspected various "dumpsys activity" output.
Change-Id: I2ebe6f7ab3d433281993eb3959d375e2e53e0df9
When process configuration was applied on the client side it
accidentally applied an override to display adjustments in resources
for all ResourceImpl objects. This resulted in resources of
activities having incorrect display adjustments and reporting
incorrect display size.
This change fixes the issue by applying the activity's override
configuration on top of the app config before updating the
display adjustments.
Note: This is a slight revert/rework of Ib3ee007bc
Fixes: 148639826
Test: ActivityThreadTest#testHandleConfigurationChanged_DoesntOverrideActivityConfig
Change-Id: I08a5bc29443fbdefbca791240aeaff8f138b8756
We now infer the PIP/MW mode change from the new configuration.
Note also that both
- Activity#isInPictureInPictureMode
- Activity#isInMultiWindowMode
infer the current state from the configuration rather than querying
against the WM.
Also in this CL:
- When in removePinnedStackInSurfaceTransaction, keep the pinned stack
hidden till the windowing mode is set to fullscreen, this is to surpress
the attempt to set the activities to be started in reparenting
- When in ActivityRecord#shouldBeVisible, should take account the force
hidden flag, which is not actually in use before
Bug: 144097203
Bug: 142282126
Bug: 138329093
Test: atest ActivityLifecyclePipTests \
ActivityLifecycleSplitScreenTests \
ActivityLifecycleTopResumedStateTests \
PinnedStackTests \
SplitScreenTests \
ActivityTaskManagerServiceTests \
RecentsAnimationTest \
AssistantStackTests \
StartActivityTests \
ActivityVisibilityTests \
MultiDisplaySecurityTests \
MultiDisplaySystemDecorationTests
Change-Id: Ibe032b5e50ba5c6d6bc44ebb54d07ac974ebe656
This patch will add a fake IME window to virtual display when IME is
showing and covering a bubble window. Without the fake window, the
bubble will not receive the correct IME insets.
To do that, this patch:
1. Added an interface in ActivityView to get VirtualDisplay when needed,
in order to create the display context.
2. Modify the visibility update. When the target is not a client
controlled target, we ignore the client visibility. We also call
visibility update when the control target updated.
3. With the modified infra, add the window with correct param and
context.
Bug: 150780413
Test: atest WmTests:DisplayPolicyLayoutTests
Test: atest InsetsStateTest
Test: atest InsetsPolicyTest
Test: go/wm-smoke
Test: See reproduce steps in the bug
Change-Id: I52691b5c7f81261de580bb4fc762e88486e78141
