Split AnimationDecaySpec into two different APIs for better granularity [163329867]

Verified

Feature Request

Status Update

No update yet.

Description

ma...@google.com

created issue #1

Aug 10, 2020 04:33PM

After offline discussion with Adam we came up with the good idea around AnimaitonDecaySpec and the level of granularity we might want to add.

Basic idea: Let's split AnimationDecaySpec into two abstractions: one will be an per-animation-run "Info" thing that, and the other will allow creation of this "info" things for any particular animation given some input.

Detailed information: Let's split AnimationDecaySpec into two things:

"Info" -like thing. It's an instance of a class that, when pre populated with some data at the start of animation, can give you information pieces about animation parameters at any playtime (specified in the funciton call).

the API of this will be similar to what we have right now in AnimationSpec, BUT with one big difference: you already have all the knowledge about this particular occurrence of the animation, so you don't need to remember what was your entrypoints (start position, start velocity, etc).

Given that,

fun getValue(
        playTime: Long,
        start: V,
        startVelocity: V
    ): V

will become

fun getValue(
        playTime: Long
    ): V

and similar with other methods.

Factory like class that will generate you "Info" object given the input It's something of this shape:

interface AnimationFlingSpecFactory {
    fun generateFlingInfo(start: T, startVelocity: Float) : FlingInfo
}

(Names are TDB of course).

What this separation gives us: This granularity brings clear separation of concerns and knowledge: one thing lives for a long time and hosts somewhere higher lever (in components, states) and it's generated "Info" objects can flow into lower level abstraction that are one-time fired (such as AnimatedFloat.fling or animateTo).

Additionally, I would suggest to rename Decay to Fling (or just make it part of plain animations api) everywhere because:

It used to fling 100% of cases (unless I'm missing something)
The contract in which you don't know the destination in advance appears be false. You always know the final destination at the time of Info thing creation, if we will split it as suggested above.

For the reference and initial idea: take a look here

Going forward, we can try to stretch this idea to the whole animation, and not only decay/fling part.

Doris, I'd like to know your opinion on this.

Comments

ti...@google.com <ti...@google.com> #2Aug 10, 2020 05:38PM

A couple of questions:

1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?

ti...@google.com <ti...@google.com> #3Aug 10, 2020 05:54PM

Tested on Android 12 Emulator with custom executor, but cannot repro this issue.

ap...@google.com <ap...@google.com> #4Sep 30, 2020 12:34AM

Second crash in the description is from a real device. Experienced it myself on two different Xiaomi phones, plus lots of crashes from users in the Google Play console.
Dynamic features are not used in the application.

As a wild guess, I have downgraded build tools from 31.0.0 to 30.0.3, compileSdk from 31 to 30, and moved all work with Language ID to the service in a separate process (just to be sure that crash can kill secondary process instead of main). This combination is in beta for 2 days by now and I don't see any SIGSEGV crashes.

ti...@google.com <ti...@google.com> #5Jan 6, 2021 11:00PM

Reassigned to ma...@google.com.

Hmm, I feel the crash might be something related to separate/secondary process.

I also changed compileSdk and targetSDK to 31 but still cannot repro this issue.

ma...@google.com <ma...@google.com> #6Jan 7, 2021 05:12PM

Verified by ma...@google.com.

On the contrary, there was no separate process before, when crashes started.

In the new build (with the aforementioned changes) I can see SIGSEGV crash, but only one instead of dozens and it has a bit different backtrace:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
liblanguage_id_jni.so (offset 0x11e000)

backtrace:
  #00  pc 000000000003c7c0  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003b960  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bb48  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bafc  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000036c98  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000032714  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000031cac  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000057438  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/oat/arm64/base.odex (offset 0x57000)

Issue 163329867