You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Xamarin.AndroidX.Compose.Animation.Android and Xamarin.AndroidX.Compose.Animation.Core.Android bindings are entirely empty today — every type in the androidx.compose.animation.* and androidx.compose.animation.core.* packages is removed by a blanket <remove-node path="/api/package" /> transform.
This means none of AnimatedVisibility, AnimatedContent, Crossfade, updateTransition, rememberInfiniteTransition, animate*AsState, Animatable, TargetBasedAnimation, SpringSpec, TweenSpec, etc. are reachable from C#.
This is the most severe of the Compose binding gaps because, unlike the other *Kt empty-wrapper cases, there is not even a class shell to call into — the entire package namespace is missing.
(Note: animation-graphics-android is fine — it has a non-empty 2.6KB PublicAPI.Unshipped.txt with no blanket-strip transform. This issue is only about animation-android and animation-core-android.)
source/androidx.compose.animation/animation-android/PublicAPI/PublicAPI.Unshipped.txt is 17 bytes — #nullable enable only, no API surface whatsoever. Same for animation-core-android.
This blanket-strip pattern is presumably historical — it likely dates back to when the binder couldn't handle Compose's heavy @JvmInline value class use at all. It should be removed.
Reproduction / evidence
compose-net cannot offer any animation primitives. The compose-net tracking issue is jonathanpeppers/compose-net#56. Even hand-written JNI bridges would require manually rebuilding the entire androidx.compose.animation.core type system in C# (transitions, animation specs, easing curves, etc.) — work that is unreasonable to duplicate when the binder should be doing it.
The Kotlin API surface is substantial: AnimatedVisibility, AnimatedContent, Crossfade, updateTransition<S, T>, Transition<S>, Animatable<T, V>, AnimationSpec<T>, TweenSpec, SpringSpec, KeyframesSpec, RepeatableSpec, InfiniteRepeatableSpec, EnterTransition, ExitTransition, FiniteAnimationSpec, MutableTransitionState, etc.
Suggested fix
Remove the <remove-node path="/api/package" /> from both animation-android and animation-core-androidTransforms/Metadata.xml. Replace with targeted <remove-node> entries only for nodes that genuinely cannot bind (this should be a small set).
Run a binding pass to populate PublicAPI.Unshipped.txt.
Expect most user-facing @Composables to remain stripped until dotnet/java-interop#1440 lands (they all use @JvmInline value class params). But that's still strictly better than today's full strip: the supporting types (Transition, AnimationSpec, easing curves, etc.) will bind, the *Kt class wrappers will exist as containers, and end users on compose-net (and similar projects) can write hand-written JNI bridges against real bound types instead of Java.Lang.Object handles.
Master inline-class blocker: dotnet/java-interop#1440 — relevant only for the @Composable entry points; the supporting type system should bind regardless once the blanket strip is removed.
For comparison, no other Compose library uses the blanket <remove-node path="/api/package" /> pattern today (verified across runtime-android, ui-android, ui-graphics-android, ui-text-android, foundation-android, foundation-layout-android, material3-android, navigation-compose-android).
Summary
The
Xamarin.AndroidX.Compose.Animation.AndroidandXamarin.AndroidX.Compose.Animation.Core.Androidbindings are entirely empty today — every type in theandroidx.compose.animation.*andandroidx.compose.animation.core.*packages is removed by a blanket<remove-node path="/api/package" />transform.This means none of
AnimatedVisibility,AnimatedContent,Crossfade,updateTransition,rememberInfiniteTransition,animate*AsState,Animatable,TargetBasedAnimation,SpringSpec,TweenSpec, etc. are reachable from C#.This is the most severe of the Compose binding gaps because, unlike the other
*Ktempty-wrapper cases, there is not even a class shell to call into — the entire package namespace is missing.Library / NuGet
androidx.compose.animation:animation-android,androidx.compose.animation:animation-core-androidXamarin.AndroidX.Compose.Animation.Android,Xamarin.AndroidX.Compose.Animation.Core.Androidsource/androidx.compose.animation/animation-android/source/androidx.compose.animation/animation-core-android/(Note:
animation-graphics-androidis fine — it has a non-empty 2.6KBPublicAPI.Unshipped.txtwith no blanket-strip transform. This issue is only aboutanimation-androidandanimation-core-android.)Verified state today (commit eb2f50b)
source/androidx.compose.animation/animation-android/PublicAPI/PublicAPI.Unshipped.txtis 17 bytes —#nullable enableonly, no API surface whatsoever. Same foranimation-core-android.source/androidx.compose.animation/animation-android/Transforms/Metadata.xml:source/androidx.compose.animation/animation-core-android/Transforms/Metadata.xml:This blanket-strip pattern is presumably historical — it likely dates back to when the binder couldn't handle Compose's heavy
@JvmInline value classuse at all. It should be removed.Reproduction / evidence
compose-netcannot offer any animation primitives. The compose-net tracking issue is jonathanpeppers/compose-net#56. Even hand-written JNI bridges would require manually rebuilding the entireandroidx.compose.animation.coretype system in C# (transitions, animation specs, easing curves, etc.) — work that is unreasonable to duplicate when the binder should be doing it.The Kotlin API surface is substantial:
AnimatedVisibility,AnimatedContent,Crossfade,updateTransition<S, T>,Transition<S>,Animatable<T, V>,AnimationSpec<T>,TweenSpec,SpringSpec,KeyframesSpec,RepeatableSpec,InfiniteRepeatableSpec,EnterTransition,ExitTransition,FiniteAnimationSpec,MutableTransitionState, etc.Suggested fix
<remove-node path="/api/package" />from bothanimation-androidandanimation-core-androidTransforms/Metadata.xml. Replace with targeted<remove-node>entries only for nodes that genuinely cannot bind (this should be a small set).PublicAPI.Unshipped.txt.@Composables to remain stripped until dotnet/java-interop#1440 lands (they all use@JvmInline value classparams). But that's still strictly better than today's full strip: the supporting types (Transition,AnimationSpec, easing curves, etc.) will bind, the*Ktclass wrappers will exist as containers, and end users on compose-net (and similar projects) can write hand-written JNI bridges against real bound types instead ofJava.Lang.Objecthandles.@Composables should reappear with no further action.Cross-references
@Composableentry points; the supporting type system should bind regardless once the blanket strip is removed.<remove-node path="/api/package" />pattern today (verified acrossruntime-android,ui-android,ui-graphics-android,ui-text-android,foundation-android,foundation-layout-android,material3-android,navigation-compose-android).