ClassicPowerMenu: restoring the Android 11 power menu on Android 12

What the app restores and what it adds

ClassicPowerMenu is a power menu replacement for Android 11 and later, and the stated main aim is restoring power menu options, the device controls and the quick access wallet, on Android 12.

That framing matters because it explains the shape of the project. It is not a new power menu with a new design, it is a reimplementation of the older one, aimed at the specific things Android 12 moved out of the power menu and into the lock screen. Android 12 pushed the device controls and the wallet into the lock screen, which is a reasonable design change and one that removed a fast path that a lot of people relied on.

The feature list has three parts, and the first is the power options themselves. Up to ten power options can appear in the power menu, including non-stock options for screenshot, reboot to recovery and reboot to bootloader. The list is fully customisable, with rearranging and hiding of the buttons you do not use, so the ten slots are a ceiling rather than a fixed menu.

The second is the quick access wallet, which is accessible while locked or unlocked. It has an optional blurring of card numbers while the device is locked, and an optional showing of loyalty cards, described as restoring a previous feature from Android 10 which was removed. The loyalty card codes can be shown while locked and without needing to open Google Wallet.

The third is the device controls, also accessible while locked or unlocked, with an optional ability to interact with the controls while locked without requiring authentication. That last option is the one to think about, because a control panel that can toggle things on a locked device is a genuine change in the security posture of the phone, and the README presents it as an option rather than a default.

How the power button is intercepted

The implementation detail that decides whether this app can work on your device is the interception mechanism, and the README is specific about it.

Xposed is not required. Interception of the power button is done via an Accessibility Service, with only normal root required. An optional Xposed module is included, which can react quicker than the Accessibility Service.

So there are two paths with different trade-offs. The Accessibility Service route uses a mechanism the platform provides to any app, which means the app works without a framework, at the cost of being subject to the service's startup timing and to the system's policies around accessibility services. The Xposed route hooks the framework earlier, which the README says means it reacts quicker, at the cost of requiring a module framework to be installed and maintained alongside the root.

The reason a root requirement exists at all is that replacing the system power menu means replacing a system component, and on modern Android that is not something an ordinary app can do. The README states the requirement bluntly: Classic Power Menu requires root access to function, it is not possible without root.

The accessibility approach also has a consequence worth understanding. An accessibility service is a privileged capability, and Android shows it to the user as such. Whatever else you install, this app is asking for a permission that can read screen content and act on it, so the Play Protect and accessibility warnings you see are not a quirk of this app but the platform telling you what the mechanism costs.

The theming and the Content Creator Mode

The visual side of the app is described in one line: a Material You inspired theme, using Monet colours and background blur on the power menu.

That is a small detail with a large consequence, because the app is drawing a system surface. Monet is the dynamic colour system that derives a palette from the user's wallpaper, so a power menu that honours it looks like part of the system rather than a bolted-on overlay. The background blur is the other half, because a translucent panel over the wallpaper is what makes the surface read as a system dialog.

The Content Creator Mode is the feature that matters most for anyone making content about the app. The README explains it directly: if you are making a video or article about Classic Power Menu, you will want to hide your card numbers, and you enable the developer options in Classic Power Menu by triple tapping the About option, then enable Content Creator Mode. It will always blur your card numbers and will show a fake QR code for loyalty cards, keeping your data safe.

The fake QR code is the detail that shows the thought behind the feature. A blurred card number on screen is not enough if the QR code beside it still encodes the real one, so the mode replaces it. That is a small design decision with a large payoff for the community that makes tutorial videos about the app, because a video of a wallet screen is a privacy leak that is easy to cause and impossible to take back once published.

Installing it and what to read first

The distribution is a GitHub release, and the README asks you to read the FAQ before downloading or opening an issue.

The FAQ lives in the app assets at app/src/main/assets/faq.md, and the README bolds the instruction: please read the FAQ before downloading or creating an issue. That is a strong signal about the shape of the support burden, and it is the right instruction for this kind of app, because whether the app works on a given device depends on the Android version, the root method and the specific system components present.

The download itself is the latest release from the Releases page, and the recent releases are 1.9.3 from 2026-04-12, 1.9.2 from 2024-10-17 and 1.9.1 from 2024-10-15.

The version history has a shape worth noting. Two patch releases in October 2024, then nothing until 1.9.3 in April 2026, and the last push is on 2026-04-12, the same day as that release. So the project is alive and shipping, but on an infrequent basis, and a phone on an older Android build may be looking at a release that predates it.

The repository layout is consistent with an Android application with modules. There is an app/ directory for the application module, a Controls/ directory, a QuickAccessWallet/ directory, a systemstubs/ directory, and Gradle files at the root with build.gradle, settings.gradle, gradle.properties and the gradlew wrapper. The systemstubs directory is the interesting one, because a stub of a system API is how an app declares that it intends to interact with something the platform does not expose, and the presence of a separate module for it tells you the project is doing that deliberately rather than by reflection.

Translation and the community around it

The README carries a Crowdin badge linking to a Crowdin project for the app, and the repository has a crowdin.yml at the root, so translations are managed on Crowdin rather than as pull requests.

That is a deliberate workflow choice, and it is the right one for this kind of app. A translation file is a YAML or JSON document with one entry per string, and a contributor who wants to add a language should not have to understand the Kotlin source to do it. Crowdin gives a translation interface, a glossary and a review process, and the pull request that comes back is a data file.

The repository also has a .github directory, a CODE_OF_CONDUCT-style setup through the .idea directory and a gradle.properties file, and a .DS_Store at the root, which is the small untidiness of a project developed on a Mac.

The broader point is that the community around this app is the community of people who want their phone to behave the way it did on Android 11, and the tools in the repository support that: the FAQ for the questions, Crowdin for the languages, the optional Xposed module for the people who want the faster interception, and the Content Creator Mode for the people who publish about it.

Where ClassicPowerMenu is the wrong choice

The first limitation is the root requirement, and the README does not hedge about it. Without root it is not possible, so the population that can use this app is the rooted population, which on a modern Android phone means a device with an unlocked bootloader and a custom recovery, and the consequences that come with that.

The second is the security surface. An app that replaces the power menu, can show wallet cards while the device is locked, and can offer device controls that work without authentication while locked, holds a set of capabilities that most apps do not. The optional blurring of card numbers and the optional unauthenticated control interaction are both user choices, which is respectful, but the underlying app is capable of more than the average user might expect from a power menu replacement.

The third is the version dependency. The app is built for Android 12 and later to restore an Android 11 behaviour, and it depends on system components that Android changes between versions. A project like this tracks the platform, and the two-year gap between the 1.9.2 release in October 2024 and the 1.9.3 release in April 2026 is a reminder that the app may not have kept up with every Android build in between.

The fourth is the Accessibility Service dependency, which is a policy surface as much as a technical one. Accessibility services have been progressively restricted on Android, and an app whose core mechanism is an accessibility service can break with a policy change that has nothing to do with the app.

The fifth is that it is a single-purpose app with a narrow audience. If what you want is the device controls back, this does it. If what you want is a different launcher, a different lock screen or a different quick settings panel, this is the wrong shape of solution.

How it compares with the stock Android power menu and with other Android customisation apps

The comparison with the stock power menu is the whole point of the project, and the difference in approach is that the stock menu is a system dialog with a fixed set of entries that the vendor chooses, while this is a replacement you install and configure. The stock menu on Android 12 gives you the power options and nothing else, with the device controls moved to the lock screen and the wallet reached separately. ClassicPowerMenu puts them back in the place your muscle memory expects, and adds the three non-stock options on top.

The comparison with the general Android customisation scene, the Xposed modules that change system behaviour, is instructive. Those modules work by hooking the framework, which gives them deep reach and gives the user a maintenance burden, since the module has to be updated for each Android release. ClassicPowerMenu takes the other route, using root for the system replacement and an accessibility service for the interception, so it needs no framework, and the Xposed module is optional and additive rather than required.

The third comparison is with a dedicated quick settings tile, which is what many people use to reach the device controls after Android 12 moved them. The difference in approach is speed. A tile is one pull and one tap, whereas the power menu is one press, and on a locked device the power button is a single gesture away. For a user who reaches for the device controls often, that difference is real.

The fourth is the wallet. Google Wallet exists and is the supported path to the cards. This app does not replace the wallet, it puts a shortcut to the cards back into the power menu and restores the loyalty card handling, which is a different thing from replacing the payment application.

Licence, maintenance and what to check before you install

The licence field on the repository records Apache-2.0, with a LICENSE file at the root. Apache 2.0 is a permissive licence with a patent grant, and for a user who only installs the app it is largely irrelevant, but it does mean the source is readable and a fork is legally straightforward.

The project is not archived and the last push was on 2026-04-12, the same day as the 1.9.3 release, so the code is current with its latest tag. The primary language is Kotlin, and the recent releases are 1.9.3 from 2026-04-12, 1.9.2 from 2024-10-17 and 1.9.1 from 2024-10-15.

Three things to check before you install it.

Read the FAQ in the app assets, which the README asks you to do before downloading or opening an issue. For a root-dependent system replacement, the most likely reason it does not work on your device is something in the FAQ, and reading it is faster than filing an issue.

Consider whether your Android build is one the app supports, given the gap between the 1.9.2 release in 2024 and the 1.9.3 release in 2026, and given that the app depends on system components that change between Android versions.

And decide about the two optional behaviours that affect your data. Card number blurring and the fake QR code exist for people recording their screen, and the interaction of controls while locked without authentication is a genuine reduction in the lock screen's protection. Both are options, and the README is clear that they are options, but they are worth deciding on rather than inheriting.

Editorial conclusion

ClassicPowerMenu suits an Android user on Android 12 or later who wants the device controls and the quick access wallet back in the power menu, and who is already rooted and comfortable with an app that intercepts the power button. It is the wrong tool if you are not rooted, since the README says it is not possible without root, and the wrong choice for a device you cannot modify, because it replaces a system component rather than configuring one. Before you install it, read the FAQ in the app assets, which the README asks you to do before downloading or opening an issue, and check that the accessibility service interception works on your Android build.

Frequently asked questions

Official sources

1. Issues
2. KieronQuinn/ClassicPowerMenu on GitHub
3. License: Apache-2.0
4. README
5. Releases