How would you access a Hilt dependency in a non-injectable ContentProvider?

What's really being asked

This question tests whether you know Hilt's escape hatch for Android framework classes that Hilt cannot inject directly, such as ContentProvider, BroadcastReceiver when not using Hilt's built-in support, or legacy third-party library entry points. It specifically checks your familiarity with the EntryPoints API, your understanding of Hilt component scoping, and your ability to distinguish between objects Hilt manages and objects instantiated by the Android framework. A senior candidate should also demonstrate awareness of context lifecycle mismatches.

The full answer

A good answer hits four things in order. First, state clearly that Hilt cannot perform member injection into a ContentProvider because the framework instantiates it, not Hilt. Second, define an interface annotated with EntryPoint and InstallIn SingletonComponent, since SettingsManager is typically application-scoped. Third, declare an accessor method such as fun settingsManager(): SettingsManager inside that interface. Fourth, inside ContentProvider.onCreate, call EntryPointAccessors.fromApplication(context.applicationContext, YourEntryPoint::class.java).settingsManager() to obtain the instance. Mentioning that the component must match where the dependency is bound shows depth.

The mistakes people make

Red flags to avoid include suggesting field injection with Inject inside the ContentProvider, which Hilt does not support for this class type. Another mistake is using EntryPoints.get with an Activity context instead of the Application context, which will crash or return the wrong component. Some candidates propose creating a manual static singleton or calling the dependency's constructor directly; this breaks Hilt's graph, testability, and scoping guarantees. Finally, installing the entry point in the wrong component, such as ActivityComponent, is an error because a ContentProvider lacks access to activity-scoped objects.

What usually comes next

An interviewer might ask why Hilt supports Activities and Fragments automatically but not ContentProviders; the answer is that Hilt uses bytecode transformation via the Gradle plugin for those classes, whereas ContentProviders are instantiated by the system before the Application's onCreate may even complete. They may also ask about thread safety; retrieving the entry point is just a map lookup, but you should store the dependency in a local field during onCreate to avoid repeated lookups during query calls. Another follow-up is how to test this; you can replace the SingletonComponent bindings in a test module because the entry point still resolves through the same Hilt graph.

A concrete example

Imagine a SettingsManager bound in a SingletonModule. You create interface SettingsEntryPoint annotated with EntryPoint and InstallIn SingletonComponent::class, with a method fun settingsManager(): SettingsManager. In your legacy ContentProvider, inside onCreate, you write val entryPoint = EntryPointAccessors.fromApplication(context, SettingsEntryPoint::class.java) and then val settingsManager = entryPoint.settingsManager(). This gives you a fully Hilt-managed instance without Hilt ever touching the ContentProvider's constructor.