android12-extensions VS MonetCompat

Not yet, although there's an open-source implementation that comes quite close: https://github.com/kdrag0n/android12-extensions/commits/monet-next

If a single developer can make a better implementation than Google did, I'm sure the development team could and should do better.

Idk but the closest thing you'll get are kdrag0ns android-12-Extensions to customize Android 12 for now

Code-wise Monet is not a part of AOSP. kdrag0n's implementation is nice and all, but I doubt LOS with its tendency to stay close to AOSP would integrate it. Looks like it can be applied with Magisk though.

There's nothing stopping them creating their own, or including a third party library to do it (I can see kdrag0n's recreation being included by some for example), but they can't use Google's. This might be why OnePlus aren't including it - they're not choosing to remove it, they're simply not recreating it.

i found a way fix. but u need root your device first, need magisk, lsposed, and android 12 extensions(https://github.com/kdrag0n/android12-extensions).

There's also kdrag0n's reproduction of Monet, and my implementation of it in a library, compatible with Android 5.0+ (shameless plug)

There’s been a xposed module that enabled it ever since dp1, so just wait for the module to get its update for b1. Link to it’s github page: https://github.com/kdrag0n/android12-extensions

There isn't an official way to do this, you'd have to use a third party re-implementation of Monet (the colour library). My own MonetCompat contains code for generating palettes, based on colorkt, but doesn't expose the ability to give it a colour and it give back a palette - it's something I want to add in the future though. Feel free to fork or copy it and take just the code you need to generate one though.

Repainter was bypassing the generation code, as you mention, using kdrag0n's recreation of Monet (the same one used in my own MonetCompat - shameless plug for devs - on an app level), and allowed tweaking of the colour generation. Of course you can't do that with a live wallpaper and passing custom colours to the generation, as good as your app is.

It's needed because the app reads your wallpaper in order to do the dynamic color theme thing so that the default theme matches your wallpaper color. You can read more about why this is needed in the MonetCompat library and the monet pub package which my app uses under the hood

The MonetCompat library by /u/Quinny898 , which uses /u/kdrag0n's custom monet implementation, also provides backwards compatibility all the way to Android 5.0 through the Palette API, but the Niagara developers said they opted for the above approach for simplicity.

WallpaperManager has a method to get the wallpaper's colours, it has done since API 27, so it's used for that. I've only ever seen it used in some launchers for UI elements until now. It's actually been possible to do Monet on the app-level for years, even before getWallpaperColors existed - because you've always been able to get the wallpaper as a bitmap and throw it into an extraction engine like Palette. This, combined with kdrag0n's Monet reconstruction, is how my own MonetCompat library works.

Oh and I already wrote a library that does that.

Someone else has already mentioned my library MonetCompat, but if you want to use the raw colours, they're accessible on Android 12 only, check android.R.color: https://developer.android.com/reference/android/R.color (the system_accent and system_neutral sets are the ones you want)

Google haven't released related libraries yet but it didn't stop some developers implementing their own that supports older Android versions.

There's also kdrag0n's reproduction of Monet, and my implementation of it in a library, compatible with Android 5.0+ (shameless plug)