Based on the UX feedback:
Delay: 30ms
Duration: 80ms
Easing: linear
Bug: 196173550
Test: Test with demo app shopping mode
Change-Id: I1eac73ba71f6128a54e00b25674ff731695a3dc9
The snapshot surface will be offset with its parent, so no need to
offset itself.
Bug: 196173550
Test: test with demo app on click back from split to split.
Change-Id: I1c65bf2e4b1b8c489ad7fe5eec1418707d590d13
Also make sure that the split info is updated after an activity is
appeared on the client side.
Bug: 199144146
Test: Manual, using the test app
Change-Id: I11e6dd9d1f55c107aaf40aed4d25b6b8fff7b9ca
Moved to androidx.window.extensions.layout package.
Removed ExtensionProvider.
Updated method signatures.
Bug: 190433972
Test: Manual, using the sample app from AndroidX
Change-Id: I6c98ced7b447f231455723a8dc601a46653a48de
Use the default app open/close animation.
TODO:
1. Handle two TaskFragment open/close as one
2. Handle change transition based on the new motion design
Bug: 196173550
Test: test with demo app
Change-Id: I7b446840270edfc3c9e3fe188585b2cd839fa9f1
Also rename TaskFragmentAdjacentOptions to TaskFragmentAdjacentParams to
make metalava happy.
Test: build & run
Bug: 192442647
Change-Id: Iab256ce8c745635a51834f44e72493e204224f36
Placeholder activity was finished while starting the
task root activity from launcher because the task
root activity was set as singleTask launch mode.
Meanwhile, the primary TaskFragment was also removed
because of the split-rule finishPrimaryWithSecondary.
Sending the information of whether the last activity
on the TaskFragment was finished due to launch other
activity to client. So that the organizer can decide
whether the primary TaskFragment should removed.
Bug: 196179714
Test: relaunch singleTask activity with placeholder
Change-Id: I9a0369285adfbdef1edc5a7f2af944ec5b434566
Exception was throw because a TaskFragment was finished before
onTaskFragmentAppeared was called.
Bug: 198361315
Test: launch Settings with WIP CLs listed in the bug
Change-Id: Id794b192cd0db21c00803166358712cdf5e2a209
When finishing a placeholder activity, the secondary container was
clean up, and the primary activity was also finished. However, the
primary container didn't remove and therefore was expanded to
fullscreen before the activity within completely being removed.
Which resulted in TRANSIT_OLD_TASK_FRAGMENT_CHANGE transition
after commit 118428b merged.
Bug: 198228078
Test: finishing placeholder activity and back to launcher
Change-Id: I3d55f0be8c7f6ab3970450d7b90dd95f3cfdd463
Sample workflow with directly setting the surface position
Bug: 196173550
Test: test with demo app
Change-Id: I36851f1fa46c1dc1615bb00cc9df3299b5088fb4
The embedded activity was destroyed immediately when being
finished because the next top activity was on the adjacent
TaskFragment and was already visible. Therefore, the finishing
animation was played before the organizer requested to
finish the activity on the adjacent TaskFragment.
Prevent the last activity of the embedded TaskFragment to
be removed immediately if the organizer requested to.
Bug: 189386466
Test: finish both activities on separate TaskFragments
Change-Id: I916eddc4dcf0de3bc7ed7264296f441d1b7bb726
When intercepting an activity start request, a new split pair
was always created and launch the activity to the side of the
caller activity.
This CL launches the activity on top of the caller activity
if the caller activity is already on the secondary container.
This is needed for the case that the activity is started
into a new Task, or new Task will be escaped from the current
host Task and be displayed in fullscreen.
However, the interception won't work if the activity is started
from another process.
Also adding logs for TaskFragment errors.
Bug: 194997356
Test: manually, start activity with sample app
Change-Id: I268c1dad191cdfdbf48cac84e18f1dfda761b0d3
When a new activity is started to side of a primary container in an
existing split, finish the old secondary container by default to
replace it instead of putting on top.
Note that this rule only applies for new activity launches to side
via rules or dedicated APIs. If an activity is started regularly,
it would normally be placed in the existing secondary container on
top, not creating a new one and replacing.
Bug: 194996352
Test: Start to side from the primary container several times,
observe secondary container being replaced with subsequent launches.
Change-Id: If4439368a669c6252c97471f0e77286357285c9d
Also adding comments to explain that it could be changed after
creation.
Bug: 194860679
Test: wm presubmit
Change-Id: I72b099a6134701377a73cbe76bb9d0cb501aa507
When finishing the last activity in a container that has dependent
containers, make sure to delete those in addition to just finishing
activities. This will ensure that containers with activities from
different apps will be properly cleaned up.
Bug: 195108809
Test: Launch a container to side with 'finishSecondaryWithPrimary'
configuration, finish the primary container with swipe from side.
Test: Do the above for activities in different apps.
Change-Id: I746055fd02894d8221cace10d556992e2dba31b5
This allows applying split rules to activity start requests for
different processes and covers APIs like 'startActivityAsUser',
not requiring app developers to use dedicated APIs to start to side
instead.
When the client organizer observes a new activity being started, it
creates a new TaskFragment first and modifies the activity start
options to target that container.
Bug: 194140227
Bug: 190433398
Test: Manual, using reference implementation and sample app.
Change-Id: Ice3de8ec725d327266ec38052129b4158608855e
Activity#onCreate is called before receiving the TaskFragment
appeared event in the client process. So, the client split
controller created another split and resulted in unexpected
behaviors.
Bug: 194860679
Test: start activity to side
Test: wm presubmit
Change-Id: Iac34bd39376940c5c0224c8687ad9858a4190e20
If an activity is re-created after configuration change, make sure
to check if it is not already in a split with an activity below
before creating a new one.
Bug: 190433398
Test: Manual
Change-Id: Ib2b87e3736d6331209be4934303b20717446807c
Track activity configuration changes, so that split controller has
a chance to apply metrics-based rules like launching a placeholder.
Not using ComponentCallbacks here, since they are only triggered for
Application configuration changes, which might be problematic if
there are multiple running activities with different sizes. They are
also usually triggered before individual activity resources are
updated.
Also moved post-creation actions to onActivityPostCreated(), since
onActivityCreated() is called from the base implementation in
Activity#onCreate() and there is still a chance that app may perform
some actions after calling super in its override.
Bug: 194538838
Test: Configure a placeholder, launch in a small size, enlarge.
Change-Id: Ied55d5f920890fa554cdd66419235d61ab03b440
Only add task fragment bounds change requests if they differ
from the last values requested by organizer.
Bug: 190433398
Test: Manual, using the test app
Change-Id: Ia619465cbc923f048d3d11e47a3fe7d3ab3314e4
... to verify their behaviors in CTS
Also wraps ITaskFragmentOrganizer to TaskFragmentOrganizerToken
because we cannot make .aidl a TestApi.
Test: presubmit
Bug: 192442647
Change-Id: I848a33340449189af7d9d66a6468a9e397a0f53a
NEW_TASK flag was added by ATMS when #startActivityInTaskFragment
is called because the activity was started without source record.
Bug: 193846941
Test: starting CCT in sample app
Change-Id: Ida26034324f7ff761f1e688403d78959a01f010d
- TaskFragmentContainer corresponds to a TaskFragment record.
- SplitContainer has a record of two containers combined in a split
with a given rule.
Bug: 190433398
Test: Manual, using the reference implementation.
Change-Id: I54cd86d2047aac2fa392189ed355760b1a32b6c4
Update window-extensions aar.
Update window-sidecar aar.
Remove deprecated fields.
Bug: 173739071
Test: Manual build with extensions, set a device state 3
Test: Set a dislay feature to go horizontally and run sample app
Change-Id: I67f1b109aeb4202c7c531b074d2d6e89e1e8c831
device state to posture via a config.
This updates the sample Sidecar/Extension implementation for the WM
Jetpack Library to read the mapping of system DeviceState provided by
DeviceStateManager from a config and apply the translation to Jetpack
Posture when the device state changes.
Bug: 173428759
Bug: 181248887
Test: Manual - overlay config value on Jumbo and verify correct mapping
Test: ./gradlew window:window:test
Change-Id: I74d71a67e72976ade88122cd8eda5f16b2301c32
This provides a clear separation between the data producing classes and
the core library class. It also allows seperating the logic in
SettingsConfigProvider into different producers that provide their data
from different sources (for ex, settings vs resources).
Bug: 173428759
Test: Manual - flash device and verify
Test: ./gradlew window:window:test
Change-Id: I111058ff7c3479bc53aede0b29de1e2e1c2ff91f
Reference implementation of WM Extensions included a hidden API
call, which is prohibited when coming from non-system apps.
Bug: 179968070
Test: Build, test on YT and sample apps
Change-Id: Ic8b215b811a5e5d6abaacdb8ff0bf82fc3995d99
Moving some of the common bits of Sidecar and Extensions
into helper classes and adding both to the reference repo.
Bug: 154172225
Test: m androidx.window.extensions
Test: Manual, by including extensions in the emulator image
Test: gradlew window:window:cAT
Change-Id: I44ff06b06b2202a5d687216e017528098dc14d1d
Placing the reference implementation in /vendor partition tirggers
UnofficialApisUsageTest failures due to hidden API use in the sample.
Moving it to system_ext should resolve this issue.
Bug: 167214265
Test: com.android.gts.api.UnofficialApisUsageTest#testNonApiReferences
Change-Id: I628fd0e00558208a3af26ecf02b82a3cedad8011
Add window sidecar aar.
Add settings implementation of SidecarInterface.
Bug: 157477145
Test: use a device with sidecar and not window extensions.
atest CtsWindowManagerJetpackTestCases:ExtensionTest
Change-Id: Iade7a4ba5a75ba7301cd151b54a95820a3d4bdde
