Apps

Heddohon is a web app, and every browser plays it. Beside that there are three ways to have it as an app: a desktop app for Linux and Windows, an experimental app for Android, and the page installed by the browser on a Mac, an iPhone or an iPad.

The desktop app and the Android app hold nothing of the web app. Each asks for your server's address once and opens that server, so a server upgrade needs no new app. Both are files on each release, from 0.5.0.

System	What to get
Linux	heddohon-<version>-x86_64.AppImage or heddohon-<version>-arm64.AppImage
Windows	heddohon-<version>-setup.exe, an installer, or heddohon-<version>-portable.exe, which installs nothing
Android	heddohon-<version>.apk
macOS	Chrome and Edge: Install on the card Heddohon shows, or in Settings, Appearance. Safari 17 or later: File, Add to Dock.
iPhone and iPad	Safari: Share, Add to Home Screen.

Once something has played, Heddohon shows a card that names the one for the device it is on. Not now puts it away on the account. Settings, Appearance, Install the app has the same at any time.

Desktop: Linux and Windows

A window of its own around your server, with a launcher entry and the desktop's media controls: MPRIS on Linux (media keys, the GNOME and KDE controls, playerctl), the system media controls on Windows.

• Linux. Make the AppImage executable and run it. It needs FUSE 2 (libfuse2), or run it with --appimage-extract-and-run.
• Windows. The files are not signed. SmartScreen stops the first start with "Windows protected your PC": choose More info, then Run anyway. The installer installs for the signed-in user, without administrator rights.
• The menu bar is hidden until Alt is pressed. The Heddohon menu has Change server, Check for updates and Software rendering.
• Updates. The app does not update itself: the file is replaced with the newer one. It asks GitHub once per start for the latest release, says a newer one once in a dialog, and keeps it listed in the menu. Check for updates asks at once.
• A window that will not open, or closes at once. On a machine whose graphics driver Chromium cannot use (a virtual machine, a remote desktop) the terminal shows CommandBufferHelper::AllocateRingBuffer() failed. The second failure in a run switches the app to software rendering and starts it again. The next start says so in a dialog, once, with Use the graphics card again to switch back. Software rendering in the menu switches it by hand, and --disable-gpu does it for one run.

The rest is in the app's README: what the window is allowed, running it from source, and its tests.

Android (experimental)

The app opens your server as a Trusted Web Activity: the page runs in the phone's own browser, full screen. Playback with the screen off, the media notification and the lock-screen controls are the browser's, the same as in a tab.

• https only. A plain http address is turned down with a message.
• One file for every processor: ARM, ARM64, x86 and x86_64.
• A browser is needed that supports Trusted Web Activities: Chrome, Edge, Samsung Internet, Brave.
• Changing the server. Press and hold the app's icon and choose Change server.
• Updates. It is not on the Play Store. The app asks GitHub once a day for the latest release and says a newer one once, at the next start. Obtainium can install it from the releases page and keep it up to date.
• The status bar and the navigation bar are the browser's. It paints them, and the page does not draw under them.

The address bar

The browser hides its address bar only for a server that vouches for the app. Heddohon 0.5.0 and later does, at /.well-known/assetlinks.json. On an older server, or for an app signed with another key, the page opens with the address bar showing.

The browser asks Google's servers whether the file is there, and they fetch it from the internet without a sign-in. If the bar still shows on 0.5.0 or later, open this address, with your server's in place of the example:

https://digitalassetlinks.googleapis.com/v1/statements:list?source.web.site=https://music.example.com&relation=delegate_permission/common.handle_all_urls

An answer with statements naming app.heddohon.android means the server is vouching, and the browser asks again when the app is next opened. An answer with errorCode says what Google got instead. ERROR_CODE_REDIRECT is a reverse proxy sending it to a sign-in page: let /.well-known/assetlinks.json through for everyone, on every address the name resolves to. A proxy that answers over IPv4 and asks for a sign-in over IPv6 fails the check.

An app you built and signed yourself is vouched for with HEDDOHON_ANDROID_FINGERPRINTS.

A sign-in in front of the server

Behind a reverse proxy that asks who you are first (Authelia, Authentik, oauth2-proxy, Pangolin, Cloudflare Access, basic auth):

• The desktop app shows the proxy's sign-in pages in its window and keeps the cookie the proxy sets. Basic auth is asked for in a prompt at each start. Request headers, such as a service token (Cloudflare Access's CF-Access-Client-Id and CF-Access-Client-Secret), are typed at the address screen under "A sign-in in front of the server", one Name: value to a line, up to ten. They are sent to the server's address and to no other. An identity provider that refuses embedded browsers (Google's sign-in does) cannot be used this way.
• The Android app cannot tell whether a Heddohon is behind the sign-in, says so, and offers Open it anyway. The sign-in then happens in the browser, which keeps it. It cannot send custom headers: the requests are the browser's.