Status Update
Comments
ma...@google.com <ma...@google.com> #2
1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?
sg...@google.com <sg...@google.com>
ap...@google.com <ap...@google.com> #3
Tested on Android 12 Emulator with custom executor, but cannot repro this issue.
sg...@google.com <sg...@google.com> #4
-
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.
na...@google.com <na...@google.com> #5
Hmm, I feel the crash might be something related to separate/secondary process.
I also changed compileSdk and targetSDK to 31 but still cannot repro this issue.
Description
Environment
Description
The DatePicker component in Jetpack Compose Material 3 does not respect the locale setting provided through DatePickerState. Despite explicitly setting a locale (e.g., Locale("hr", "HR")), the DatePicker continues to use the system's default locale as determined by LocalConfiguration.current.locales[0]. The specified locale is installed on the device.
Expected Behavior
When a locale is explicitly set in DatePickerState, the DatePicker UI should adapt to use this locale for localizing labels, captions, titles, etc. If the specified locale is not installed on the device, it should fall back to using LocalConfiguration.current.locales[0].
Current Behavior
The DatePicker ignores the explicitly set locale in DatePickerState and always uses the system's default locale. This results in the UI not being localized according to the specified locale, affecting user experience for non-default language users.
Steps to Reproduce
Code sample
Probable Cause
The DatePicker implementation seems to ignore the locale parameter in DatePickerState, defaulting to the system's default locale. This is evident in the construction of the calendarModel within the DatePicker, where defaultLocale() is always used regardless of the locale specified in the state.
Suggested Fix
Modify the DatePicker implementation to respect the locale provided in DatePickerState when creating the calendarModel, ensuring that UI elements are correctly localized.
Additional Information
While the recommended approach for managing DatePickerState is through rememberDatePickerState, it does not allow for explicit localization settings via the locale parameter. This limitation becomes apparent in use cases requiring specific locale settings that differ from the system default. Although it's possible to manually implement a rememberSaveable solution that includes the locale, providing a first-class support or clearer guidance for such scenarios within the Compose framework would enhance its usability and flexibility for developers facing similar localization requirements.