FWIW Android (and surely iOS, although I don't know anything about that in particular) have had systems like this for a long time. Aside from all the task scheduler smarts in the kernel itself, there are all kinds of things that can be marked as low priority so they run on the LITTLE (what Apple calls "efficiency") cores, while e.g. a UI rendering thread might go straight to a "big" ("performance") core even if its h…
Google Play likes to do shit in the background. A lot of it. All the time. Even if you have deliberate RCE auto-update disabled in settings, it will still update itself and Google services, silently, in the background, without any way to disable that. And while it's installing anything, let alone something as clumsy as Google services, your device grinds to a halt. It sometimes literally takes 10 seconds to respond to input, it's this bad. It's especially bad when you turn on a device that you haven't used in a long time. So it definitely wasn't scheduling background tasks on low-power cores, despite knowing which tasks are background and which are not (that's what ActivityManager is for). My understanding from looking at logcat was that this was caused by way too many apps having broadcast receivers that get triggered when something gets installed.
Now, in Android 11 (on Pixel 4a), this was partly alleviated by limiting how apps see other apps, so those broadcasts don't trigger much anything, and apps install freakishly fast. That, and maybe they've finally started separating tasks between cores like this. Or maybe they started doing that long ago but only in then-current kernel versions, and my previous phone was stuck with the one it shipped with despite system updates.