Per https://developer.android.com/guide/topics/ui/picture-in-picture
After app requests enterPictureInPictureMode and receives onPause
callback, it will continue playback if isInPictureInPictureMode is true.
However, with ag/11273366, isInPictureInPictureMode will now return true
after the new configuration is dispatched to app, which happens after onPause.
This may cause app, following the guidance, to cease playback in PiP mode.
Fixes this by setting the internal mIsInPictureInPictureMode earlier
right in enterPictureInPictureMode
Video: http://go/recall/-/aaaaaabFQoRHlzixHdtY/fVRqG7UWoKkQQhFxPkzcUt
Bug: 156924033
Test: manually enter PiP from Twitch
Change-Id: I8e0865076fcb756cfa5db39901f460ab5ad69b99
d85bed510, Adding support for cross-task hero transition, When running
cross-task, only play the enter animation, but the judgment for start
exit transition with shared element is broken. For the case on the issue,
when the exit transition completes, the activity is on the top of task,
it is not allowed to execute return transition.
This CL modifies the condition to allow the return transition. For start
exit back transition, the isReturning is always true. We can use it to
decide if it is allowed to play the return transition.
Bug: 137838129
Test: atest ActivityTransitionTest
Manual testing on ApiDemos with Activity transition
Change-Id: Iaa6a875dbe305f6356887616b797dc45e76a4b56
Tracks the number of hits, misses, refreshes, and invalidations on a
per-cache basis, and makes that information available through dumpsys
cacheinfo.
Bug: 157175501
Test: adb shell dumpsys cacheinfo
Change-Id: Icabdd82acda2edc54d787d0a2d15a33ba18fd668
UidAtomTests:testAppOps is a test class and test method of
CtsStatsdHostTestCases. To run this in Test Mapping, it should
specify CtsStatsdHostTestCases. as the name in TEST_MAPPING file,
and android.cts.statsd.atom.UidAtomTests as the options.
Bug: 155714228
Test: presubmit test.
Change-Id: I7df08ae811425020ebbeae6a8e9f1317065c00c9
While starting activity, WindowManager posts a runnable to DisplayThread to updateOomAdj.
The latency of the thread switch could cause client app failure when the app is checking
ActivityManagerService.isUidActive() before updateOomAdj is done.
Use PendingStartActivityUids to save uid after WindowManager start activity and before
updateOomAdj is done.
PendingStartActivityUids list is checked in
ActivityManagerService.isUidActive() and
AppOpsService.UidState.evalMode(). A uid in this list is treated same as
uid is active.
Bug: 157180494
Test: atest cts/tests/app/src/android/app/cts/ActivityManagerCameraLaunchTest.java
Change-Id: If0685c3c2fad01e48f3fcf2228057041f4ec9b00
By adding a util method that prefers longlabel and
falls back to shortlabel.
Test: atest
Bug: 157140669
Change-Id: Ib7229b75b7a8ab87274e9aab1c7816129f04e505
* A security exception should be thrown when
setAutoTimeRequired is called on a managed profile
* Update javadoc
Bug: 156620695
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testSetAutoTimeRequired
atest com.android.cts.devicepolicy.MixedProfileOwnerTest#testSetAutoTimeRequired
atest com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testSetAutoTimeRequired
Change-Id: Ifb53c218947f62aa446aa607d3f4eee354586395
Activity that does not handle any of the configuration changes was not
relaunched when only changing its size and without cross the size
threshold, see ActivityRecord#crossesSizeThreshold(), but the
new configuration would still be scheduled to the client.
In that case, Activity#onConfigurationChanged() was called when
ActivityConfigurationChangeItem executed, because it requested to
always report to the activity. This was wrong since the activity didn't
request to handle any of the configuration changes.
On the other hand, if configuration change sent from view root came
earlier than ActivityConfigurationChangeItem, the new configuration
change did not propagate to ResourcesManager.
Allow the new configuration changes propagate to ResourcesManager
and report to activity only if the activity has been declared to handle.
Bug: 155589510
Test: atest AppConfigurationTests
Change-Id: If7dd769098a9f06efafda0250bfce71c6c96fb49
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
