IssueTracker

Since this is happening in Tink, rather than in the AndroidX library, it would be best to open an issue with that project, as there isn't an easy way for us to fix this.

Tink is the library that does the heavy lifting in Jetpack Security.

And yes, potentially raising that issue with the Tink team directly could help.

+1

I'm pretty new on this project and I haven't dug deep into all of the strange behavior reported. But having read many of the bug reports my initial guess is crashes on initialization are related to encrypted files that got restored from a backup. If you back up all of an app's files - including EncryptedSharedPreferences - and then restore after moving to a new device, factory restoring a device, or perhaps even uninstalling and reinstalling an app, you will crash and it might not be clear why. The recommended way to use the security jetpack library lends to these kinds of errors. The files get encrypted with a key that won't be available inside of a backup copy. So decryption will always fail if that key isn't there when restoring from a backup.

You can see the warning I added in your editor as a documentation comment on the EncryptedFile and EncryptedSharedPreferences classes. Those comments get copied into the reference info on the jetpack website:

https://developer.android.com/reference/androidx/security/crypto/EncryptedFile

https://developer.android.com/reference/androidx/security/crypto/EncryptedSharedPreferences

But I think it would be much better for us to provide an Android backup agent implementation that does the filtering for you.

You can definitely accomplish this with XML configuration: https://developer.android.com/guide/topics/data/autobackup#IncludingFiles

But you can also write a custom backup agent class to do the work at runtime. I will update the documentation later to include a reference XML configuration.

Thanks for your feedback!

The issue still persists.

Same for me too. I updated the Lifecycle lib to v2.8.2 and Compose BOM to v2024.06.00 which incorporate v1.6.8 of Compose libs. Still, the app got this exception and crashed, but only in the release mode and not in debug mode. Unfortunately, I got the crash in the production app after its release. After downgrading the Lifecycle lib to v2.7.0, it is working fine in the production app. Immediately, I had to release another patch version, so the users do not complain about app not working.

Comment #26, Comment #27, Comment #28, Comment #29, Comment #30:

We have received a similar report at b/346808608, where the author suggests a workaround (adding -keep class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt { *; } to your ProGuard rules).

Although we have included a custom ProGuard rule as part of our fix, the rule is not working as intendend across all projects. We are currently investigating the problem, see here for more details.

I can confirm it's still an issue for me with Compose BOM "2024.06.00" and lifecycle 2.8.2.

I added these lines to proguard to fix the issue:

-if public class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt {
    public static *** getLocalLifecycleOwner();
}
-keep public class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt {
    public static *** getLocalLifecycleOwner();
}

Following up on the issue mentioned in comment#26: a fix for b/346808608 is scheduled to be included in our upcoming hot-fix release, version 2.8.3 -- for additional details, please refer to this comment.

Following up on the issue mentioned in comment#26: there was a mix-up, and the Lifecycle 2.8.3 artifacts won't be available until Monday.

Lifecycle 2.8.3 is now available on maven.google.com.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.lifecycle:lifecycle-runtime-compose:2.9.0-alpha01
• androidx.lifecycle:lifecycle-runtime-compose-android:2.9.0-alpha01
• androidx.lifecycle:lifecycle-runtime-compose-desktop:2.9.0-alpha01