material-components / material-components-android

Modular and customizable Material Design UI components for Android
Apache License 2.0
16.38k stars 3.07k forks source link

Bug: DynamicColors.isDynamicColorAvailable() isn't reliable as it says it's supported on devices that it's not #2775

Closed AndroidDeveloperLB closed 2 years ago

AndroidDeveloperLB commented 2 years ago

Description: Full description of issue here I requested to be able to check whether the current device has dynamic colors being generated from the wallpaper (or live wallpaper such as here and here) or not: https://github.com/material-components/material-components-android/issues/2772 I was told that DynamicColors.isDynamicColorAvailable() can be used for that. So I made a sample app that just prints to the log if it's available or not.

Expected behavior: Screenshots and/or description of expected behavior For these devices, it says it's supported, but I know for a fact that it's not, because setting a live wallpaper that sends the colors or setting a simple all-green/red/yellow wallpaper won't affect the OS and won't affect other apps (such as Gmail).

For example, for this device&Android-version it says that it's supported, yet it's not (check the code to understand the extra info) :

In fact, it has no option in the "wallpapr and style" to apply the colors based on the wallpaper:

screenshots.zip

Source code: The code snippet which is causing this issue

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        val isSupported = DynamicColors.isDynamicColorAvailable()
        Log.d("AppLog", "isSupported?$isSupported")
        val arch = getArchitecture()
        val performanceClass = getPerformanceClassValue()
        val deviceInfo =
            "MODEL:${Build.MODEL};BRAND:${Build.BRAND};DISPLAY:${Build.DISPLAY};DEVICE:${Build.DEVICE};BOARD:${Build.BOARD};HARDWARE:${Build.HARDWARE};MANUFACTURER:${Build.MANUFACTURER};ID:${Build.ID}" +
                    ";PRODUCT:${Build.PRODUCT};RELEASE:${Build.VERSION.RELEASE};SDK_INT:${Build.VERSION.SDK_INT};INCREMENTAL:${Build.VERSION.INCREMENTAL};CODENAME:${Build.VERSION.CODENAME};architecture:$arch" +
                    ";MEDIA_PERFORMANCE_CLASS:${performanceClass}"
        Log.d("AppLog", "deviceInfo:$deviceInfo")
    }

    companion object {
        fun getArchitecture() =
            kotlin.runCatching { System.getProperty("os.arch") }.getOrNull() ?: ""

        fun getPerformanceClassValue(): Int {
            return try {
                if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S)
                    Build.VERSION.MEDIA_PERFORMANCE_CLASS
                else -1
            } catch (e: Throwable) {
                e.printStackTrace()
                -1
            }
        }
    }
}

Sample app (check logs and/or UI): My Application.zip

Android API version: Android API version here Already wrote above : API 31

Material Library version: Material Android Library version you are using here (e.g., 1.1.0-alpha07)

implementation 'com.google.android.material:material:1.7.0-alpha02'

Device: Device on which the bug was encountered here Already mentioned: Galaxy A32.

dsn5ft commented 2 years ago

won't affect the OS and won't affect other apps (such as Gmail)

Checking the OS and other apps such as Gmail is not the best way to determine whether dynamic color is available on a device. As I mentioned in #2772, DynamicColors.isDynamicColorAvailable() should just be related to whether the dynamic system colors like @android:color/system_accent1_600 are valid. It's then up to the OS and other apps such as Gmail to decide whether they are using those colors.

Re: Samsung Galaxy A32 with Android 12, as long as the device is running Samsung OneUI 4.1 or above (source), then the dynamic color system resources should be working.

Instead of looking at the OS/apps as the signal, I think you should put a dynamic color like @android:color/system_accent1_600 in your sample app to see if it updates as you expect when the wallpaper is changed.

AndroidDeveloperLB commented 2 years ago

@dsn5ft The OS is on One UI 4.1. Can you prove that it is actually working, then? Show me a valid, 100% working way to prove a device has Material You being implemented (or not implemented). To me all signs show that it's not implemented at all.

So far I've found that:

  1. The OS colors don't change.
  2. Gmail doesn't change its colors, and also other apps such as Google Clock.
  3. The OS doesn't have the ability to choose the color paletes from the wallpaper. There is just one there, of the same exact colors, no matter what you have.
  4. The sample app here ("catalog") shows the same exact colors for the "Demo" and "Dynamic Palette Demo" under "color" . All changes to wallpapers lead to the same blue system accent colors, including the one you've mentioned, of course ("system_accent1_600" ). Tested pure yellow, pure green, and pure red.
  5. Also tried to restart the OS (maybe changes apply after that...)

This is what's shown on the sample, no matter which wallpaper I choose or which colors I choose for the live wallpaper:

scrcpy_ZUpn2oQaEz.zip

Wouldn't it make sense that if a live wallpaper is sending the OS pure green (#FF00FF00) or pure yellow (#FFFFFF00) or pure red (#FFFF0000) as the same color for primary&secondary&ternary colors, the OS would use it or generate some different colors for other apps?

I see no reason here to believe that Material You works on Samsung for this version of the OS. What's the point in having "color palette" settings, if nothing can be chosen there, and the OS doesn't do anything with the colors of the wallpapers?

Even if some random colors of the various ones would change (like "system_accent1_600"), why would it matter if the apps that Google itself claim that are ready for Material you - don't show that they do, and probably no other app, either?

Please explain me what is the test that Google has performed on this device, to decide that it has "Material You". How did Google verify it on this device?

drchen commented 2 years ago

The sample app here ("catalog") shows the same exact colors for the "Demo" and "Dynamic Palette Demo" under "color" . All changes to wallpapers lead to the same blue system accent colors, including the one you've mentioned, of course ("system_accent1_600" ). Tested pure yellow, pure green, and pure red.

This feels a bit suspicious to me. Can you attach both screenshots of the two demos?

I agree it will be nice if Android framework can provide an API to indicate if dynamic colors are supported but unfortunately it doesn't.

If a certain Samsung OS version with OneUI 4.1+ doesn't have dynamic colors support, it probably be a Samsung OS issue. (But please be aware of that there's actually no way to really "fix" such issue. Users will have to update the OS version anyways.)

AndroidDeveloperLB commented 2 years ago

@drchen Please explain the full steps you want me to test it. Would this be ok to take a video of this:

  1. Set a red-only wallpaper, turn off&on the display (to let the OS be in sync with this), go to the sample app on both places that it shows the colors (the one with the small rectangles and the one with the list of colored-rows)
  2. Set a green-only wallpaper, turn off&on the display (to let the OS be in sync with this), go to the sample app and do the same.

?

About the function, what's the point in having this function, then, if it's unreliable? I also requested that instead of a boolean, we would have a new function to return us what's really supported. Why shouldn't it be possible for Google to require OEMs to tell what's exactly supported?

drchen commented 2 years ago

Please explain the full steps you want me to test it.

Just open Catalog and go to "Demo" and "Dynamic Palette Demo" under "Color". Video or screenshots both work.

AndroidDeveloperLB commented 2 years ago

@drchen OK here. And I tested using the app "Wallpapers" by Google. Weird that it lacks some basic colors, though.

studio64_1jZuT7FsLI.zip

AndroidDeveloperLB commented 2 years ago

@drchen Please re-open this request which is about getting more than just a boolean: https://github.com/material-components/material-components-android/issues/2779

drchen commented 2 years ago

Are you using an emulator? (I don't know there's Samsung emulators...)

Regarding #2779, as I explained, there's really nothing better we can do on the library side than the current implementation.

AndroidDeveloperLB commented 2 years ago

@drchen It's this mirroring tool which I think Google should adopt and improve 10 times: https://github.com/Genymobile/scrcpy

Why do you think it can't be better? What's the point in a function that doesn't do what it's supposed to do? I just want to know if the colors affect the OS and/or third party apps. Why can't it be a query that I can perform?

drchen commented 2 years ago

Because we don't have the info either. : )

There's just no reliable way to know if OEMs on S actually support dynamic colors or not (or to which level.) It's also impossible for us to audit all versions from all OEMs to check their support level.

I'll let the relevant team know that some Samsung versions with OneUi 4.1 may not really support dynamic colors and discuss with them about what we can do.

Thanks for your reporting, though.

AndroidDeveloperLB commented 2 years ago

@drchen So get the info. Have it on the license tests if needed. Now is the time to do it, before Android 13 is out. Otherwise it will stay fragmented and OEMs will again break the default behavior, as they have done many times (see here ).

You say "partners", but it doesn't seem like they collaborate with Google enough. Things break all the time. How could Google license OEMs like Xiaomi which breaks things by default. I alone found at least 3 ways they break behavior, including explicit documentation on Android's website.

drchen commented 2 years ago

I understand what you said. I suggest you report the issues you saw to the framework team. The Material library is not part of the framework and there's very few things we can do as for things like this.

AndroidDeveloperLB commented 2 years ago

@drchen The thing is that the library's dynamic colors feature can't be used if OEMs don't support it. :(

AndroidDeveloperLB commented 2 years ago

@drchen I've tested more on this device, and it seems that it's just buggy. Sometimes it does offer the color pallete and sometimes it is stuck on what you've chosen. This is true especially for live wallpapers (Muzei and LWP+). Note that I turn off&on the display.

drchen commented 2 years ago

If it's buggy that's totally beyond our control.... ^^;

I'll close this issue since there's really nothing we can do at the moment. The Material library is providing helper functions to let clients be able to integrate dynamic colors in an easier way. Unfortunately we can't guarantee and have no control over OEM's behavior.

However I'll raise your report to the relevant person who work with OEMs and framework supports so they will be better aware of the situations you are concerned with. Thanks for your report!

AndroidDeveloperLB commented 2 years ago

@drchen Can you please let me know about updates of this? Meaning to keep me updated about it.

drchen commented 2 years ago

Will let you know if they have any updates. But I doubt there will be any real actions on this given that T is going to be released soon and all OEMs are supposed to fully support dynamic colors on T.

AndroidDeveloperLB commented 2 years ago

@drchen Including this device and all devices out there that have Android 12?

drchen commented 2 years ago

In theory, I think. But again I can't represent product team to guarantee that. It's just my personal understanding.

AndroidDeveloperLB commented 2 years ago

@drchen I always wished all devices would have updates to new Android versions for a long time.