Fixed
Status Update
Comments
jb...@google.com <jb...@google.com>
cl...@google.com <cl...@google.com> #2
Can you provide the below requested information to better understand the issue:
Steps to reproduce
What steps are needed to reproduce this issue?
Please explain the reproduction steps in detail.
Expected output
Could you please explain the expected behavior.
Current output
Could you please explain the current behavior.
Screen capture of the issue
Press the volume down and power buttons simultaneously. The image will appear in your gallery. Attach the screenshot image to this issue.
Steps to reproduce
What steps are needed to reproduce this issue?
Please explain the reproduction steps in detail.
Expected output
Could you please explain the expected behavior.
Current output
Could you please explain the current behavior.
Screen capture of the issue
Press the volume down and power buttons simultaneously. The image will appear in your gallery. Attach the screenshot image to this issue.
ap...@google.com <ap...@google.com> #3
Steps to reproduce:
1. Switch night mode to on/off;
2. Switch night mode to follow system.
Expected: Switch to the same night mode as the system currently uses.
Current: No changes at all.
1. Switch night mode to on/off;
2. Switch night mode to follow system.
Expected: Switch to the same night mode as the system currently uses.
Current: No changes at all.
ap...@google.com <ap...@google.com> #4
Thank you for reporting this issue. We have shared this with our product and engineering team and will update this issue with more information as it becomes available.
ap...@google.com <ap...@google.com> #5
The fix for this went out in AppCompat v1.1.0-alpha03.
cl...@google.com <cl...@google.com>
ap...@google.com <ap...@google.com> #6
The bug is still there with appcompat v1.7.0-alpha01
jb...@google.com <jb...@google.com> #7
This has been fixed internally and will be available in the Navigation 2.8.3
release.
Description
Component used: Navigation
Version used: Latest snapshot
Devices/Android versions reproduced on: Any
This bug report is to track the discussion that has started over at https://issuetracker.google.com/issues/358137294#comment6
The problem is that in minified builds, even though navigation now has support for enum classes, kotlinx.serialization at that point knows the name of the class before it was obfuscated by r8, and the navigation library is trying to find it by using the obfuscated name. That's my understanding of the issue.
The real effect this has when using the type-safe apis is that one is simply not able to have enums inside their serializable type-safe destinations.
The one workaround which works is to annotate the enum class with
@androidx.annotation.Keep
, however this is not mentioned anywhere, there is no compile-time warning for it, nor any lint which could help.I am reporting this here with the hopes that there can be some improvement in this area. Optimally this should "just work", even in minified builds, but if that turns out to be infeasible, perhaps some lint could help us out. And if that is infeasible too, perhaps a special error message at compile time could inform the user that they should use this annotation, or whatever other solution may be considered best.
There is a repro project herehttps://github.com/StylianosGakis/navigation-predictive-back-breaking-shared-element/tree/b401ce64c0d2b48585d92f96f626b970fb01bb4a which as seen here https://issuetracker.google.com/issues/358137294#comment9 shows this crash happening.