# Tempus for Android: A Native Subsonic Music Client

> Tempus is an Android client for self-hosted Subsonic libraries, with streaming, offline playback, playlists, transcoding, scrobbling, and optional Internet radio. The GitHub build is the documented choice when Android Auto or Chromecast support is required.

**eddyizm/tempus** — An open source and lightweight music client for Subsonic, designed and built natively for Android.

- Repository: https://github.com/eddyizm/tempus
- Website: https://eddyizm.github.io/tempus/
- Stars: 1,386 · Forks: 167
- Language: Java
- License: GPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/eddyizm-tempus

## Why Tempus Exists for Subsonic Library Owners

Tempus addresses a specific gap between a self-hosted music collection and an Android phone. The music remains in a Subsonic-compatible service, while Tempus supplies the mobile interface for browsing, searching, streaming, and playlist work. It is aimed at people who want access to their own server across Android devices rather than a catalog supplied by a commercial streaming service.

The project is also useful for listeners who want the server to remain part of playback control. The README documents server-side transcoding profiles, meaning compatible files can be converted for streaming according to a selected profile. It also describes ReplayGain behavior based on metadata, which can address volume differences between tracks when the required information is present. These are server and metadata dependent features, not guarantees that every deployment will produce identical results.

Tempus is a fork of Tempo. That lineage matters when evaluating the code and its feature history, although the README does not provide a technical comparison between the two applications. The documented feature set is centered on a Subsonic server, with optional support for services such as Last.fm and Listenbrainz.org. The project explicitly avoids choosing music through an undisclosed recommendation algorithm. Its listening interface instead draws on listening history, random playback, and optional integrations supported by the backend.

This makes Tempus more appropriate for a user who already understands servers, APIs, metadata, and library organization. It is not presented as an all-in-one library acquisition service. The user still needs a Subsonic-compatible backend, stored music, and the relevant metadata or endpoints for optional functions.

## How Tempus Connects to a Subsonic Library

The documented data flow starts with a user connecting Tempus to a Subsonic server. The app then exposes the library through browsing categories that include artists, albums, genres, playlists, and decades. Search is part of the same server-backed interaction rather than a separate recommendation catalog. Multiple libraries are presented as library folders, which gives users a direct way to distinguish collections served by the same backend.

Playback has several server-facing layers. Streaming sends track requests to the Subsonic service, while the transcoding feature can ask that service to convert audio through a selected profile. The server therefore remains responsible for locating media and, when requested, transforming it. Tempus provides the Android playback interface around those requests.

The README also describes an Instant Mix refactor based on the Subsonic `similarSongs2` mechanism, including artist, album, and similar-song endpoints. This is a server-generated queue rather than a claim that the Android device contains the entire collection. Availability and results depend on backend support. If those endpoints are absent or behave differently, the documentation does not describe a complete fallback.

Optional metadata and integration services form another layer. Last.fm and Listenbrainz.org can receive scrobbles and contribute listening information, but the backend must support the relevant integration. Podcasts likewise depend on Subsonic server support. Radio is different: the README says Tempus can search for and save Internet radio stations locally even without a backend Subsonic API, although it remains an Android client rather than a server deployment.

## Install Options and the First Tempus Setup

The README does not document a Gradle build command for installing Tempus from source. It directs users to several existing distribution channels instead: F-Droid, GitHub Releases, IzzyOnDroid, Obtainium, and OpenAPK. The README links to the project homepage and release page for those download paths, so there is no justified reason to invent an Android SDK setup or a custom Gradle invocation here.

Users should choose a distribution according to the variant they need. The README states that the GitHub release includes Android Auto and Chromecast support. It also distinguishes the `app-tempus` GitHub asset from the `app-degoogled*` IzzyOnDroid asset, which omits Google-related functionality. Release assets include release or debug and 32-bit or 64-bit flavors, so architecture matters when selecting a file.

After installing an APK, the documented first-use task is to connect Tempus to a Subsonic server. The README does not give exact field names for server address, credentials, or transport settings, so those details should be obtained from the application or the linked usage documentation rather than reconstructed from the project description. Users should confirm that the backend is reachable from the Android device before diagnosing playback problems.

The README provides this signing fingerprint for release verification:

```text
B7:85:01:B9:34:D0:4E:0A:CA:8D:94:AF:D6:72:6A:4D:1D:CE:65:79:7F:1D:41:71:0F:64:3C:29:00:EB:1D:1D
```

Use the release or distribution source appropriate to the required variant, then verify the downloaded artifact against the project documentation before installing it.

## Offline Mode, Multiple Libraries, and Playback Controls

Offline mode is one of Tempus's most relevant features for users with intermittent connectivity, but the README also places a clear qualification around it. The feature is currently under active development, and the documentation warns that it may have limitations when using multiple servers. That warning should be read literally. The README does not specify which tracks are cached, how cache conflicts are resolved, how much device storage is required, or whether every playback control behaves identically offline.

Multiple-library support is therefore not equivalent to unrestricted offline operation. A user can see libraries as folders, but should not assume that a server-specific queue, credential, cached track, or synchronization state behaves identically across servers. The project documentation does not claim that it solves these edge cases, so an engineer evaluating the app needs to test the exact combination of accounts, libraries, and network conditions that matters.

Other playback features include gapless playback, ReplayGain, an equalizer, and a widget for basic controls. ReplayGain depends on metadata supplied by the library. The equalizer can use a built-in option or a third-party equalizer, which means the available behavior may also depend on software installed on the Android device. Podcasts require server support, while transcoding requires a server that implements it.

The widget is a convenience surface rather than a separate synchronization mechanism. The README does not explain whether it changes what is cached or available while offline. Its documented purpose is limited to keeping basic controls on the screen.

## Tempus Variant Differences and Upgrade Constraints

Variant selection is the main practical deployment constraint. The README says the `app-tempus` GitHub release has the full Android Auto and Chromecast feature set. The IzzyOnDroid `app-degoogled*` release goes without Google functionality, and the README states that 32-bit and 64-bit APKs are available on GitHub for users who need the 32-bit option. A user choosing between channels is therefore choosing both an update source and a feature set.

This distinction is easy to miss because the project presents F-Droid and GitHub together in its feature description. The release asset naming is the more precise signal. Android Auto or Chromecast users should use the GitHub variant if those features are required, while users who need a degoogled build should inspect the `app-degoogled*` asset and its architecture.

The repository contains Android and Gradle project files, including `build.gradle`, `settings.gradle`, `app/`, `gradle/`, and wrapper files. The README does not state supported Android API levels, Gradle invocation, Java version, build prerequisites, or local signing procedure. It would therefore be unsafe to present source compilation as a documented installation route. The repository layout confirms an Android application project, but not a complete build tutorial.

Maintenance status is current in the project record: the repository is not archived and its last push was on 2026-10-14. Recent releases include `v4.29.0`, `v4.29.1-dev`, and `v4.28.4-dev`. Those names also show that development and prerelease naming are part of the release workflow. The README links `CHANGELOG.md` for release details, so users deciding whether to upgrade should inspect that file for the specific change rather than relying on the version string alone.

## Tempus Compared with a Standalone Android Music Player

The main alternative is a conventional local music player that reads files from Android storage or a configured media folder. The difference is not merely visual. A local player centers playback around files already available on the device, while Tempus centers the user’s server-backed Subsonic library and can ask that server to locate or transcode media.

This architectural difference affects setup. A local player can work with files copied to a phone. Tempus requires a compatible Subsonic service, network access for streaming, and server capabilities for several optional features. In return, Tempus can browse a server catalog, handle libraries as folders, expose playlists, use server-side transcoding profiles, and expose server podcast functionality.

Tempus is therefore the better fit when the library is hosted elsewhere and remote access is the primary use case. A local player is the better fit when offline autonomy, direct file organization, or independence from a server matters most. Tempus does offer offline mode, but the README explicitly warns about its current limitations, particularly with multiple servers, so it should not be categorized as a complete replacement for a local file-based library.

The comparison also explains why the GitHub and IzzyOnDroid variants are not interchangeable for every user. A degoogled build may be desirable for privacy or software sourcing preferences, while the GitHub build preserves Android Auto and Chromecast support. The correct alternative depends on which constraint matters first: server access, offline local files, Google-free distribution, or cast and car integration.

## Conclusion

Tempus suits Android users who already operate a compatible Subsonic backend and want library-controlled playback without a proprietary music service. It is a poor fit for users seeking a standalone local music player, an undocumented server-install path, or certainty about every offline multi-server case. Before adoption, verify the chosen release asset, backend support for the required Subsonic endpoints, and whether the multi-server offline limitations affect the intended library setup. The most concrete starting point is the GitHub release when Android Auto or Chromecast support matters.

## FAQ

### What is Tempus used for?

Tempus is an Android music client for accessing and playing a Subsonic library. It is intended for users who host their music on a compatible Subsonic-compatible backend.

### Does Tempus support offline playback?

Yes, Tempus documents an offline mode, but says it is under active development and may have limitations with multiple servers. The README does not specify cache scope or storage requirements.

### Which Tempus build supports Android Auto and Chromecast?

The README states that the GitHub version includes Android Auto and Chromecast support. It distinguishes this from the `app-degoogled*` IzzyOnDroid release, which omits Google-related functionality.

### Does Tempus require a Subsonic server for Internet radio?

No. The README says Tempus can search for and save Internet radio stations locally even without backend Subsonic API support, although its primary library features remain centered on Subsonic.

## Sources

- [eddyizm/tempus on GitHub](https://github.com/eddyizm/tempus)
- [License: GPL-3.0](https://github.com/eddyizm/tempus/blob/main/LICENSE)
- [Project website](https://eddyizm.github.io/tempus/)
- [README](https://github.com/eddyizm/tempus/blob/main/README.md)
- [Releases](https://github.com/eddyizm/tempus/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eddyizm-tempus