# Flow prints its APK signing fingerprint in full, exports the recommendation profile as a file, and ships nightly beside stable

> An Android client for a video and music service, built with a declarative UI toolkit, whose distinguishing feature is a recommendation engine that runs on the phone and whose state you can read, export, and delete. The three details worth knowing before installing are the release fingerprint on the page, the nightly channel that lives next to the stable app, and the fact that it wants no account from the service it plays.

**A-EDev/Flow** — A modern, feature-rich YouTube and YouTube  Music client with local recommendation for Android built with Jetpack Compose

- Repository: https://github.com/A-EDev/Flow
- Website: https://flow.aedev.me
- Stars: 2,403 · Forks: 115
- Language: Kotlin
- License: GPL-3.0
- Published: 2026-09-30 · Updated: 2026-09-30 · Language: en
- Canonical page: https://hysenlabs.com/projects/a-edev-flow

## The signing fingerprint is printed on the page, in full

Almost every Android project that distributes builds outside the store tells you to check the signature and then sends you to a documentation page to find the value. This one puts the value on the front page, in the same block of text as the instructions.

```text
Release Certificate SHA-256 Fingerprint:
43:22:29:4E:D4:CA:A2:D4:29:41:40:09:58:18:08:0F:FE:8A:CC:1F:BE:3C:DC:76:10:7D:F4:5C:52:86:BE:40
```

The section is titled verifying authenticity, and its claim is specific: to check the APK has not been tampered with, compare the signing certificate fingerprint, using a tool such as a third-party verifier application. That is the whole mechanism. There is no key transparency log, no signature over a manifest, and no build attestation; the trust anchor is a hex string you can read out loud and compare against what the installed package reports.

For a project distributed through three different channels, that is the minimum honest thing to publish, and publishing it in full rather than as a truncated prefix means a reader can actually check it. The weak point is equally plain: the fingerprint is only as good as the channel that carried the page to you, which is why the download section offers a store with its own signing rather than only a bare file link.

## The recommendation profile is a file you can read and take away

The recommendation engine is the feature the project is built around, and the argument for it is stated as a gap in other clients: most open-source clients give you playback and nothing else, so you either use the official app and get tracked, or use an alternative and lose recommendations.

The engine runs entirely on the device, with no server, no telemetry, and no account. It learns from what you watch, skip, like, dislike, search for, and how long you watch. It separates weekday from weekend behaviour and morning from night. It watches for fatigue with a topic and mixes in something new, and it exists specifically to stop the feed collapsing onto two or three subjects. It pulls related videos from what you watched recently to make transitions feel natural, and it filters low-quality uploads using engagement ratios rather than view counts alone.

The two features that make that acceptable are administrative rather than clever. There is a transparency screen where you can see what the algorithm knows about you and why it recommended something, and the whole recommendation profile can be exported to a file and imported back. Combined with the privacy section's promise that all data is local and that you can export or delete everything at any time, that is a coherent position: the engine is allowed to know a lot about you precisely because you can see what it knows, take it with you, and erase it.

## Nightly installs beside the stable app and keeps its own data

The distribution section separates the stable line from a rolling one, and the warning is the first thing in it: nightly builds are unstable and may contain bugs, use at your own risk.

Then the design decision, which is the part that makes nightly testing practical on a phone. The nightly channel is built from every commit to the default branch. It installs next to the stable app rather than replacing it, as a separate application with its own name, and it keeps its own data. It also updates itself to each new nightly from inside the app.

That combination solves the three things that usually make nightly builds unusable. Side by side installation means you can run both and compare, which matters when the thing under test is a recommendation engine whose behaviour is hard to judge from a screenshot. Separate data means a nightly crash cannot corrupt the history and library you care about. And in-app updating means you are not re-downloading a file every morning to see whether anything changed.

The stable line, by contrast, is offered through three channels: an install-request scheme handled by a third-party app store, the newest release on the repository, and a third-party repository that publishes packages for a different installer. The tag for the rolling channel is literally named for it, and its title carries a build number rather than a version, so the two channels are distinguishable in any list you look at.

## Two features are separate community projects doing the work

Reading the video feature list closely shows that two of its entries are other people's projects, which is worth naming because the list presents them as features of this one.

SponsorBlock skips sponsors, intros, outros, and filler automatically. That is a community-maintained database of segment timings, maintained separately and consumed here as a capability. DeArrow replaces clickbait thumbnails and titles with community-sourced alternatives, which is a different community effort again, a dataset rather than a service. A third entry, returning a dislike count, is a reimplementation of a feature the official product removed.

None of that is a criticism; reusing a shared dataset is the efficient choice and keeps the client small. But it does mean the app's behaviour depends on infrastructure this project does not host, and the failure modes differ. When the segment database is stale you get the occasional missed sponsor; when the thumbnail dataset is stale you get the old titles back. Neither is a client bug, and neither would show up in this project's issue tracker as one.

The rest of the playback list is standard work for a client of this kind, done with the current media stack: resolution switching across four heights, background playback, picture-in-picture, casting, speed control from a quarter speed to double, chapters, gesture controls, subtitle styling, resume playback, and downloads with two modern video codecs in addition to the standard format. The music half adds a persistent mini player, queue management, shuffle and repeat, and synchronised lyrics.

## Eleven themes, and a screenshot grid with two empty cells

Two small details in the presentation sections are worth pointing out because they are the kind of thing that tells you whether a page is maintained.

The theme list is numbered at eleven and every theme is named: a light and a dark, two blacks, two blues, a green, an orange, a purple, a rose, an ice, and a red. Two of those pairs are near-neighbours, which is a design choice rather than a duplication, and a dark theme and an OLED-black theme are genuinely different targets on a modern panel. So the count is defensible, but it is worth knowing that a third of the list is variations on darkness if you are choosing a theme by name.

The screenshot grid is the other one. It is laid out as four rows of three cells. Eleven cells carry a caption: the home feed, the video player, the personality screen, the music player, the music hub, the library, shorts, subscriptions, a channel view, and an artist page. The twelfth cell is empty, as is a thirteenth in the sense that the last row only has one filled entry. So the grid is one cell larger than the gallery it holds, which is the sort of residue that appears when a section is updated without being reflowed.

The privacy list, by contrast, is exact and short: no account with the video service is required, no ads, no analytics, no tracking, everything stored locally, import from a different open-source client, and export or delete at any time. That last line and the transparency screen are the two claims a user should test first, because both are checkable in a minute and both would invalidate the rest of the argument if they were not true.

## Funding goes through a card, a wallet, and one honest sentence

The support section opens with a personal disclosure rather than a pitch: the project is free and open source, its developer is independent and without traditional banking access, and keeping it alive relies entirely on community support.

Then two paths. The first is a subscription shop that takes a credit card, Apple Pay, or PayPal, with a choice between a monthly amount and a single tip. The second is direct cryptocurrency transfers, offered with the sentence that if you already use crypto you can send it straight to the developer's wallets, followed by a table of coins, networks, and addresses.

The structure is ordinary for an independent Android developer, and the disclosure explains why a wallet address is in the same section as a card. What is worth noting for an evaluator is the shape of the dependency: one person, no corporate backing, and a support model with no service level behind it. That is not a criticism of the software, which is licensed under a copyleft licence and buildable from source, but it does belong in the same paragraph as the maintenance date when you are deciding whether to depend on this client for your daily video watching.

## Conclusion

Use it if you want recommendations without handing a watch history to a server, and if you are the kind of user who will actually open the transparency dashboard and export the profile. Three things to weigh. The recommendation engine is the point and also the cost: it learns from skips, searches, and watch length, so it knows a lot about you by design, which is only acceptable because the state is readable and exportable. The nightly channel installs a second app with its own data and self-updates from inside itself, which is convenient and exactly as unstable as the warning says. And this is an unofficial client for a service that has an official app, so read what that means for your account before you import anything.

## FAQ

### Does the Flow Android app need a Google account?

No. The privacy section lists no Google account required, alongside no ads, no analytics, no tracking, all data stored locally on the device, and the ability to export or delete everything at any time.

### What is the FlowNeuro recommendation engine?

An engine that runs entirely on your phone with no server, telemetry, or account. It learns from what you watch, skip, like, dislike, search for, and how long you watch, separates weekday from weekend patterns, mixes in new content when it detects fatigue with a topic, and filters low-quality videos using like-to-view ratios.

### Can I import my subscriptions and history into Flow?

Yes. The page says you can import subscriptions and history from NewPipe, and the recommendation profile itself can be exported to a file and imported back.

### How do I check that a Flow APK is genuine?

Compare the signing certificate fingerprint of the installed package against the one printed on the project page, using a tool such as AppVerifier. The page publishes the full release certificate fingerprint for exactly that purpose.

## Sources

- [A-EDev/Flow on GitHub](https://github.com/A-EDev/Flow)
- [License: GPL-3.0](https://github.com/A-EDev/Flow/blob/main/LICENSE)
- [Project website](https://flow.aedev.me)
- [README](https://github.com/A-EDev/Flow/blob/main/README.md)
- [Releases](https://github.com/A-EDev/Flow/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/a-edev-flow