PixelPlayer: a local-first Android music player with AI playlists

Local playback with Media3, and FFmpeg for the formats Android misses

The audio stack is the part of this project that determines whether you can live with it, and it is conventional. The tech stack table names Media3 ExoPlayer as the audio engine with FFmpeg support, which in practice means the platform decoder handles the common formats and FFmpeg handles the rest. The feature list names the formats outright: MP3, FLAC, AAC, OGG, WAV and more.

Playback is a full media session, so background play and lock screen controls are part of the design rather than a later addition. The queue supports drag-and-drop reordering, all shuffle and repeat modes are covered, gapless playback is listed for transitions between tracks, and crossfade timing is configurable between songs.

Library organisation is unusually thorough for an app of this size. You can browse by songs, albums, artists, genres or folders, which is what makes it usable on a device where the folder layout is meaningful. There is a configurable delimiter setting for parsing multi-artist tags, proper album artist grouping so compilations do not collapse into one artist, and a folder filter so the scanner only looks where you want it to.

The design bet here is that your files are the source of truth. Nothing in the feature list suggests a streaming catalogue, a subscription or an account.

Lyrics, artwork and a tag editor that writes back to your files

The metadata features are what separate this from a bare audio player.

Synchronised lyrics come in LRC format over the LRCLIB API, and the app can display them as a scrolling view that follows playback. It also lets you edit lyrics or add them to a track, which means a missing lyric is a solvable problem rather than a dead end.

Artist artwork is pulled from the Deezer API with a fallback icon when no image is found. The caching is described as two layers, an in-memory LRU plus a database, so the second lookup of an artist does not need the network and works offline. The practical consequence is that a library browsed once stays browsable without a connection.

The Tag Editor writes metadata back to files using TagLib, with MP3, FLAC and M4A named as supported. This is the feature with the widest blast radius in the whole app, because it modifies the originals rather than a local database. A batch metadata edit landed in the 0.7.5-beta release, which makes it a bulk operation rather than a single-file fix.

Together these three features mean the app can repair a messy library rather than just display it, which is the argument for tolerating its beta status if your music is badly tagged.

Where the AI features actually sit

There are three AI-adjacent features and they are worth separating, because only one of them is the generative feature the marketing tends to lead with.

AI Playlists is the generative one. The README states it supports Gemini, Deepseek and OpenAI, and a Daily Mix described as AI-powered and personalised from listening habits. The 0.7.0-beta notes add Groq AI and OpenRouter as experimental providers, and the 0.7.5-beta notes mention deleting old Gemini model identifiers and adding Gemma 4. AI translation also appears in the 0.7.5-beta changes, which is a separate feature from playlist generation.

None of this is needed for playback. A player that generates a playlist from a library you already own is a convenience layer, and turning it off costs you nothing but the feature.

The rest of the connectivity story is more substantive. Chromecast streaming is supported. Glance widgets give home screen control. The 0.7.0-beta release added Wear OS with music transfer, local playback on the watch, queue synchronisation and remote control from the watch, which is a bigger piece of work than the release note's one line suggests. Jellyfin support arrived in the same release, and Google Drive support in 0.7.5-beta, alongside a fix for MediaStore URI resolution when files are deleted.

One feature is listed but not finished: Android Auto appears in the feature list marked Soon, so in-car playback is not something to plan around yet.

Every release is a beta, and the README builds from a fork-friendly clone line

The README's install section is a source build, not an APK install, and it starts here:

git clone https://github.com/theovilardo/PixelPlayer.git

Then you open the cloned directory as an existing project in Android Studio, wait for Gradle to sync, build, and run on a device or emulator. The stated prerequisites are Android Studio Ladybug 2024.2.1 or newer, Android SDK 29 or higher, and JDK 11 or higher. The runtime requirements are Android 11, API level 30, with 6GB of RAM recommended for smooth performance.

There is a mismatch worth noticing immediately: that clone URL does not match the repository you are reading. The project lives under PixelPlayerHQ, and every badge, the latest release link and the download button in the README still point at theovilardo. So the documented build step lands on a different repository than the one whose source you were reading. The package name is com.theveloper.pixelplay, which is a third naming scheme, and the Obtainium link encodes that package id along with the theovilardo repository URL.

The README carries a disclaimer that no fork will receive support, and asks forks to support their own users. Given the amount of forking this project invites, that disclaimer is the most load-bearing line in the document.

Three beta releases, 578 open issues, and months of unreleased work

The release history is three entries long and every one carries a beta suffix. Version 0.6.0-beta was published on 2026-03-10. Version 0.7.0-beta followed on 2026-05-25 with Wear OS, the experimental AI providers and Jellyfin. Version 0.7.5-beta was published on 2026-06-13 with Google Drive support, AI translation, battery consumption work, MediaStore URI resolution fixes and a batch metadata editor.

The last push to the default branch, master, was on 2026-09-21. That is a little over three months after the last tagged release, so the master branch is substantially ahead of anything installable from the releases page.

The issue count is the other number that stands out: 578 open issues, against 517 forks and roughly 6,500 stars. For comparison, a project with a similar star count and a stable release cadence typically carries an order of magnitude fewer. That combination, high stars plus high open issues plus beta-only releases, is the signature of a project with real adoption and no maintainer capacity to match it. It is also why the single-author commit pattern in the release notes matters: most changes are merged by one person between community contributions.

The repository is not archived, has no homepage set, and its topics list is empty, which means none of this activity is discoverable through GitHub's topic pages.

A multi-module project with a Wear app and a baseline profile

The source tree shows what this app actually is. There is an app module, a wear module, a shared module, and three directories that are not part of a typical Android project layout: baselineprofile, remote-config and docs.

The baseline profile directory is the most interesting of those for performance. On Android, a baseline profile lets the runtime skip interpretation and AOT-compile the hot paths at install time, which is exactly what you want for an audio player that must start playback quickly from a notification tap. Shipping one is a deliberate piece of engineering rather than a default.

The remote-config directory suggests configuration can be pushed to installed clients, which matters for a project whose feature list is still moving. It also means behaviour can change without an app update, which is worth knowing before you rely on any single feature.

The app module's own package layout is conventional and readable: data split into database for Room entities, DAOs and migrations, model for domain types, network for the LRCLIB and Deezer services, preferences for DataStore, repository, service for the music service and an HTTP server, and worker for WorkManager sync jobs, with di for Hilt modules and presentation split into components and navigation. Standard Kotlin practice throughout, with Hilt for injection, Room for storage, Retrofit and OkHttp for networking, Coil for images, coroutines and Flow throughout, and Glance for widgets.

The repository description promises three things the README does not deliver

Comparing the repository's own description against its README turns up three separate gaps, and they are worth checking before you rely on any of them.

The description calls this a privacy-first player. The README contains no privacy claim anywhere, no data collection section and no policy document. The architecture is consistent with the description, since playback is local and the only outbound calls are lyrics, artwork and whatever AI provider you configure, but consistent architecture is not a privacy policy.

The description says Material 3 Expressive. The README says Material Design 3, and the tech stack table also says Material Design 3. One of these is an older name and the other a newer one, but the README does not mention Expressive at all.

The description promises equalizer presets, and the feature list has no equalizer entry. There is a custom transitions setting for crossfades and a Tag Editor, but nothing that shapes frequency response. That gap matters most, because an equalizer is the feature people most often look for in a local player and the one that would be hardest to add later without changing the audio pipeline.

Taken together, the description reads like a plan for where the project is going and the README reads like where it is. The README is the one to trust on that basis.

Editorial conclusion

PixelPlayer is a genuine local music player rather than a streaming client with a local mode bolted on. Playback runs through Media3 with FFmpeg, the library comes off disk, lyrics come from LRCLIB and artwork from Deezer, and the AI features generate playlists rather than a catalogue. What you give up for that is obvious: everything depends on your own files being present and tagged. Two practical warnings come out of the repository itself. The README links to theovilardo/PixelPlayer throughout, so build and release URLs need fixing by hand. And every tagged release is a beta, so the version you install from GitHub is not the version the source tree represents. Clone, open in Android Studio, and build before you judge it.

Frequently asked questions

Official sources

1. Issues
2. PixelPlayerHQ/PixelPlayer on GitHub
3. README
4. Releases