Respect @Preview size settings in NavGraph thumbnails

[chandroidx]

Is your feature request related to a problem?
Currently, NavGraph thumbnails appear to be rendered with a fixed phone-sized portrait canvas, regardless of the size configuration defined on the user's @Preview annotation.

For example, even when a preview is configured as landscape:

@Preview(
  widthDp = 1280,
  heightDp = 800,
)
@NavPreview(route = SomeRoute::class, primary = true)
@Composable
fun SomeScreenLandscapePreview() {
  SomeScreen()
}

the generated NavGraph thumbnail is still rendered as a portrait image.

From what I observed, the Layoutlib renderer seems to pass a fixed device spec such as spec:width=411dp,height=891dp,dpi=420, and the Robolectric renderer also seems to use a fixed qualifier like w411dp-h891dp-xhdpi. Because of this, @Preview values such as widthDp, heightDp, and device do not affect the generated thumbnail.

Also, the default functionality of the plugin distributed through JetBrains Marketplace did not appear to apply the selected device in the NavGraph Graph tool window. For example, selecting a Tablet Device still seemed to render or display the previews as the fixed portrait phone layout.

Describe the solution you'd like:
It would be great if NavGraph could respect the size-related configuration from the user's @Preview annotation when rendering thumbnails.

Ideally, values such as the following would be reflected in the generated NavGraph thumbnail:

widthDp
heightDp
device
possibly other preview configuration values if applicable
This would allow users to provide representative landscape, tablet, foldable, or custom-sized previews and have the NavGraph render match what Android Studio Preview shows.

Describe alternatives you've considered:
I tried marking a landscape preview as the primary @NavPreview, but only the selected preview function changed. The rendered thumbnail size still remained portrait.
I also tried replacing a custom preview annotation with a direct @Preview(widthDp = ..., heightDp = ...) or @Preview(device = ...), but the generated thumbnail still used the fixed portrait canvas.
A possible workaround is to use -Pnavgraph.export.device=WxH when exporting the final graph, but this only changes the exported graph frame/letterboxing behavior. It does not make each thumbnail respect its own @Preview configuration.

[joreilly]

Also would love if landscape previews could be supported.

[skydoves]

Hi @chandroidx @joreilly, thanks for reporting this issue! In the new release 0.1.2, it respects the preview sizes. Please update both your IDE plugin & gradle version, and let me know if there're any issues you still face.

[joreilly]

Thanks @skydoves for adding this so quickly. So, I'm still having issues after updating but likely something to do with my setup. FWIW this is what Claude is telling me (which of course may not be correct!):

  Root cause

  The plugin renders thumbnails with two backends (RenderBackend.AUTO, your default):

  1. Layoutlib runs first — this is the device-aware path, and it does receive your landscape spec (it's correctly written into
  build/navgraph-render/input.json as spec:width=1280px,height=800px,dpi=240,orientation=landscape).
  2. Robolectric re-renders only the previews Layoutlib failed on — and its base class is hardcoded @Config(qualifiers = "w411dp-h891dp-xhdpi") → 822×1782 
  portrait, with @Preview(device=…) completely ignored.

  The problem: all 22 previews fail the Layoutlib pass with the same error (verified in results.json — 22/22 have brokenClasses):

  ClassNotFoundException: androidx.customview.poolingcontainer.R$id
    → androidx.compose.ui.tooling.ComposeViewAdapter
    → PoolingContainer.<clinit>

  So every preview falls back to the portrait Robolectric renderer. That's why they're all the identical 822×1782 portrait — and why your nav0_0.png raw
  Layoutlib output is a 401×29 error tile reading "androidx.compose…ComposeViewAdapter".

  The poolingcontainer artifact is on the Layoutlib classpath, but only as customview-poolingcontainer-1.0.0-runtime.jar (the runtime_library_classes_jar
  transform), which strips the generated R/R$id class. Any real Compose screen using a lazy container triggers PoolingContainer's static init, which needs
  R$id → crash.

  What this means

  - Your code is correct. OOB_THUMBNAIL_DEVICE and the @Preview(device=…) annotations are fine and will produce landscape once Layoutlib stops failing.
  - The 0.1.2 update genuinely landed (resolved plugin = 0.1.2), but its "respects preview sizes" fix lives in the Layoutlib path — which never succeeds here,
  so you never see it. This was almost certainly already portrait before 0.1.2, via the same fallback.
  - Switching renderBackend won't rescue it: LAYOUTLIB-only would give you 22 broken error tiles; ROBOLECTRIC-only is hardcoded portrait. Neither yields
  landscape.

  The fix

  This is a plugin-side render-classpath gap, not something fixable cleanly in your build — the device-free Layoutlib classpath needs the generated AAR R
  classes (specifically androidx.customview.poolingcontainer.R$id), and it's omitting them. A local stub R would collide with the real one at app-build time,
  so that's not safe.

[skydoves]

Thanks @joreilly. I confirmed it: poolingcontainer.R$id only ships in the app's linked R.jar (not the runtime jar), so when it is missing from the render classpath ComposeViewAdapter crashes and every preview falls back to the hardcoded portrait Robolectric backend. This is a plugin-side classpath gap, not your code, and separate from the size fix (which is fine but never runs while Layoutlib fails).

The plugin does try to add your app's R.jar for KMP, so to see why it is missing for your setup, could you share:

1. build/navgraph-render/results.json (the brokenClasses of one preview) and renderer.log.
2. Is the annotated module KMP with a consuming com.android.application? Is that app flavored, and if so which debug variant?
3. Does an app/build/intermediates/compile_and_runtime*r_class_jar/<variant>/process*Resources/R.jar exist, and does it contain androidx/customview/poolingcontainer/R$id.class?

[joreilly]

This is what Claude tells me for those questions :)

 1. . results.json brokenClasses + renderer.log

  Every preview reports error.status: "SUCCESS" but with a non-empty brokenClasses for androidx.compose.ui.tooling.ComposeViewAdapter. The root cause is
  identical across nodes:

  java.lang.ClassNotFoundException: androidx.customview.poolingcontainer.R$id
      at androidx.customview.poolingcontainer.PoolingContainer.<clinit>(PoolingContainer.kt:121)
      at …ViewCompositionStrategy…installFor
      at androidx.compose.ui.platform.AbstractComposeView.<init>
      at …ComposeView.<init>
      at androidx.compose.ui.tooling.ComposeViewAdapter.<init>

  So thumbnail rendering aborts at ComposeViewAdapter construction — ComposeView's <clinit> for PoolingContainer can't resolve poolingcontainer.R$id on the
  render classpath. (nav0/AllSet shows it as ClassNotFoundException; later nodes like nav10/PrivacyPolicy show the cascaded
  ExceptionInInitializerError/NoClassDefFoundError for the same class.) renderer.log is empty — no extra signal there.

  2. Is the annotated module KMP with a consuming com.android.application?

  No. this is a single-platform Android module that itself is the application 

  3. Is the app flavored? Which debug variant?

  Not flavored...relevant variant is plain debug.

  4. Does the R.jar exist and contain poolingcontainer/R$id.class?

  Yes to both. app/build/intermediates/compile_and_runtime_not_namespaced_r_class_jar/debug/processDebugResources/R.jar exists (~3.2 MB) and contains both:
  androidx/customview/poolingcontainer/R$id.class
  androidx/customview/poolingcontainer/R.class
  (The app module's debug R.jar has them too.)

  Conclusion

  The missing class is present in the module's compiled debug R.jar — it's just not on the navgraph renderer's render classpath. This is the classic
  layoutlib/Compose-preview failure mode where the aggregated transitive-dependency R classes (here androidx.customview.poolingcontainer.R) aren't fed to the
  renderer. The fix is to add the compile_and_runtime_not_namespaced_r_class_jar debug R.jar to the renderer classpath the navgraph task assembles (or
  otherwise include the generated/aggregated R classes), rather than anything about flavors or KMP. Want me to look at how the navgraph render task builds its
  classpath to pin down where to inject that R.jar?

[skydoves]

Hi @joreilly, sorry for the late reply, and thank you very much for your clear context! Would you check if the new release 0.2.1 works on your side when you have a moment?