rive-app / rive-app/rive-android

Regression in AnyState Transition: setNumberState + fireState Misbehaves in 9.13.8 (Works in 9.12.2)

Open
#357 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Kotlin
Stars
538
Forks
66
PR merge metrics
No merged PRs in 30d

Description

Title

Regression in AnyState Transition: setNumberState + fireState Misbehaves in 9.13.8 (Works in 9.12.2)

Description

We are using the official Rive Android Runtime API to update a state machine’s inputs by calling setNumberState immediately followed by fireState to trigger transitions from AnyState. In Rive.app’s preview, this approach reliably produces the expected state transitions (e.g. switching between different facial expressions). However, in Android Runtime 9.13.8 the following issue occurs:

  • When calling fireState immediately after setNumberState, the state machine transitions from AnyState to a specific state (e.g. "particle1" or "changeEye-idle") only once, and subsequent state updates fail to occur.
  • In contrast, downgrading to version 9.12.2 results in the expected behavior, with each trigger causing the correct state transition and corresponding animation.
Provide a Repro

Please use the minimal reproduction steps below:

  1. In your Rive file, create a state machine that uses a numeric input (e.g. facialExpressionSelector) and a trigger input (e.g. facialExpressionTrigger) to set up transitions from AnyState to specific states.
  2. In your Android app, implement a function similar to the one below to change the facial expression:
fun setFacialExpression(
    riveView: RiveAnimationView,
    machineName: String,
    expression: FacialExpression
) {
    // Update the numeric input
    riveView.setNumberState(machineName, "facialExpressionSelector", expression.intValue.toFloat())
    // Immediately fire the trigger
    riveView.fireState(machineName, "facialExpressionTrigger")
}
  1. Invoke this function from each facial expression button’s onClick handler.
Source .riv/.rev file

RIV
credit : CC-BY, Remix from Ryuhei's work
Origin

Expected behavior

The expected behavior is that, as in Rive.app’s preview, calling fireState immediately after setNumberState reliably triggers the correct transition from AnyState to the intended state (corresponding to each facial expression) and plays the appropriate animation.

Screenshots

Image

Image

Device & Versions (please complete the following information)
  • Device: Jerry Star
  • SDK Level: Android 13, API 33
  • Rive Android Runtime:
    • 9.13.8 – Issue present
    • 9.12.2 – Works as expected
Additional context

According to the official Rive documentation and GitHub source code, the methods setNumberState and fireState are designed to support transitions from AnyState properly.
Starting with version 9.13.7, improvements were made to trigger evaluation (processing triggers reliably per layer). However, in version 9.13.8, using this approach causes the state machine to transition to an incorrect state (e.g. "particle1" or "changeEye-idle") only once, and no further state updates occur. This regression is not observed in version 9.12.2, where the expected state transitions and animations are triggered reliably with each call.

Thanks

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the minimal reproduction using the linked .riv file and the Android entry points setNumberState and fireState, comparing runtime versions 9.13.8 and 9.12.2. Trace how the numeric input and trigger are evaluated for AnyState transitions. Done means repeated expression changes reliably reach the intended states and animations in 9.13.8.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, kotlin
Domain
mobile
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
50/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.