Privacy Policy

Last updated: 2026-10-29

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.

A server can also be signed in to with an API key, on servers that issue them. The key is sent instead of the password, never alongside it, and is stored on the phone exactly where the password would be, in Android’s account system, and goes only to that server.

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.
• The app’s log, only if you switch it on. The report screen shows exactly what would be sent before you send it. It is off unless you turn it on. The log is a short list the app keeps in its own private storage, capped in size and readable by nothing else, and it is sent nowhere unless you attach it: when the app started and which build it is, that a scan of your server began and how many artists, albums, playlists and tracks it brought back, whether a sign-in worked or the kind of way it failed, the player going idle, buffering, playing or stopped, and the name of an error with its error code. It never records your server’s address, your username or the name of an account, the name of a Wi-Fi network, a title, an artist, an album or anything else about what you listen to. Because those are not written down in the first place, they are not scrubbed out of something longer; as a second check, addresses, account names, network names, media identifiers, email addresses, coordinates and anything that looks like a key, token or password are also masked before the preview is shown.
• 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.
• The IP address it was sent from. It is stored with the report, and only the moderator sees it.
• A fingerprint of your device, made from its Android ID (Settings.Secure.ANDROID_ID), which the app reads without any permission. Android gives every app its own value, tied to the app’s signing key, so two apps by Gabriele Proietti Mattia see different ones, and a factory reset changes it. The service keeps only a keyed one-way hash of it, never the value itself, and never shows it to anyone.

The same two go with a feature request. Both are there to keep abuse out, so that someone who sends abuse can be banned by device. It is never the advertising ID, and there is no install id of our own.

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.

Keeping abuse out

A report or a feature request containing obscene words is not stored and not forwarded to anybody. Its sender is banned, without being told:

• by the device fingerprint, permanently;
• by the IP address, for 30 days;
• by the account or address, permanently, but only if you were signed in or had verified the address. An address you merely typed into the form is never banned.

The owner can lift any ban. If you think you were banned by mistake, write to apps@gpm.name.

The IP address and the device fingerprint are kept with the report as long as the report is kept. Ban records stay until they expire (30 days for an IP address) or are lifted. Keeping them rests on a legitimate interest in protecting the service and the people who run it.

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 key or login, only the IP address and the device fingerprint described above.

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.