Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Color] Fix dynamic color support check #4192

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

pubiqq
Copy link
Contributor

@pubiqq pubiqq commented May 27, 2024

No description provided.

@@ -401,7 +401,7 @@ public static boolean isDynamicColorAvailable() {
if (VERSION.SDK_INT < VERSION_CODES.S) {
return false;
}
if (BuildCompat.isAtLeastT()) {
if (VERSION.SDK_INT >= VERSION_CODES.S_V2) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, shouldn't this be >= VERSION_CODES.TIRAMISU in order to be equivalent to BuildCompat.isAtLeastT()? Or > VERSION_CODES.S_V2.

Android T is the first version where all devices should support dynamic color by default, so we don't want to return true for S_V2.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, shouldn't this be >= VERSION_CODES.TIRAMISU in order to be equivalent to BuildCompat.isAtLeastT()? Or > VERSION_CODES.S_V2.

No, that's not a mistake. When the BuildCompat.isAtLeastT() check was written, the library used androidx.core:core:1.7.0 (transitive dependency from androidx.appcompat:appcompat:1.4.0), and in it, the code name "T" meant the version that comes after "S" (see implementation).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Android T is the first version where all devices should support dynamic color by default, so we don't want to return true for S_V2.

?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's an interesting find re: the initial BuildCompat.isAtLeastT() implementation, but tbh I don't think that was intentional on our part.

Dynamic Color was initially introduced in Android 12, but OEMs had to opt-in to generate the system_ colors at runtime based on the wallpaper / user choice, otherwise those system_ colors would just remain at their hardcoded defaults. That's why we have the device / manufacturer allow list. I'm fairly certain that T is the first version where that behavior of updating system_ colors was baked into the Android Framework / OS by default, but I'll have to do some more digging to make sure.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regardless, I would say the current behavior of the library (with up-to-date dependencies), both internally and externally is that BuildCompat.isAtLeastT() means VERSION.SDK_INT >= VERSION_CODES.T. So I think we should follow that as opposed to reverting to the potentially initial / accidental behavior from years ago.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The behavior you require is implemented in the Android 12 patches. They're included in Android 12L and above.

@pubiqq pubiqq requested a review from dsn5ft May 29, 2024 16:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants