Describe Hilt's component hierarchy and scope injection rules

What's really being asked

This question probes whether you understand that Hilt is not magic but a code generator that maps Dagger components onto the Android lifecycle. The interviewer cares if you can reason about object lifetime, memory safety, and the directionality of dependency graphs. Senior candidates should demonstrate that they see scoping as a contract about lifespan, not just a performance optimization or a namespace.

The full answer

First, enumerate the standard generated hierarchy in order: SingletonComponent at the root, followed by ActivityRetainedComponent, then ActivityComponent, then FragmentComponent, then ViewComponent, plus ViewWithFragmentComponent which sits under FragmentComponent. Second, explain the structural rule: every component is a subcomponent of its parent, meaning parents outlive children and dependencies can only flow downward. Third, clarify why this structure exists: it mirrors Android's own lifecycle tree so that when an activity is destroyed, its component and all scoped objects under it can be garbage collected without leaking backward into the application singleton. Fourth, answer the injection consequence directly: attempting to inject an ActivityScoped object into a Singleton-scoped object is a compile-time error because Hilt's annotation processor validates scope compatibility; a Singleton lives for the application lifetime and cannot safely hold a reference to something bound to a shorter-lived activity.

The mistakes people make

A major red flag is saying the code would compile and leak at runtime. Hilt fails the build because the scope hierarchy is enforced by the Dagger compiler, not checked at runtime. Another red flag is conflating ActivityRetainedComponent with ActivityComponent; the retained component survives configuration changes while the activity component does not, so their scoped objects have different lifetimes. A third red flag is suggesting you can work around the restriction by using a Provider or Lazy wrapper; while Provider can defer instantiation, it does not change scope compatibility, and Hilt still rejects the binding graph.

What usually comes next

The interviewer may ask how to share activity-level data with a singleton without breaking scope. The correct pattern is to use a factory or assisted injection so the singleton creates short-lived objects on demand rather than holding them. They may also ask about custom components; a strong answer notes that Hilt allows custom components but they must still fit into the existing parent-child tree and obey the same lifetime rules. Another follow-up is the difference between ActivityScoped and ActivityRetainedScoped; the retained scope survives rotation but dies when the user finishes the activity, whereas the non-retained scope dies on every configuration change.

A concrete example

Imagine a UserRepository annotated with Singleton that tries to inject an ActivityNavigator annotated with ActivityScoped. The UserRepository might cache data in a Map and live for hours, but the ActivityNavigator holds a reference to the current Activity. If Hilt allowed this, rotating the phone would destroy the activity yet the singleton repository would keep the old Activity instance alive, causing a massive memory leak. Hilt prevents this at compile time by rejecting the binding, forcing you to either scope the navigator higher, lower the repository scope, or pass the navigator as a method argument when needed.