Status Update
No update yet.
Comments
ja...@gmail.com
Attached reproducing video of an app using calculateWindowSizeClass and LocalConfiguration:
On the second time resizing to be 50%/50% from smaller, the displayed configuration is incorrect.
mi...@gmail.com
When resizing the activity in multi-window mode under those conditions, there are cases where:
the Activity is not recreated Activity.onConfigurationChanged is not called View.onConfigurationChanged is not called
Is this just for 33 / is there a framework bug filed? The amount of broken things in configuration land we already had to workaround in Compose is a bit untenable. It seems like we are missing a lot of test coverage in the platform to avoid these issues hitting us in the future
pa...@gmail.com
In any case this seems like more ammunition for us to push more strongly on 'pure-compose apps should always opt out of configuration changes'
br...@gmail.com
Yes, API 33 introduced this behavior, (internal) platform bug is here:
ja...@gmail.com
I was incorrect, this is also reproducible on API 32 as well. Not reproducible on API 31.
ra...@gmail.com
Adam/Louis, how do we want to handle this one? Is there someone on platform who should take this, or since API 32 is already out in the wild maybe this should go to devrel to push more strongly on 'pure-compose apps should always opt out of configuration changes'.
al...@android.com
ma...@gmail.com
[Deleted User] <[Deleted User]>
I'm having issues on pre-33 api levels on a pure compose app (has all configChanges added in the manifest file) pared with AppCompatActivity just for multi language support. When changing the language I'm using AppCompatDelegate.setApplicationLocales(compat) which calls onConfigurationChanged on the activity. LocalConfiguration changes to the new configuration on 33+ but remains the same on pre-33. Workaround that i've found is calling if (Build.VERSION.SDK_INT < 33) contentView.dispatchConfigurationChanged(newConfig) in onConfigurationChanged. I'm guessing it's a compose issue since activity wise everything works as expected.
mi...@gmail.com
LocalConfiguration but a separate issue.
[Deleted User] <[Deleted User]>
Thanks for the heads up, I've tried to find a related issue but only managed to find this one after a brief search.
[Deleted User] <[Deleted User]>
Ok
[Deleted User] <[Deleted User]>
Thanks for the heads up, I've tried to find a related issue but only managed to find this one after a brief search.
bo...@gmail.com
[Deleted User] <[Deleted User]>
ma...@gmail.com
ja...@gmail.com
mo...@gmail.com
m....@gmail.com
de...@gmail.com
me...@gmail.com
kr...@gmail.com
su...@gmail.com
ar...@connectmedica.com
ia...@gmail.com
ke...@pinxterapp.com
ni...@google.com
[Deleted User] <[Deleted User]>
+1 for this feature.
ja...@gmail.com
[Deleted User] <[Deleted User]>
ru...@gmail.com
sa...@gmail.com
ช่วยแก้ไข browser ให้ผมหน่อยครับ
Description
However, for my app, the derived colors for both are noticeably different than the rest of my application. While the functionality of custom tabs is winning over the designer, they are not happy with the visual result.
Therefore, I'd like to be able to specify the status bar color to use with the custom tab (ie the primaryColorDark from my application). Seems reasonable if the developer doesn't specify a status bar color it uses the derived color as it does today.
As well I'd like to control the icon tint in the tool bar for the default "close" and "overflow" icons. While, specifying my own bitmap works around the "close" icon, the overflow icon tint is still controlled by the custom tab and may not match the overall theme.