Move SandboxContext to a separate class.
Remove all MainThreadInitializedObject references in Launcher3 and tests.
Remove ObjectSandbox interface and make RoboApplication extend
SandboxContext
Bug: 361850561
Test: Presubmit
Flag: EXEMPT dagger
Change-Id: I1a8af5e6ae59df44d8ad6732b4d6e949ac402d6c
See
https://docs.google.com/drawings/d/1JHFi_nhmQt2xPT1N3FB_1mnaRK5TVqKZ9-fSl3EA7sU/edit?usp=sharing
and
https://docs.google.com/drawings/d/1bx4WURP4uHZGzZ1bWQgpw701jkTkVqlNfA02Yt-ZtSI/edit?usp=sharing&resourcekey=0-oySjsnaCsOSrNIPqqEa0gw
for design details.
We need to make SandboxContext extend LauncherApplication because we
want create MainThreadInitializedObjects in SandboxContext's
AppComponent scope. Since MainThreadInitiliazedObjects are closed in
SandboxContext's OnDestroy() , we need to replicate same thing using
dagger as well.
- DaggerSingletonObject is same as MainThreadInitializedObject but is
used for fetching the dagger created singletons so that we can avoid
major refactors for accessing singletons. This will be deleted soon.
- DaggerSingletonTracker to track dagger created singletons and call
close() on those singleton objects created in SandboxContext scope.
- Annotate the singleton object SettingsChangeLogger constructor with @Inject and execute the statements in Main thread.
- Added createSandboxContextForTest(only for Test) to avoid creation of
dagger component in test. As follow up, I will delete this method and
introduce fakeDaggerComponents in test.
Bug: 361850561
Test: Manual
Flag: NONE Dagger Integration
Change-Id: I2d3762ea64e53baa4de190790568aec750b54201
* Add ApplicationContext qualifier and binding the application context instance so
that this context is available across dagger graph.
* Add QuickStepModule and LoggingModule
* Provide SettingsChangeLogger in dagger way. We are depending on
MainThreadInitializedObject for cleanup. We need to define a way
explicitly see how we can destroy singleton objects.
Bug: 361850561
Test: Manual
Flag: NONE Dagger Integration
Change-Id: Ia10cc500edb1d88adcca540119651f59b9bc8dc8
> Making SafeCloseable implementation mandatory, to prevent leaks during test and preview
> Removing getNoCreate method and defining executeIfCreated to avoid null pointer exceptions
> Fixing sandbox value leaking into main, by Checking sandbox against App context
> Converting sanbox to an interface instead a class
Bug: 335280439
Test: Presubmit
Flag: None
Change-Id: I951dcde871898e745ff6490a1c4f8fd1512888f5
- Added a initializeForTesting method to SandboxContext
- Also made SandboxContext non-abstract, so it can be used in tests to inject mock MainThreadInitializedObject into the SandboxContext, this should avoid mocked MainThreadInitializedObject bled into another test
Test: presubmit
Flag: None
Bug: 303328913
Change-Id: I37157d81b08b80f1e90eacca7dc2ce482cd08aa4
> Addition/removal of shortcus is already removed. This just
cleans up the unused code path
Bug: 275875209
Test: Updated tests
Flag: N/A
Change-Id: I8ab7f57b693f996920e50e8beecafcffab5167e9
- In CHANGE_SUPPORTED_BOUNDS check, it uses Map.equals, but as the value is a primitive array WindowBounds[], equals check does not deep compare the arrays and may result in false negative
- One example is when fontScale changes, DisplayController re-create bounds from WindowManagerProxy, result in new WindowBounds[] created, and the shallow compare results in unexpected CHANGE_SUPPORTED_BOUNDS
Fix: 282736623
Test: DisplayControllerTest
Change-Id: I3897595c58559192b951ecfee7c9f62a07dafe1f
* SafeCloseable objects will have their close() method
called when SandboxContext is destroyed, so we can leave
them out of the allowList.
* Long term we may want to remove the allowList altogether
and just rely on safeCloseable
Test: Locally passes
Flag: not needed
Bug: 280463854
Change-Id: I317a9d6639b25a522fe9dbcf2655b55ec68fded6
This reverts commit 455ba62b5d.
Reason for revert: Breaks tests on all targets
Bug: 196825541
Bug: 197570389
Change-Id: Ida6792a09c54dee46105b6b914a0dd1545bdf48d
go/grid-migration-preview
With this change, we can see actual grid migration in wallpaper preview.
The approach here: we use a tmp table (favorites_preview) here specifically for this preview (to write off the migration results), and load from this tmp table workspace items if migration is necessary and successful. Otherwise, we load from the current workspace.
UPDATED: this change should be completely compatible with the new multi-db grid migration algorithm. Here is why
1. In LauncherPreviewRender#renderScreenShot, I added a check to decide which grid migration preview method we should call. Once v2 preview method is implemented, it should be integrated with other parts of this change perfectly (the reason will be mentioned below).
2. While we have multiple DBs, mOpenHelper in LauncherProvider always points to the current db we are using. Queries using CONTENT_URI is routed to whatever DB mOpenHelper points to, so it works perfectly to directly operate on CONTENT_URI even when we use multi-db underneath the hood.
3. With 1 and 2 mentioned, I believe in order for this preview change to support multi-db, we only need to implement the V2 grid migration algorithm. Because most of what we are doing in this change is wrapped in GridSizeMigrationTask, it's perfectly safeguarded.
Bug: 144052839
Change-Id: Ie6d6048d77326f96546c8a180a7cd8f15b47e4c4
- Whitelist specific binder calls when handling touch during swipe up
gestures
- Only track binding for touch handling and certain launcher lifecycle
changes for now
Bug: 140246642
Change-Id: I6ba30280dd17da358662870f8719ae851536ad8b
Separating InvarantDeviceProfile out of LauncherAppState and creating
LauncherAppState only when it is actually used
Change-Id: I2ee55f53cae01f11203f94675bb5f70c65ad2b9d
Pun Butrach
Abhishek Sharma
Anushree Ganjam
MrSluffy
Brian Isganitis
Sunny Goyal
Alex Chau
Vinit Nayak
Suphon Thanakornpakapong
Patryk Michalik
Kshitij Gupta
Hyunyoung Song
Tracy Zhou
Winson Chung