Is it possible to read the OS native Activity transition animation and somehow use it in compose to ...

# compose

[ursus]

Is it possible to read the OS native Activity transition animation and somehow use it in compose to transition screens?
Or is the only way to find android sources and reimplement it in compose?

[ursus]

https://github.com/aosp-mirror/platform_frameworks_base/blob/master/core/res/res/anim/activity_close_enter.xml

this seems to be it.

does anyone know what is <extend ? never heard of such animation

[Ian Lake]

Activity transitions are done via the Animation API (the API one, not the API 11 Animator API that the API 21 Transition APIs and AndroidX Transition API is built on top of). All of those APIs can only animate Views, so they can't be used in Compose (nor should you really; they're extremely limited in what you can do compared to Compose transitions done within a single activity)

[Ian Lake]

But to answer your other question, <extend is the framework @hide API of `ExtendAnimation`: https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/view/animation/ExtendAnimation.java

[Ian Lake]

I'll note that framework Animation cannot be used with the Predictive Back gesture inside your activity, so you wouldn't want to use that in your Compose code anyways (even in the View world, only Animator and AndroidX Transition supports the seeking needed for Predictive Back In-App)

[ursus]

okay so I can only emulate it to look the same

btw im trying to picture what extend animation does .. is it like animateContentSize and changing the width/height?

[Ian Lake]

From looking at the code, it adjusts the insets of the View, so its place in the view hierarchy isn't changing, per se, but anything that respects insets inside the View is going to be changing its size, yes

[ursus]

thats strange - when I look at my pixel 8 and start a new activity, to me it just looks like horizontal slide + fade; I don't see bounds changing

[Ian Lake]

They're just defaults, apps can and do override them, which is why trying to match the defaults is a bit of a false start in the first place

[ursus]

not sure if I follow, I want to imitate the stock animation, say like what the Settings does, what you linked seems to be it, right?

[Ian Lake]

Well, actually no. The Settings app uses Activity Embedding (that's how they get large screen support), which doesn't use any of those system animations either

[ursus]

thats strange - to me it looks transition looks the same in Settings, in Whatsapp (which is notoriously multi activity), google news,

[Ian Lake]

Yes, Whatsapp also uses Activity Embedding

[ursus]

so they get act. embedding default transition right? why do you think matching it in compose is not good?

[ursus]

btw whats your opinion on the activity embedding? it goes a bit agains the full compose app (which imo implies single activity) no?

[Ian Lake]

The tricky part is that the default animations only what it is because the Animation API is terribly limited. That's why even in the Fragment/View world, you're pointed at using the Material Motion library and its motion specs: https://m3.material.io/styles/motion/easing-and-duration/tokens-specs

[Ian Lake]

Unfortunately, the Material Motion library for Compose isn't out yet (although it is on the Compose Roadmap), which is why you have to do any of this at all

[Ian Lake]

Activity Embedding is a good stop gap to get large screen support without doing a major rewrite, but I wouldn't consider it a long term solution given the extreme limitations it has

[ursus]

Right, but what we need is a high quality default transition, like iOS has for ViewController push/present

simply crossfading, what most people do, makes the platform look less advanced