* changes:
Send fixed rotation adjustments to the associated client
Add support to override display adjustments by token
Add fixed rotation display adjustments
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
This value is used to report WM#getMaximumWindowMetrics.
Current approach, which is use logical display metrics,
is not compatible with display area feature.
Especially, when multiple task display area feature
are phasing in.
Test: atest WindowConfigurationTests
Bug: 151414021
Change-Id: Iaa1f52395a1b7a0a7fefd5c31cfde703fa81f509
* 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
