RippleDrawable implementation of Compose ripple sometimes crashes with NullPointerException: null cannot be cast to non-null type android.view.View [188569367]

Fixed

Bug

Status Update

No update yet.

Description

za...@gmail.com

created issue #1

May 19, 2021 05:19AM

Jetpack Compose release version: 1.0.0-beta07 Android Studio Build: 7.1.0-alpha01

It seems that in some cases the new RippleDrawable-backed ripple implementation in beta07 crashes.

I haven't figured out what the exact conditions required are to get the ripple to crash, but you should be able to reproduce the crash by checking out the zachklipp/repro-ripple-bug branch of the compose-richtext repository from GitHub and running the sample app (there's only one app in the project).

The stack trace starts as follows (full trace attached):

java.lang.NullPointerException: null cannot be cast to non-null type android.view.View
    at androidx.compose.material.ripple.PlatformRipple.findNearestViewGroup(Ripple.android.kt:115)
    at androidx.compose.material.ripple.PlatformRipple.rememberUpdatedRippleInstance-942rkJo(Ripple.android.kt:78)
    at androidx.compose.material.ripple.Ripple.rememberUpdatedInstance(Ripple.kt:125)
    at androidx.compose.foundation.IndicationKt$indication$2.invoke(Indication.kt:108)
    at androidx.compose.foundation.IndicationKt$indication$2.invoke(Indication.kt:106)
    at androidx.compose.ui.ComposedModifierKt$materialize$result$1.invoke(ComposedModifier.kt:73)
    at androidx.compose.ui.ComposedModifierKt$materialize$result$1.invoke(ComposedModifier.kt:68)
    at androidx.compose.ui.Modifier$Element$DefaultImpls.foldIn(Modifier.kt:107)
    at androidx.compose.ui.ComposedModifier.foldIn(ComposedModifier.kt:46)
    at androidx.compose.ui.CombinedModifier.foldIn(Modifier.kt:149)
    at androidx.compose.ui.CombinedModifier.foldIn(Modifier.kt:149)
    at androidx.compose.ui.ComposedModifierKt.materialize(ComposedModifier.kt:68)
    at androidx.compose.ui.ComposedModifierKt$materialize$result$1.invoke(ComposedModifier.kt:74)
    at androidx.compose.ui.ComposedModifierKt$materialize$result$1.invoke(ComposedModifier.kt:68)
    at androidx.compose.ui.Modifier$Element$DefaultImpls.foldIn(Modifier.kt:107)
    at androidx.compose.ui.ComposedModifier.foldIn(ComposedModifier.kt:46)
    at androidx.compose.ui.ComposedModifierKt.materialize(ComposedModifier.kt:68)
    at androidx.compose.ui.ComposedModifierKt$materialize$result$1.invoke(ComposedModifier.kt:74)
    at androidx.compose.ui.ComposedModifierKt$materialize$result$1.invoke(ComposedModifier.kt:68)
    at androidx.compose.ui.Modifier$Element$DefaultImpls.foldIn(Modifier.kt:107)
    at androidx.compose.ui.ComposedModifier.foldIn(ComposedModifier.kt:46)
    at androidx.compose.ui.CombinedModifier.foldIn(Modifier.kt:149)
    at androidx.compose.ui.ComposedModifierKt.materialize(ComposedModifier.kt:68)
    at androidx.compose.ui.layout.LayoutKt$materializerOf$1.invoke-Deg8D_g(Layout.kt:174)
    at androidx.compose.ui.layout.LayoutKt$materializerOf$1.invoke(Layout.kt:173)
    at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:116)
    at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:34)

stacktrace.txt

35 KB

View

Download

Comments

ma...@google.com <ma...@google.com> May 19, 2021 11:15AM

Assigned to lp...@google.com.

lp...@google.com <lp...@google.com> #2May 19, 2021 01:47PM

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?

za...@gmail.com <za...@gmail.com> #3May 19, 2021 09:15PM

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

ap...@google.com <ap...@google.com> #4May 25, 2021 12:30PM

Marked as fixed.

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.

Issue 188569367

Description

Issue summary

Comments

ma...@google.com <ma...@google.com> May 19, 2021 11:15AM

lp...@google.com <lp...@google.com> #2May 19, 2021 01:47PM

za...@gmail.com <za...@gmail.com> #3May 19, 2021 09:15PM

ap...@google.com <ap...@google.com> #4May 25, 2021 12:30PM

Add comment

Issue metadata