LiveBridge turns ordinary Android notifications into Live Updates, with an OEM compatibility bill attached

What LiveBridge actually intercepts

LiveBridge is an Android app that reads notifications as they arrive and republishes them as Live Updates, the Live Activity-style interface Android 16 introduced. The project describes itself as a Flutter Android app with native Kotlin logic, which is a fair summary of a two layer design: the user interface and most of the application logic live in Dart, while the parts that talk to the system notification and Live Update APIs are written in Kotlin.

The input side is the standard Android notification stream. The output side is the new Live Update surface, where a compact bar or an island style element sits at the top of the screen and carries live progress.

The core feature list in the README is short but specific: converting progress notifications into Live Updates, smart status detection that covers taxi, delivery and food order flows as well as weather, OTP code extraction from notifications, real-time island navigation, app filtering modes, and per-app presentation overrides. The last two are the ones that matter for anyone who lives in their notification shade, because a tool that promotes every notification to the top of the screen is unusable without them.

Smart status detection and the parsing dictionaries

The interesting engineering problem here is not the rendering, it is deciding what a notification actually means. A courier app and a weather app both post progress notifications, and a generic converter would show a raw progress bar for each. LiveBridge instead tries to identify the flow, with the README naming taxi, delivery and food order flows alongside weather as cases it recognises.

That recognition is driven by customizable parsing dictionaries, and the dictionaries auto-update. This is the mechanism that makes the tool adapt to apps it has never seen: instead of hardcoding a rule per courier service, the rules live in a dictionary that the app can refresh.

The trade-off is that the quality of the output depends on the quality of the dictionaries, and the dictionaries are only as current as their last update. An app that changes its notification format can start rendering wrong until a dictionary catches up. The README does not document a way to write your own dictionary entry, so for an unusual app your options are limited to the built-in rules and the per-app presentation overrides, which change how a notification is shown rather than how it is parsed.

OTP extraction reads a code out of a notification

The feature that will generate the most discussion inside a security team is OTP code extraction. The README lists it among the core features, and the mechanism is straightforward: the app listens for incoming notifications and recognises the one-time passcode pattern in the text, presumably so the code can be surfaced in the Live Update rather than requiring a trip to the notification shade.

It is convenient in exactly the situation where convenience is most tempting, because one-time passcodes are the credential an attacker wants. The trade-off is structural rather than incidental. To extract the code, LiveBridge needs Notification Listener access, which in Android means the app can read every notification that arrives on the device, not just the ones it converts. A tool that reads your SMS, your banking alerts and your work chat is a tool with a very broad view of your life, regardless of how carefully it uses the code it extracts.

The permissions section in the README lists what the app usually needs: Notification Listener access, notification permission for LiveBridge itself, Live Updates permission where the system or vendor requires it, and background activity or battery exclusion on some OEM ROMs. That last one means asking the user to exempt the app from battery optimisation, so it keeps running in the background.

Building from source needs Flutter 3.35.7 and an Android 16 target

The project ships a download page for people who only want to install the app, and it says so directly: users do not need to build the project unless they want to contribute or test version changes. For developers, the requirements are listed as Flutter SDK 3.35.7, an Android SDK configured to compile and target Android 16, and an Android 16 or newer device.

Getting dependencies and running a debug build takes the standard Flutter pair of commands.

flutter pub get
flutter run

The release path is the same Flutter build command with a different mode, producing an APK you can distribute.

flutter build apk --release

The repository layout shows the usual Flutter structure, with `lib/` holding the Dart side, `android/` holding the native project and the Kotlin integration, plus `assets/`, `test/`, `tool/` and `docs/`. There is a `pubspec.lock` checked in and an `analysis_options.yaml` for linting, which suggests the project is developed with a reproducible dependency set rather than a loose one.

The Android 16 target is not incidental. The whole point of the app is a feature that only exists on that platform version, so a build targeting anything older would compile but have nothing to show.

Installing the APK asks you to disable Play Protect

The download instructions are worth reading as a security decision rather than as a formality. Before installing the APK, the README asks for two things: use Android 16 or newer, and disable Play Protect during installation.

The reason for the second request is ordinary for an app distributed outside the Play Store. A sideloaded APK is flagged as coming from an unknown source, so the protection warns or blocks it. The instruction is telling the user to turn that warning off.

The fact that the project is on GitHub with a GPL-3.0 licence and a NOTICE file means the source is available and the attribution requirements are stated, which reduces the risk relative to a closed binary with no source. It does not eliminate it. Reviewing the Kotlin code that handles notifications is exactly the kind of review that is hard to do on a phone, and a project this close to the notification stream is where a mistake would matter most.

A reasonable middle path exists for anyone who is cautious: build the APK yourself from the source, or read the code before installing. Both are cheap compared with the cost of an unwanted app reading every notification on a device holding your banking and messaging apps.

The vendor compatibility list is the honest part of the README

The known issues section is the most useful thing in the documentation, because it names failures instead of implying universality. On AOSP, the app icon and label behaviour may differ from OEM firmware. Always on display and `isOngoing` behaviour vary across vendors. Chinese OriginOS is listed as not working at all, CMF devices are listed as not working, and Nothing devices without Progress Glyph indicators are described as working badly.

The reason for the variance is structural. Live Updates is a new platform feature, and each vendor implements it differently, ships their own island or progress glyph component, and applies their own background restrictions. The app is rendering into a surface the vendor controls, so a behaviour difference is a matter of course rather than a bug in most cases.

The project also documents Xiaomi's native Hyper Island as an exclusive feature, crediting the HyperIsland-Toolkit by D4vidDf, and the credits list names further components for live media and network statistics. That pattern of building on other people's work, plus the statement that testing on multiple OEMs is highly recommended, tells you the project knows the matrix is the hard part of the problem.

The README says LiveBridge is under active development, and the last push was on 2026-10-07 with v2.2.1 and v2.2.0 published the same day. That is a project moving quickly, which is good for device support and also means behaviour can shift between builds.

What GPL-3.0-or-later asks of anyone who ships a build

The licence is GPL-3.0-or-later, and the README spells out the obligations in plain language. Redistributed builds, forks and modified versions must preserve the attribution notice in the NOTICE file, must clearly identify themselves as based on the original LiveBridge project, and must provide the corresponding source code when distributing APK builds or other binaries.

For a user installing the app, none of that changes anything. For a company that wants to bundle LiveBridge into an internal build, or to fork it and add support for another vendor, the obligations are concrete and workable: keep the NOTICE, keep the attribution visible, publish your source alongside the binary. That is a manageable condition, and it is the kind that makes forking a reasonable option rather than a legal question.

The practical note is that the app also holds a privileged position on the device, since Notification Listener access is a grant the user makes and can revoke at any time. A fork that changes what the app does with that access should say so plainly, both because the licence asks for attribution and because the grant is easy to misread as harmless.

Editorial conclusion

Adopt LiveBridge if you are on Android 16 or newer, you use apps that send progress notifications such as taxi, delivery or food order flows, and you can grant Notification Listener access. Do not adopt it on Chinese OriginOS or CMF devices, where the project states it does not work, and treat the Play Protect requirement as a signal to read the source before installing an unofficial APK. Verify first that your daily apps post cancellable progress notifications, that your OEM build is not on the known issue list, and that granting Notification Listener access to a third party app is acceptable under your device policy.

Frequently asked questions

Official sources

1. appsfolder/livebridge on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases