Skip to content

Compose Animation: animation-android and animation-core-android are fully blanket-stripped (<remove-node path="/api/package"/>) #1446

@jonathanpeppers

Description

@jonathanpeppers

Summary

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.

Library / NuGet

(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.)

Verified state today (commit eb2f50b)

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.

source/androidx.compose.animation/animation-android/Transforms/Metadata.xml:

<metadata>
    <remove-node path="/api/package" />
</metadata>

source/androidx.compose.animation/animation-core-android/Transforms/Metadata.xml:

<metadata>
    <remove-node path="/api/package" />
    
</metadata>

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

  1. Remove the <remove-node path="/api/package" /> from both animation-android and animation-core-android Transforms/Metadata.xml. Replace with targeted <remove-node> entries only for nodes that genuinely cannot bind (this should be a small set).
  2. Run a binding pass to populate PublicAPI.Unshipped.txt.
  3. 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.
  4. After Un-strip ui-text-android and ui-unit-android Compose bindings #1440 lands, the @Composables should reappear with no further action.

Cross-references

  • compose-net tracking: jonathanpeppers/compose-net#56
  • 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).

Metadata

Metadata

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions