Hilt makes Dependency Injection in Android a breeze, but its compile-time magic can sometimes lead to confusing runtime crashes, especially when dealing with components like Services or Broadcast Receivers that don't support @AndroidEntryPoint directly in the same way Activities do.

The Hilt-Generated Class Error

If you see an error like "Hilt-generated class should be public", it's usually because your Activity or Fragment is private or internal. Hilt needs to generate a wrapper class in the same package, so visibility matters.

Wrong Visibility @AndroidEntryPoint
internal class MyFragment : Fragment() { ... } // May cause issues

EntryPoints for Non-Supported Classes

When you need to inject something into a class that Hilt doesn't support out of the box (like a custom View or a ContentProvider), you must use EntryPoints. This is the manual way to "grab" a dependency from the Hilt graph.

Manual EntryPoint @EntryPoint
@InstallIn(SingletonComponent::class)
interface MyEntryPoint {
fun getRepository(): MyRepository
}

The Golden Rule

Always ensure your Application class is annotated with @HiltAndroidApp. Without this, the entire dependency graph fails to initialize, leading to the dreaded "IllegalStateException: Hilt Components have not been initialized".

Summary

Visibility and EntryPoints are the most common stumbling blocks in Hilt. Keep your classes public and understand when to use manual EntryPoints. Injection success!