A CoreStartable class represents a chunk of SystemUI functionality that is initialized at startup time, independent of the rest of the system. Which CoreStartables are included and run can be customized per-build via Dagger.
The base class contains nominal functionality, making it lightweight and inexpensive to construct. Unlike Activities, Services, and similar Android constructs, CoreStartables do not have unique context, and have no lifecycle methods except for a singular #start method that is called once.
Subclass CoreStartable. Put any initialization logic in its #start method. Preferably, put it in its own source package (with related code) to keep it organizationally distinct from other code in SystemUI.
Mark its class with @SysUISingleton and its constructor with @Inject.
Define a corresponding Dagger module in the same package. The name of the module should follow the pattern: “StartModule” where is replaced with the name of the CoreStartable.
Put the following definition inside your new module:
@Binds @IntoMap @ClassKey(Feature.class) abstract CoreStartable bindFeature(Feature impl);
CoreStartables should be single-feature focused. If you need something run at startup time that doesn't have a clear initialization path in existing code, strongly consider defining a new CoreStartable instead of inserting into a random place in an existing one.
CoreStartables should be order independent. They currently are started in an arbitrary but deterministic order. We do not promise that this order won't change in the future, however. We do not provide a mechanism for changing the order. If you need some other part of the system to come online first, consider adding a listener to that part of the system.