Fixed
Status Update
No update yet.
Comments
ch...@google.com
ol...@google.com
we've considered this, just didn't have time to implement.
Btw, we cannot just use name() because it might be proguarded away. so we need to generate the code that matches enums to hardcoded string values.
If you are using name(), be careful about migrations since 2 different compilations might have different names for the enum values.
Btw, we cannot just use name() because it might be proguarded away. so we need to generate the code that matches enums to hardcoded string values.
If you are using name(), be careful about migrations since 2 different compilations might have different names for the enum values.
ol...@google.com
True. Even though this could be fixed by using proguard rules.
Would be great to see this in the future, it's really lots of code here ;)
Would be great to see this in the future, it's really lots of code here ;)
to...@google.com
What about the idea of using a more generic adapter which can handle all of the enums in your app? That way you could decide to persist them all with one "stone". You could choose to save them as strings, ordinals or even some other way of your choosing. But you would not have to add an adapter for every enum type in your app. You just have to add the one special enum adapter and Room would know how to use it for all enums.
Description
RemotePlaybackClient constructor crashes on API 31
Log:
Targeting S+ (version 31 and above) requires that one of FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.
Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if some functionality depends on the PendingIntent being mutable, e.g. if it needs to be used with inline replies or bubbles.