rive-android_issues_306.kt

// This Gist is a simple setup repro for https://github.com/rive-app/rive-android/issues/306
// using Rive-Android 8.3.0 ("app.rive:rive-android:8.3.0")


/**
 * Displays [Rive](https://rive.app/) animations
 *
 * NOTE:
 * Rive native support for Compose is tracked at https://github.com/rive-app/rive-android/issues/259
 */
@Composable
fun RiveImage(
    @ResId animationRessourceId: Int,
    modifier: Modifier = Modifier,
    stateController: RiveStateController? = null,
) {
    // We wrap the AndroidView in a Box to correct positioning, for some reason when it was just
    // the AndroidView it wouldn't center the RiveAnimationView as expected (slightly lower vertically)
    Box(modifier = modifier) {
        AndroidView(
            factory = { context ->
                RiveAnimationView(context)
            },
            modifier = Modifier.align(Alignment.Center)
        ) { animationView ->
            animationView.setRiveResource(animationResourceId)
        }
    }
}


@Composable
fun LoadingContent(
  loading: State<Boolean>,
  modifier: Modifier = Modifier,
  content: @Composable () -> Unit
) {
  Box(modifier = modifier) {
    content()

    AnimatedVisibility(
        visible = loading.value,
    ) {
      RiveImage(
        animation = RiveAnimation.Resource(R.raw.tangrams),
        modifier = Modifier
            .fillMaxSize()
            .background(MaterialTheme.colors.surface)
            .contentDescription("Loading...")
        )
    }
  }
}

Hi @brianwernick Do you have some time to follow up on Umberto's comments?

@umberto-sonnino @caudetgit hey guys, Brian is out for the week. His teammate is reviewing it and will update here.

@umberto-sonnino @caudetgit

Hi guys. We have reviewed your code comments. We don't think they're very significant changes but we will test them. We will have an update on our testing next week.

I wanted to re-iterate that this crash is intermittent and hard to reproduce, but it has raised our crash rate by +0.6%, which given our large user base is significant. If you repeat your testing accordingly you will experience the crash.

In the meantime we've fielded a version of our app without any Rive assets while we continue to work this issue with you.

I wanted to re-iterate that this crash is intermittent and hard to reproduce, but it has raised our crash rate by +0.6%, which given our large user base is significant. If you repeat your testing accordingly you will experience the crash.

Hi @marcus-hobbs, I tried running that Compose example for a few hours in an emulator, but that hasn't crashed yet.

In any case, we'd love to get to the bottom of this, looking forward to your update next week!

@umberto-sonnino thanks for spending time trying to reproduce. For future testing I recommend trying on a device--we haven't been able to reproduce in the emulator either.

@umberto-sonnino thanks for spending time trying to reproduce. For future testing I recommend trying on a device--we haven't been able to reproduce in the emulator either.

@marcus-hobbs I also tried the sample above on a device for a few hours, but it kept going without hiccups.
Would just running the code above show the crash on your end? Or does it appear in more dynamic scenarios? (e.g. transitioning between views, having a more complex ViewGroup hierarchy, etc.)

@umberto-sonnino The code above is essentially what we have implemented in production that has the crashes; which to echo what @marcus-hobbs has said, has been pretty difficult to reproduce locally (I've encountered it a few times on a Pixel 7 emulator during development in the surrounding code).

That said, the code above is a simplification of our actual usage that focuses on the Rive specific implementation. In our app the LoadingContent is in a slightly more complex scenario since the screen this is contained by is under a jetpack navigation (compose) graph and a scaffold so there are more upstream transitions occurring. So it is possible that this crash occurs during a recomposition or potentially a canceled composition.

@umberto-sonnino The code above is essentially what we have implemented in production that has the crashes; which to echo what @marcus-hobbs has said, has been pretty difficult to reproduce locally (I've encountered it a few times on a Pixel 7 emulator during development in the surrounding code).

That said, the code above is a simplification of our actual usage that focuses on the Rive specific implementation. In our app the LoadingContent is in a slightly more complex scenario since the screen this is contained by is under a jetpack navigation (compose) graph and a scaffold so there are more upstream transitions occurring. So it is possible that this crash occurs during a recomposition or potentially a canceled composition.

@brianwernick Mmh yeah, I'm wondering if this is tied more to the lifecycle of the View than the example itself. We're trying to build a repro by stress-testing the view lifecycle a bit.

Also, there's a reference to a RiveStateController, but in the code snippet that's not being used. That might be relevant to reproduce the crash. Are you saving/restoring state? If so, could you share those bits too?

The RiveStateController was unintentionally left in the example; it's from a more recent branch that we were adding support for changing the stateMachine, animations, and listeners but it's not currently used or tied-in to the code that we are running in production.

I'll play around and see if we can find any relevant patterns from crash reporting, etc. and update rive-app/rive-android#306 with any information we find.