HyperIsland: a Dynamic Island enhancer for HyperOS built as an LSPosed module

An island for Xiaomi ROMs, delivered as a hooked module

HyperIsland is a notification enhancement module for HyperOS, the ROM on Xiaomi phones, written in Kotlin and built with Jetpack Compose. The project describes itself as a Super Island notification enhancement for HyperOS 3 and 4, and the badges on the project page name the three fixed points of the design: the Android platform, the LSPosed framework, and the HyperOS 3/4 ROM.

That combination determines the audience precisely. The module works by hooking into the notification pipeline of a specific ROM, so it needs a device that can run a hooking framework, which in practice means a rooted or otherwise modified handset with LSPosed installed and the module enabled inside it. On a stock device, on another manufacturer's ROM, or on a phone without root, none of this applies.

The idea it implements comes from the Dynamic Island on recent Apple hardware, and the project names a comparable element of its own as the persistent island, a small always-present element that can expand into a notification. The licence is MIT, and the repository welcomes issues and pull requests.

It hooks standard notifications and re-renders them as island cards

The core mechanism is interception rather than replacement. The module catches standard Android notifications posted by any app, processes them, and displays them in the Super Island plus focus notification style. Buttons are taken from the original notification, so an action the source app provided, such as replying or archiving, survives the transformation instead of being dropped.

Two specific pipelines get dedicated treatment. The HyperOS download manager is intercepted so the island shows the file name and the download progress, with pause, resume and cancel operations available from the island itself. Toasts are intercepted as well and converted into island displays, which is the feature aimed at the short-lived popup messages that otherwise vanish before they can be read.

Because the module works on the notification stream rather than on a single application, it applies to whatever an app posts. The trade-off is equally clear: the module is a hook, so it sits between apps and the system service, and anything that changes how notifications are posted upstream can affect what the island receives.

Four glass finishes and a persistent island that can move out of the way

The presentation layer is where most of the configuration lives. Four finish styles are supported, described as gaussian blur, highlight glass, soft light glass and liquid glass, and each one can be adjusted through custom parameters rather than being a fixed preset.

A persistent island mode displays a permanent element similar to the Apple Dynamic Island, with support for automatic hiding and avoidance. That means the island can retreat when it would cover something, which is the difference between a persistent element that stays out of the way and one that sits on top of your content. Whether the avoidance behaviour is configurable per application is not stated in the project description, so the safe assumption is that it behaves as a global setting.

For a user who wants the notifications gone entirely, the toast interception and the focus notification style serve the same underlying goal: information arrives where it can be glanced at, then gets out of the way.

AI summarisation depends on a model endpoint you configure

One feature stands apart from the notification work. The module can summarise notifications with a large model that speaks the OpenAI protocol, condensing the notification text and pulling out the key points. In practice this means you supply your own endpoint and model configuration, and the content being summarised is the notification text itself.

That last point deserves attention rather than enthusiasm. Notification text on a phone can contain message previews, sender names, app names and sometimes content the user would not want sent to a third party. The project lists the feature as optional and separate from the notification rendering, so the sensible approach is to enable it only for the apps whose notifications you are willing to have summarised, and to point it at an endpoint you control. Nothing in the project description states how the request is made, what is transmitted beyond the notification text, or whether there is a per-app switch, so treat the current behaviour as something to check on your own device rather than something you can read off a spec.

Building from source needs JDK 21 and the Gradle wrapper

The project documents a single build command for developers. With JDK 21 and the Android SDK installed, the release APK is assembled with the Gradle wrapper bundled in the repository:

./android/gradlew -p android :app:assembleRelease

The `-p android` flag points Gradle at the `android` directory, which holds the Android application module, and the `:app:assembleRelease` task builds the release variant. The repository layout matches that structure, with the Android project in `android/` and the rest of the tree holding documentation and templates.

The documentation itself is a separate project. The `package.json` at the root is a VitePress site with three scripts, one for a local preview, one for a production build and one for previewing the built output:

  "scripts": {
    "docs:dev": "vitepress dev docs",
    "docs:build": "vitepress build docs",
    "docs:preview": "vitepress preview docs"
  },

So the docs site under `docs/` is what a user reads, and the published version lives at hyperisland.1812z.top. The root README points there for the full usage instructions, template introductions and configuration guide, which means the repository itself is a summary rather than the manual. The README also carries an English translation alongside the original Chinese, Japanese and Turkish versions, which matters for anyone outside the Chinese-speaking audience the project was written for.

A hooked module instead of the stock notification shade

There is a genuine alternative and it is the one most people already have: leave notifications alone and read them in the system shade. The difference in approach is architectural. Without a module, notifications are rendered by the system, they are never intercepted, and nothing about them is summarised or re-shaped.

HyperIsland wins where the source information is scattered. The download manager case is the clearest, since the island shows the file name and progress with pause, resume and cancel in one place, rather than opening the system's download screen to find that notification again. The toast case is the second, since a toast that would have disappeared is converted into something that stays visible. The focus notification style also changes how a notification occupies the screen while it is current.

What you give up for that is the hook itself. The module has to run inside the notification pipeline on a specific ROM, so it only works where LSPosed and HyperOS 3 or 4 are present, and it is subject to whatever the ROM changes in that pipeline. A stock system has none of those constraints and none of those features.

Release pace, documentation and what the licence allows

The project is being worked on quickly. The last push was on 2026-10-17, and three tagged versions went out in the four days before it: v3.1.10 on 2026-10-13, v3.2.0 on 2026-10-15 and v3.2.1 on 2026-10-17. For anyone tracking this project, that pace means a release can arrive between two readings of the documentation, so the version you install should be matched against the documentation for that version rather than the latest text on the site.

The licence is MIT, which is permissive: you can read, modify and redistribute the code, including in a larger work, without a copyleft obligation to publish your own sources. The repository keeps its licence text in a `LICENSE` file and states that the project is open source under MIT, inviting issues and pull requests. That is a description of what the licence text grants, not advice on how to use it.

What the licence does not do is reduce the hardware and firmware requirements. Those are fixed by the design: a HyperOS 3 or 4 device, a hooking framework, and a willingness to install a module that reads your notifications. Any evaluation has to start there.

Editorial conclusion

HyperIsland fits Xiaomi HyperOS 3 or 4 users who run LSPosed and want notifications, toasts and download progress presented as a persistent island instead of a shade full of cards. It does not fit stock Android, other ROMs, or users without a rooted device and a hooking framework, and the AI summary feature needs an endpoint you supply. Before installing, confirm that your ROM version is covered by the HyperOS 3 or 4 badges in the project, and read the documentation site at hyperisland.1812z.top, since the repository README carries only the feature list and the build command.

Frequently asked questions

Official sources

1. 1812z/HyperIsland on GitHub
2. License: MIT
3. Project website
4. README
5. Releases