Two bugs that weren't bugs
This is a follow-up to The Device That Wasn't Mine, where I walked a phone out from under a Device Owner MDM lock and did a full debloat pass afterward. That post ended on a clean note: app drawer stripped down to one screen, everything working, story over.
It was not the end of the story.
Chapter 4: The power menu ghost
A few days later, holding the power button stopped doing anything. No shutdown menu, no restart option, nothing - just silence, like the gesture had never been registered at all. Rude.
The instinct was to blame the debloat pass, so that's where the chase started - putting things back, starting with the most thematically suspicious removals:
com.android.thememanager- a reasonable first suspect, since HyperOS routes a surprising amount of system theming through it. Did nothing.com.google.android.apps.safetyhub- on the theory that Global Actions might be trying and failing to build an emergency-info entry. Did nothing either.com.google.android.googlequicksearchbox- in case the long-press gesture was somehow bound to the Assistant role. Also did nothing.
Three reinstalls, three dead ends, and still no power menu.
The actual diagnosis came from logcat, captured during a deliberate long-press:
adb logcat -c
# (long-press power button on device)
adb logcat -d > power_menu_log.txt
Buried in the output:
WindowManager: powerLongPress: eventTime=3169276 mLongPressOnPowerBehavior=0
The key event was being received and processed correctly - mLongPressOnPowerBehavior=0 just meant the configured behavior was "do nothing." Not a crash, not a missing component. A setting.
Confirming it directly:
adb shell settings get secure power_button_long_press
Returned null. The broader dump showed it explicitly:
_id:668 name:power_button_long_press pkg:android value:0 default:0 defaultSystemSet:true
So - just write the correct value back:
adb shell settings put secure power_button_long_press 1
SecurityException: Permission denial, must have one of: [android.permission.WRITE_SECURE_SETTINGS]
Another wall. Normally ADB shell carries WRITE_SECURE_SETTINGS by default on stock Android; HyperOS revokes it, and the toggle that would restore it - Developer Options → USB debugging (Security settings) - turned out to require signing into a Mi account to enable.
The same account-gating pattern from the sideloading issue in the first post, showing up again in a completely unrelated corner of the OS.
At that point, with ADB fully fenced off from the one value that seemed to matter, the only path left was to stop assuming the fix had to be technical at all and just search the Settings app properly.
It was sitting in Settings → Accessibility → Gesture shortcuts, the entire time - a plain, user-facing toggle labeled "Power off," completely disconnected from the power_button_long_press secure setting I'd spent the better part of an evening fighting over ADB. Flip it on, and the menu came back instantly.
Three packages reinstalled for nothing. A permissions wall that turned out to be irrelevant. The actual fix was always one menu away, in the most ordinary place imaginable, and no amount of dpm, logcat, or settings put was ever going to find it, because it was never a setting ADB could see.
[!NOTE] Lesson filed away for next time: before reaching for a shell, check whether the OS moved the toggle into its own UI first. HyperOS, it turns out, had.
Chapter 5: The color that wouldn't change
With the power menu fixed, something smaller but stranger surfaced: the whole phone was stuck on one accent color. Every app - Messages, Phone, Contacts, a music player, a video app with nothing in common with the others - rendered the same flat green-teal, regardless of what wallpaper was set.
This should have been Android's dynamic color system (Material You) doing its normal job: extract a palette from the current wallpaper, generate accent and neutral tones from it, apply them system-wide. It's been standard since Android 12, and HyperOS supports it. Except it wasn't updating, no matter what wallpaper went on - not the original, not a different image, not a wallpaper that was just a single flat color.
The most direct question to ask the system was whether it even thought extraction had happened:
adb shell dumpsys wallpaper | findstr -i "color"
isColorExtracted=false
isColorExtracted=false
isColorExtracted=false
Not stale data, not a caching quirk - extraction genuinely wasn't completing, for any wallpaper slot. An adb shell cmd overlay list check ruled out the obvious suspect too: the Monet overlays themselves (com.android.systemui:neutral, :accent, :dynamic) were all enabled. The plumbing was intact. Something upstream of it wasn't feeding it anything.
The answer was sitting in a logcat capture taken during a wallpaper change - the same tool that had cracked the power menu issue, pointed at a completely different problem:
10-04 20:33:49.751 2436 2698 W WallpaperManagerService: Cannot extract colors because wallpaper could not be read.
Right above it, a much busier, much more verbose process - MiuiWallpaperManagerService - was logging a completely successful wallpaper change: file written, colors computed, multiple components across the OS notified.
Two different services. Two different processes. Only one of them failing.
HyperOS runs its own parallel wallpaper system on top of stock Android's. Xiaomi's MiuiWallpaperManagerService handles the custom picker, the Super Wallpaper animated effects, AOD styling - and writes everything to a MIUI-specific path, /data/system/theme_magic/users/0/wallpaper/image/. Stock Android's WallpaperManagerService - the one Material You actually reads from - expects wallpaper data in the standard AOSP location, and on this build, nothing was reliably bridging the two.
MiuiWallpaperManagerService |
WallpaperManagerService |
|
|---|---|---|
| Handles | picker, Super Wallpaper, AOD styling | serving wallpaper to the OS |
| Writes to | /data/system/theme_magic/... |
the standard AOSP location |
| Sees | a successful change, colors computed | a file it can't read |
Set a wallpaper through Xiaomi's own Wallpaper or Themes app, and MIUI's service handles it beautifully; the stock service never sees a readable file, and dynamic color has nothing to work from.
The confirmation came by accident, setting a wallpaper through Google's Wallpapers app instead of Xiaomi's - and the accent color changed immediately, system-wide, on the first try. I stared at it for a second. Accidental science at its finest.
Two wallpaper systems, running side by side, only one of them wired into the half of Android that actually mattered for this feature. Not a bug in the sense of broken code - both services were doing exactly what they were written to do. Just two services that had quietly stopped agreeing with each other, somewhere upstream of anything a factory reset or a debloat pass would ever touch.
Neither of these ended up being anything I'd broken. The MDM lock in the first post was a deliberate system working as designed. The power menu was a setting that had simply moved to a different menu than where ADB could see it. The color bug was two OS subsystems never fully agreeing with each other in the first place.
Nothing here was mysterious in hindsight. It was mysterious right up until the moment logcat said otherwise - which is, really, the whole argument for reaching for it before reaching for anything else.