Skip to content
RoyalPlayzYT
All work
Working prototypeProduct Design / Android App2026

Lyra

An original-branded Android music app — new name, icon, package, and theme over an open-source player base, with attribution kept in the About screen.

  • Android
  • Kotlin
  • Gradle

Overview

Lyra is an Android music player with its own identity: a new brand name, app icon, package name, and dark theme, built on the Echo Music v1.4.1 open-source base. The original project's attribution was kept in the About screen — the rebrand changes the surface, not the credit.

It exists today as a signed release APK that installs and plays. It is not published on the Play Store, so this is presented as a working prototype rather than a shipped product.

Problem / Goal

I wanted to understand what it actually takes to take an open-source Android app and give it a complete, coherent identity — and to get a signed release build out the other end. The interesting part wasn't the features, it was the pipeline: branding, build configuration, signing, and producing an installable artifact.

Approach

  • Full identity pass: package rename, launcher icon, theme colors, and app name, applied consistently across manifests, resources, and build files.
  • Release build with a fresh signing key, built on a memory-constrained machine — which forced careful Gradle tuning rather than bigger hardware.
  • Kept the upstream attribution visible in the app's About screen.

Selected features

  • Complete rebrand: name, icon, package, themeBuilt
  • Signed release APK (FOSS build, no proprietary services)Built
  • Local music library browsing and playbackBuilt
  • Play Store publicationPlanned

Constraints & challenges

The build kept dying on a small VM

Release builds with R8 ran out of memory on a 7.7 GB machine with no swap. The fix was tuning the Gradle daemon heap down to 2 GB, disabling lint-vital checks for release, and — critically — never running two release builds at the same time after a four-way concurrent build thrashed the machine.

Renaming a package without breaking the app

A package rename touches manifests, deep links, providers, and build flavors. Each surface had to be found and updated together, then verified with a clean install — a partial rename is worse than no rename.

Outcome & lessons

  • 01The build environment is part of the project; document its quirks.
  • 02Attribution survives a rebrand — credit the base, own the surface.
  • 03A finished APK beats a perfect plan: shipping the artifact is the milestone.