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)
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
Create ActivityClientRecord early in preExecute may cause
NullPointerException. If two LaunchActivityItem using the same token
and the 1st postExecute() comes after 2nd preExecute(), the
corresponding launching activity will be removed and cause 2nd
execute() get NullPointerException.
Since the only use case to get ActivityClientRecord in preExecute() is
just to use it to store the pending override config. We can directly
store the latest pending override config from preExecute() in
ActivityThread instead of creating ActivityClientRecord.
Bug: 201668069
Test: atest TransactionExecutorTests
atest ActivityThreadTest
Merged-In: If350e942254e54c9ec90bc63a6e50eb67d038183
Change-Id: If350e942254e54c9ec90bc63a6e50eb67d038183
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
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
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
Reset implementation based on design being comfortable with white
shadows now, so there doesn't need to be a bias toward saying the
wallpaper is dark.
- use luminance/tone instead of HSL to judge contrast
- if the median pixel has a luminance/tone less than mid-gray, the
wallpaper is dark.
- add a method to ColorUtils that returns luminance from a hex code
without any allocations (avoids converting to LAB)
End result is we move from judging a wallpaper as dark ~99% of the time
to 54% of the time, based on Monet Studio implementation checking ~1000
wallpapers, including Google's default wallpapers.
Bug: 213314628
Test: Manual inspection at runtime, long-running prototyping in Monet
Studio with UX across ~1000 wallpapers
Change-Id: Ia9122142728a8de9390b3e0471d7803376487864
As the default value is false, we don't need to put it in bundle if the value is false.
Bug: 234070143
Test: atest android.app.cts.BroadcastOptionsTest#testTemporaryAppAllowlistBroadcastOptions_defaultValues
Change-Id: Ia23d2a03f8c3c64d25b47ed9a8d02ae22ce9246b
Priv-app no longer use its BAL permission to launch background activity by default,
it needs to use this new flag to allow this operation.
Bug: 232921553
Test: PackageInstaller.Session.commit() no longer able to start BAL.
Change-Id: Ifbc642a32dbebdf8854e7e5b1366cb899e971fa7
When entering content-pip
- We take a snapshot for the host task within the
ActivityStarter#startActivityInner function, this is to make sure that
the snapshot is taken before an app switches to the placeholder content
- We retrieve the snapshot in WM Shell when animating the newly created
content-pip task, and use that snapshot during the animation
- This works similar to the solid color content overlay when app enters
PiP without specifying a valid source rect hint. Therefore, we
abstract the functionality to a dedicated PipContentOverlay class
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/dRSTf7prHc0krPhTKZ0kXx
Bug: 220191201
Test: enter content-pip from ApiDemos app, see also Video
Change-Id: I2420402341a910b44bd8f64e3ad518ebef41bc19
BackNavigationController was still relying on a debug setting. Now the
animation request is handled via a boolean parameter passed by sysui,
which has access to the developer option.
Test: Existing test modified
Bug: 231502692
Change-Id: Icda4692e05396407d961610de0ce709492adadc1
Merged-In: Icda4692e05396407d961610de0ce709492adadc1
