91a416bae9
- We were previously initializing components manually because some startup is order-dependent, which led to an increasing number of dependencies from ShellTaskOrganizer on things that it really doesn't need to know about. The initialization order actually matches the dependency order pretty closely, so instead we can have these components add callbacks in the order they are created and initalize in sequence. - Also move some logic out of constructors to the init callback - The other subtle issue is that the provider for ShellInitImpl was implicitly also ensuring that certain shell components were created at startup (since they aren't otherwise referenced by any SysUI component directly or indirectly). Instead, separate that out into another more explicit provider, with the @ShellCreateTrigger annotation, and allow subclasses to provide a @ShellCreateTriggerOverride annotated provider for product-specific initialization Test: atest WMShellUnitTests Test: atest SystemUITests Bug: 238217847 Change-Id: I4a2583ceeaf469130ac07fc8c4e267c28843b7b8 Signed-off-by: Winson Chung <winsonc@google.com>
WM Shell Test
This contains all tests written for WM (WindowManager) Shell and it's currently divided into 3 categories
- unittest, tests against individual functions, usually @SmallTest and do not require UI automation nor real device to run
- integration, this maybe a mix of functional and integration tests. Contains tests verify the WM Shell as a whole, like talking to WM core. This usually involves mocking the window manager service or even talking to the real one. Due to this nature, test cases in this package is normally annotated as @LargeTest and runs with UI automation on real device
- flicker, similar to functional tests with its sole focus on flickerness. See WM Shell Flicker Test Package for more details