In those cases, creating a new LauncherAppCompoent and storing it in
the application context
Bug: 372180905
Test: atest LauncherComponentProviderTest
Flag: EXEMPT bugfix
Change-Id: Ibf517a23801138b1fa18e8e4a7adbdedb994365b
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
Sunny Goyal
Anushree Ganjam