Player Updates

Player Updates

Tilecast can verify, cache, and deploy signed Tilecast Player APK releases. Players download from their paired Tilecast server, not from GitHub.

Android and Fire OS can still require a person at the TV to approve installation.

Server trust configuration

Before importing releases, configure the raw Ed25519 public key:

TILECAST_UPDATE_MANIFEST_PUBLIC_KEY=BASE64_RAW_PUBLIC_KEY

Restart Tilecast after changing deployment configuration.

The manifest private key and Android signing keystore must never be installed on Tilecast Server.

Release files

Every release bundle contains exactly:

tilecast-player.apk
tilecast-player-update.json
tilecast-player-update.json.sig

Tilecast verifies:

• Ed25519 manifest signature
• application ID org.tilecast.player
• version code and version name
• stable or beta channel
• minimum Android SDK
• APK filename and size
• APK SHA-256
• Android signing-certificate SHA-256
• downgrade protection
• signing identity continuity

Invalid or incompatible releases are rejected before deployment.

Add a release to Studio

Owners can use Settings → Player updates.

Sync from GitHub

Tilecast checks the fixed Gibsonmb71/tilecast Releases source.

TILECAST_GITHUB_TOKEN is optional and only raises GitHub API rate limits.

Upload release

Upload the APK, JSON manifest, and signature together.

Direct upload and GitHub sync use the same verification pipeline and create the same Player release record. GitHub availability is not required for deployment.

Deploy a release

Owners and Administrators can target screens, groups, or both.

Deployment modes:

• Download only
• Install now
• Maintenance window

Group membership is resolved when the deployment starts. Duplicate screens are removed from the target set.

Deployment states

Studio distinguishes:

• downloading
• verifying
• waiting for install permission
• waiting for user approval
• installing
• reconnecting
• success
• failure
• canceled
• incompatible
• already current

WaitingForPermission and WaitingForUser are expected states, not automatic failures.

Canary rollout

A deployment can begin with a deterministic canary cohort.

Other screens remain held until every canary reconnects successfully. The rollout pauses if a canary:

• reports failure
• enters safe mode
• remains reconnecting past the health window

Review the pause reason before continuing.

Player-side checks

Before installation, Player checks:

• available storage
• complete resumed download
• APK SHA-256
• package name
• version code
• minimum SDK
• signing certificate
• install permission
• emergency state

An active emergency delays installation but does not prevent download.

Pairing credentials, manifests, configuration, disabled state, and media cache live outside the APK and survive replacement.

Success is recorded only after the updated Player reconnects with the expected version and reports healthy playback.

Publishing releases

Release publishers should follow the repository's Player update contract. Do not rotate the Android signing key casually. Android rejects an update signed with a different identity.