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
Adds support for toggling the global auto time setting via the command
line. Useful for manual and automated tests, and also makes
time_detector consistent with time_zone_detector.
This also helps to confirm that the new config-update code should work
when used by SettingsUI.
Manually tested using a combination of the command line and SettingsUI.
Bug: 172891783
Bug: 229740080
Test: atest com.android.server.timedetector android.app.time
Test: adb shell cmd time_detector is_auto_detection_enabled
Test: adb shell cmd time_detector set_auto_detection_enabled
Change-Id: I39ce8c9381c2eef3f0fb5a42b54bc9c68e545f67
This adds support for updating user-facing time detector configuration
via the TimeDetectorService.
Bug: 172891783
Bug: 229740080
Test: atest com.android.server.timedetector android.app.time
Change-Id: I109e59e44dbe085d456fc36bcd98375d118940c0
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
Switch TimeDetectorStrategy.Environment to returning
ConfigurationInternal in place of an individual property.
This is in preparation for implementing the methods to update
time detector configuration and support listeners. More properties will
be added to ConfigurationInternal / removed from Environment in later
commits.
This mirrors the situation in com.android.server.timezonedetector and is
part of a sequence of changes to make com.android.server.timedetector
follow the patterns for configuration used there.
Bug: 172891783
Bug: 229740080
Test: atest com.android.server.timedetector android.app.time
Change-Id: I0ffe467ede4b6b0279b284108a368c5265a323a0
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
