The delay was introduced to suppress JIT activity during startup.
However, ART no longer uses the expicit process state signal as an input
to informing JIT activity, so the delay can be removed.
By forwarding the process state immediately, ART can make more informed
decisions about activity based on process state, e.g., suppressing
madvise calls for less important (non-foreground) processes.
Bug: 235390330
Test: m + presubmit + boot tests
Change-Id: Ia95a76f86cf4c38bf89e56f954dbf59e0083ec50
Merged-In: Ia95a76f86cf4c38bf89e56f954dbf59e0083ec50
update to reflect the new usage of the extra in forcing platform side
provisioning.
Bug: 236597525
Test: n/a
Change-Id: Ie98e9aaa790d1c0bd4b2d5e2b85a81bd8e3c92e3
When the enableOnBackInvokedCallback is set to false (or not set),
registering an OnBackInvokedCallback should be a no-op to avoid
overriding the default compat callback.
Test: Manual testing registering a callback on an app with the flag
disabled and doing a back gesture. Currently we don't have test
executing a back gesture so automated tests are not possible
Bug: 235206960
Change-Id: I54d843f11130a78ed5a68cbe4722e601a2086ee1
Merged-In: I54d843f11130a78ed5a68cbe4722e601a2086ee1
(cherry picked from commit aa48dc3c2d)
When apps are restored, set their standby bucket to RARE if
they have been used within the past 90 days, based on the
restored UsageStats data.
Bug: 214580000
Test: atest UsageStatsDatabaseTest
Change-Id: I9d63032ef84fef97734b51323f41b797caa4f554
(cherry picked from commit 89f69113ad)
The current configuration in the client activity could be
updated via the other flow (from ViewRootImpl). So, it is
possible that the client activity configuration is different
from the last reported configuration that cached in the system.
If the configuration changed again in that case, the
ActivityConfigurationChangeItem could end up without reporting
Activity#onConfigurationChanged if the differences between
the new configuration and the current client activity
configuration contains the configuration changes that the
activity cannot handle.
Update the activity current config only when reported, so
the configuration differences can be correctly evaluated from
the new configuration and the configuration last reported.
Bug: 231312158
Test: repro steps on the bug
Test: atest ActivityThreadClientTest
Change-Id: Ifa27d222bb0905053cf12e08c423bf7bfad904cd
Before this CL, minimum dimensions of Activity wasn't respected,
that said, an Activity could be embedded in a TaskFragment of which
bounds are smaller its minimum dimensions.
This CL add the minimum dimensions on several places:
WM core:
1. Verify minimum dimension requirement before adding an Activity to
a TaskFragment. It'll be early return if the requirement is not
satisfied.
2. Propagate the minimum dimensions to the client side through
TaskFragmentInfo to notify the requirement.
3. If TaskFragmentOrganizer tries to shrink a TaskFragment to
the bounds that smaller than minimum dimensions of its children
Activity, switch to match the parent bounds.
AndroidX Window extensions:
1. Early return if TaskFragment is resized to the bounds that smaller
than minimum dimensions which dispatched from the server side.
2. When organizer tries to show Activities side-by-side, verify if
minimum dimensions requirement of the primary Activiy. If the
requirement is not satisfied, show Activities in fullscreen
instead.
TODO: Add an API to check if an Activity intent is allowed to embed
in a TaskFragment.
Bug: 232871351
Test: atest TaskFragmentOrganizerControllerTest
Test: atest TaskFragmentOrganizerTest TaskFragmentOrganizerPolicyTest
Test: atest SplitActivityLifecycleTest
Test: atest CtsWindowManagerJetpackTestCases
Test: atest WmJetpackUnitTests
Merged-In: Ib46c2cec2a0735b9e3f3420f2cb94754801b86b9
Change-Id: Ib46c2cec2a0735b9e3f3420f2cb94754801b86b9
Hidden Activity API allows a component holding permission
MANAGE_MEDIA_PROJECTION to declare that the result of setting up the
MediaProjection session should be returned immediately to the host VC app.
The host VC app will cycle through the resumed state when the activity
result is delivered to it, and return to its original state.
Manually tested with test MediaProjection app.
Test: atest WmTests:ActivityRecordTests
Bug: 230607871
Change-Id: Ic85fe8657b9e7f526bbc37a52011d16afa8aef2c
Bug: 233566891
PropertyInvalidatedCache.dumpCacheInfo() sometimes triggers an ANR in
system_server, with a thread blocked writing to dumpsys TransferPipe
while holding a cache lock. Other threads are blocked on the cache
lock. There does not seem be a true deadlock, but if IO is slow then
all the threads slow down enough to trigger the ANR.
This change stages the output of dumpCacheInfo() in a byte array. The
byte array is written while holding the appropriate cache locks. When
the byte array has been completely generated and all locks have been
released, the output is sent back to the caller over the dumpsys
TransferPipe.
The two PrintWriter objects are properly closed now. The previous
code worked as a side effect of the many calls to flush(), which are
unnecessary now.
As a consequence of this change, it will be possible add a unit-test
for the output of 'dumpsys cacheinfo' by calling the method that
creates the byte array. Such a unit test is not part of this commit.cache.
Tested manually by running 'dumpsys cacheinfo' and verifying that the
output is correct.
Test:
* FrameworksCoreTests:IpcDataCacheTest
Change-Id: Icbd0197ca883cf0560ba2eb637951abee033eced
Revert "Update smartspace shadow"
Revert "Update app icon shadows"
Revert submission 17935777-lightDarkDetection
Reason for revert: Talked with Adam Cohen, white shadows are controverstial and we'd need to escalate to senior UX if we want to ship. James would rather do it in U timeframe, will flag to UXers we work with that the opportunity to escalate is available if needed.
Reverted Changes:
Ia91221427:Update light/dark detection.
Ie12d3d054:Update app icon shadows
Icc88c3496:Update smartspace shadow
Change-Id: I7d6b972d29b328a7d5ca7ac7241156b6e51a2cd6
Before this CL, minimum dimensions of Activity wasn't respected,
that said, an Activity could be embedded in a TaskFragment of which
bounds are smaller its minimum dimensions.
This CL add the minimum dimensions on several places:
WM core:
1. Verify minimum dimension requirement before adding an Activity to
a TaskFragment. It'll be early return if the requirement is not
satisfied.
2. Propagate the minimum dimensions to the client side through
TaskFragmentInfo to notify the requirement.
3. If TaskFragmentOrganizer tries to shrink a TaskFragment to
the bounds that smaller than minimum dimensions of its children
Activity, switch to match the parent bounds.
AndroidX Window extensions:
1. Early return if TaskFragment is resized to the bounds that smaller
than minimum dimensions which dispatched from the server side.
2. When organizer tries to show Activities side-by-side, verify if
minimum dimensions requirement of the primary Activiy. If the
requirement is not satisfied, show Activities in fullscreen
instead.
TODO: Add an API to check if an Activity intent is allowed to embed
in a TaskFragment.
Bug: 232871351
Test: atest TaskFragmentOrganizerControllerTest
Test: atest TaskFragmentOrganizerTest TaskFragmentOrganizerPolicyTest
Test: atest SplitActivityLifecycleTest
Test: atest CtsWindowManagerJetpackTestCases
Test: atest WmJetpackUnitTests
Change-Id: Ib46c2cec2a0735b9e3f3420f2cb94754801b86b9
By the original design, we register the activity event in the
ActivityManagerService. After getting the activity event, we will
query current visible activities and report them to Assistant.
Assistant will start to get direct actions of those visible
activities. But sometimes they can not get the direct actions
due to the stage of activity lifecycle before onStart().
We will postpone the request direct actions a few times
before onStart().
Bug: 224789902
Test: atest CtsVoiceInteractionTestCases
Change-Id: If7cd52c5ba749523e575c0be5595e8f20704c4f2
