Privacy Policy

Last updated: 2026-09-19

StarSonic has no account, no telemetry and no server belonging to its author. It is a client for a music server that you run. This page describes what it does with data; it is short because the app does little.

What stays on your device

• Your server credentials. The address, username and password of each server are held in Android’s own account system on the phone. They are sent only to the server you entered them for, and to nobody else.
• Your library. Artists, albums, tracks and playlists are copied from your server into a database on the device so that browsing works offline. It is a copy of your own catalogue and it never leaves the phone.
• Cached music. Tracks you play are kept in a bounded cache on the device, up to the limit you set in Settings; once it is reached, the oldest tracks make room for new ones automatically. Settings shows how much is in use. Downloads you ask for explicitly are kept separately, until you remove them.

What is sent, and to whom

Only to the server you configured: requests for your catalogue, cover art and audio, authenticated the way the Subsonic protocol prescribes — a token derived from your password rather than the password itself, on every request.

Casting to a Chromecast (Play build only). When you pick a Chromecast from the button in Now Playing, the phone hands it, over your local network, the address of each track on your own server together with its title, artist, album and cover-art address, and the Chromecast then fetches the audio and the cover directly from your server. That address carries the same credential the app itself uses for streaming — the Subsonic token derived from your password, or your Jellyfin access token — never the password itself, so the Chromecast needs to be able to reach your server. Neither the audio nor the credential passes through any service of the author’s. Google’s Cast framework on your phone and the Chromecast is Google’s software and is governed by Google’s privacy policy.

There is no analytics SDK, no crash reporting service and no advertising.

What the author receives

For everything to do with your music: nothing. Your server’s address, your credentials, what you play and what you have — none of it leaves your network, and no service of the author’s is in that path at all.

There is now one thing, and only when you go and use it. StarSonic has a report screen — something is wrong, or an idea — and a messages screen where you read what was written back. This section used to say “Nothing. There is no backend to receive it”, which stopped being true the day those screens were added.

What a report carries

• What you wrote: whether it is a bug or an idea, the title and the description.
• What makes it fixable: the app’s version, your Android version, the phone’s manufacturer and model, and your language tag. Typed into the message by the app — none of it is read from an identifier.
• A screenshot, only if you pick one. Nothing is captured for you, and what you see before sending is exactly what leaves the phone.
• Your email address, only if you type one. Without it a report is anonymous and cannot be answered.
• A random identifier for that single report, so sending twice on a bad connection is not counted as two. Not a device id, not stored on your phone, and different every time.

It goes to apps-management.gpm.name, a service run by the author. Nothing about your music server goes with it — not its address, not your credentials, not your library.

Reading the answers, and the key that costs

A report is answered by email. If you never open the messages screen, nothing here applies to you.

That screen shows what you sent and what came back. Since your reports are yours, it asks for the address and sends a six-digit code there; once checked, the app keeps a key:

• it hangs from the address you proved, never from your phone, and removing the app throws it away rather than recovering it;
• it works for StarSonic only;
• the service stores a one-way hash of it, not the key;
• it stops working after a year unused, and Sign out withdraws it at the service and not only on your phone.

Sending a report needs none of this, and a report carries no identifier of any kind.

Feature requests and votes

The same screen lists what people have asked for, and lets you ask and vote. Reading it costs nothing and needs no address; asking and voting need one, because one vote per person is a promise that has to hang from something. What is published is the request — never your address, and never who voted for what.

Permissions

• Internet and network state — to reach your server.
• Accounts and sync settings — because servers are stored as Android accounts and the library is refreshed by the platform’s sync mechanism.
• Wake lock and foreground service (media playback) — to keep playing with the screen off.
• Notifications — for the sync progress notification, and the playback controls shown while music is playing.
• Wi-Fi state, and coarse and fine location. These are for one optional feature: a server address that only applies on a Wi-Fi network you name, so the app can use, say, a local address at home and a remote one elsewhere. Reading the name of the Wi-Fi network you’re on is what Android classes as a location signal from Android 8 on, and requires the location permissions to work at all — both are declared because since Android 12 asking for fine alone is silently answered with coarse. The app never asks for either at startup: they are requested only if and when you set up a network-specific address, the network name is read on the device to decide which address to use, and nothing about your location or your networks is ever sent anywhere. Without this permission, that one rule simply does not match, and the server’s default address is used instead.

Children

The app is not directed at children and collects nothing from anyone.

Changes

If what the app does with data changes, this page changes with it, and the date above moves. Questions: apps@gpm.name.