HMSPush: giving HMS Core a system notification channel on non Huawei devices

The gap HMSPush targets: push that only works by waking the app

HMS Core is Huawei's bundle of services, and push notification is one of the things it carries. The services are installed on non Huawei phones too, which sounds like a complete solution and is not. The README explains the limitation in plain terms: on a device without the matching system services, HMS can only wake the target application and let that application raise its own notification.

That workaround has two visible costs. The user sees the app's own notification rather than a system drawn one, which looks different on the lock screen and in some launchers. More importantly, the app has to be running for the notification to appear, and the process has to be brought back from the dead just to draw a line of text.

There is a second problem on top of the first: most applications do not turn on HMS push on non Huawei devices in the first place. The application checks the environment, decides it is not a Huawei device, and never registers the HMS push channel. No notification arrives because no channel was ever opened.

HMSPush is written for exactly this situation. The module description says it gives HMS Core the ability to send system notifications, and it supports disguising the app runtime environment as a Huawei device so that a background system level push channel can be established. The intended user is someone running HMS dependent apps on a non Huawei phone and tired of missing notifications.

The mechanism: an LSPosed hook inside HMS Core

The technical base is LSPosed, and the README credits it as the Xposed framework the project builds on. The module hooks into the HMS Core application at the framework level, which is what grants it the ability to post notifications that the system draws rather than the target app.

The device disguise is the second half. By making the running environment look like a Huawei device, the module addresses the registration problem directly: an app that checks for Huawei characteristics sees them, opens the HMS push channel, and stays registered. That is the mechanism behind the README note that applications may need one or two restarts after the module is configured, since the app has to run again in order to see the disguised environment and register.

The repository layout supports this reading. Alongside the app directory there is an xposed directory and a common directory, and the project is written in Kotlin with Gradle build files at the top level (build.gradle.kts, settings.gradle.kts and a gradlew wrapper). The separation between the module code and shared code is what you would expect from a project where one part registers as an Xposed module and the other part holds shared code.

The acknowledgements section names LSPosed, XposedBridge from rovo89, LSPatch described as a root free Xposed framework, and the AndroidNotifyIconAdapt icon library. The presence of LSPatch matters for anyone without root: the module can be patched into an app rather than requiring a rooted system, which is why the acknowledgements mention it at all.

Installing the module and the first notification test

The README gives the setup as a sequence, and each step matters.

First, install HMS Core itself. The README points to app stores for it, including the Tencent app store, Coolapk and APKMirror, all serving the package com.huawei.hwid. Without HMS Core present there is nothing for the module to extend.

Second, download the latest HMS Push release from the GitHub releases page, install it, enable the HMSPush module in LSPosed, tick both the 系统框架 scope and the HMS Core scope, and reboot the device. The framework scope is what lets the module act on system level notifications, and the HMS Core scope is what lets it hook the target of the hook. A reboot is required for LSPosed to load the module.

Third, inside the HMSPush module in LSPosed, select the apps you want to support push for, then restart the target application once or twice so that it registers the push channel. The README marks this step as optional if you already spoof the device by another method, which tells you the disguise is the part doing the registration work, and that the per app selection in the module is only one way of applying it.

Fourth, kill the application and test the push. The README suggests using QQ for the test. The test is meaningful only after the app is dead, because a notification produced by a live app proves nothing about the background channel. This is the moment where the whole setup either works or does not.

The support matrix is uneven, and WeChat is excluded on purpose

Not every application that could use HMS push supports it, and the README is unusually candid about the coverage. It says most applications are supported and names QQ, Douyin, Zhihu and Coolapk among the tested ones. Xianyu, Taobao and Ele.me are listed as supported from v0.0.13 onwards.

One exclusion is stated as a fact rather than a limitation of the module: WeChat does not support it, because WeChat has not integrated HMS services. No amount of configuration changes that, since the push channel the module restores simply does not exist in that application. If your reason for wanting this is WeChat notifications, this project is the wrong tool and no configuration will fix it.

The version history explains the uneven coverage in practice. The release list runs v0.0.27 on 2023-12-15, then v0.0.28 on 2026-04-01 and v0.0.29 on 2026-05-03. The long gap between those tags is consistent with a project whose support list grows as individual applications are tested and reported, one application at a time, rather than through a general compatibility mechanism.

A practical consequence for readers: the list of tested applications is not a promise about every app on your phone. The feedback route is the GitHub issues page, the Telegram group linked from the homepage, or the maintainer's email address.

Failure modes: background HMS Core and notifications that will not open the app

Two failure modes are documented, and both are operational rather than conceptual.

The first is HMS Core itself stopping. The README asks you to keep HMS Core running in the background and not to disable its autostart permission or its permission to reach the target push application. A module that exists to deliver background push is only as alive as the service it extends, so an aggressive battery optimiser or a vendor background restriction will quietly break it.

The second is a notification that displays but does nothing when tapped. The README's remedy is to convert HMS Core into a system app, and it does not leave that as a puzzle: if you do not know how to do that, you can flash the Magisk module linked from the releases page, HMSCore-v0.3.zip from the v0.0.5 release. A system app survives restrictions that an ordinary app does not.

For debugging, the README asks for the LSP log when reporting a problem, since the module runs inside a hooked process and the interesting failures are usually visible there rather than in the notification itself.

The documented risk: device disguise and account bans

The README carries a warning, and it is the most important line in the document for anyone deciding to install it. Spoofing the device causes abnormal behaviour in the application environment, and that can end with the account being banned. Users are told to bear the risk themselves.

This is the central trade-off of the project, and it deserves to be stated plainly rather than softened. The module's value comes from making a non Huawei device look like a Huawei device to the application, so the application registers the push channel. The same deception is what an application detects when it decides an account looks wrong. No amount of configuration in LSPosed removes that link, because the disguise is the mechanism, not an incidental setting.

The scope of that risk is limited by which applications you apply the module to. The per app selection in the HMSPush module controls the disguise, so limiting it to the applications where you actually want push is the practical way to bound exposure. The README also says this step can be skipped if you already spoof the device by another method, which is a warning in itself, since it acknowledges that other apps on the device may then be running in a disguised environment too.

Secondary risks are ordinary Android module risks: an LSPosed module changes the behaviour of the system it hooks, and a module that fails to load after a system update looks like the target application misbehaving.

Licence, build layout and what the project does not document

HMSPush is released under the GNU General Public License v3, with the licence file at the root of the repository. Modification and redistribution are permitted under those terms, and anyone who forks the module inherits the same obligations. This is a licensing question rather than advice, and the specifics are in the LICENSE file.

The project is written in Kotlin and built with Gradle, using the Kotlin DSL: build.gradle.kts and settings.gradle.kts sit at the top level next to gradlew and gradlew.bat, and the code is split into app, xposed and common. The repository also contains a .github directory and a .gitignore, and the presence of the Gradle wrapper means a contributor can clone and build without a system Gradle installation.

The homepage is a Telegram group rather than a documentation site, and the README does not describe a user manual, a settings screen reference, or a list of the scope keys beyond the 系统框架 and HMS Core entries named in the install steps. It also does not describe how the module decides which system services to impersonate, or how the disguise behaves across different Android versions. For a project whose mechanism is deliberately obscure, that thinness is expected, but it does mean you are trusting the implementation rather than reading it. Bug reports go to the GitHub issues page, the Telegram group, or the maintainer email address.

Editorial conclusion

HMSPush is worth installing if you run an app that depends on HMS push, such as QQ, on a phone without Huawei system services, and you are comfortable with the module's own warning that the device disguise can lead to account bans. Skip it for WeChat, which does not use HMS at all, and skip it if your device cannot run LSPosed, since the module has no standalone mode. Before installing, check that HMS Core stays in the background and that you can enable the 系统框架 and HMS Core scopes in LSPosed, and decide in advance whether you want the device disguise applied to each target app, since the README offers that step as optional when you already spoof the device yourself.

Frequently asked questions

Official sources

1. fei-ke/HMSPush on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases