An OSGi bundle stuck in Installed or Resolved state instead of Active is one of the most common AEM support tickets, and the cause is almost always visible if you know where to look.
Installed state: unresolved package imports
A bundle in Installed state cannot even resolve its dependencies. Open the OSGi console's bundle detail view and check "Imported Packages" — any entry marked as unsatisfied points directly at the missing dependency. This is usually either a missing bundle deployment or a version range mismatch between what your bundle imports and what is actually exported on the instance.
Resolved but not Active: missing service references
A bundle that resolves but never activates typically has a Declarative Services component waiting on a mandatory service reference that never appears. Check the Felix SCR / Config Manager console for the component's state — "Unsatisfied" references list exactly which service is missing.
Cyclic dependencies
Two components that reference each other as mandatory dependencies can deadlock activation. This is less common but harder to spot; the symptom is usually a set of related bundles that all sit in the same non-active state with no individually obvious missing dependency.
A practical checklist
- Check the bundle's exact state (Installed vs Resolved vs Active) — they point to different root causes
- Review Imported/Exported Packages for version range mismatches
- Check the SCR console for unsatisfied component references
- Grep the error log around the bundle's install timestamp for stack traces, not just the OSGi console state
- If multiple bundles fail together after a deployment, suspect a shared dependency version bump rather than N unrelated bugs
Most of these failures are caused by a deployment ordering or version mismatch problem rather than a logic bug in the bundle's own code — which is why checking the console state first saves far more time than reading through application code.