IssueTracker

Component used: androidx.startup:startup-runtime

Version used: 1.0.0

Devices/Android versions reproduced on: N/A

Feature Request

I would like to know if it would be possible or if there are any plans to allow androidx.startup.Initializer.Initializer to define dependencies of non-concrete Initializer classes, these could be simple abstractions that can be defined as dependencies. I suspect that this request would require some reworking on how dependencies are discovered from androidx.startup.AppInitializer and potentially break initializeComponent method when used with an abstraction?

Use case

In the time that I have been using startup-runtime I have often had difficulty defining dependencies without having to cross multi-module boundaries, for example:

Let's say I have a few core feature modules that handle groups of initialisation tasks that I define to run in this order (logging -> dependency injector -> work managers) which I can simply solve by having a core module with concrete implementations of (logging and dependency injector) and then having an abstract class that has a dependency on the dependency injector that all of my other features extend.

This works fine and well but what if I want to have another layer of an initialise which I would extend in some other modules that should be a dependency to other Initializers?