Capability Matrix

The TomorrowOS Capability Matrix is the authoritative reference for feature-level capabilities across supported player platforms. Platform support status and certified platform baselines are defined by the canonical compatibility dataset at docs/data/platform-compatibility.json. The capability matrix tracks what each operating system, device model, firmware version and runtime can safely support. TomorrowOS should never assume that every screen, media player or signage operating system can do the same thing. The matrix exists so developers can check feature support before using a capability.

Source of truth

TomorrowOS separates platform support from feature-level capability support:

docs/data/platform-compatibility.json defines which platforms, versions and player releases are currently supported or planned.
This capability matrix defines what features those platforms can safely support and any model, firmware or runtime limitations.
docs/testing/certification.md defines how those capability claims are verified on real hardware.

A platform being marked Supported does not mean every capability is supported on every device or firmware version.

Why the capability matrix matters

Digital signage platforms behave differently across:

Samsung Tizen
BrightSign OS
Windows
LG webOS
Android

Even within the same operating system, support can vary by:

Device model
Firmware version
Browser engine
Media engine
Storage limits
Native API access
App permissions
Commercial display generation
Whether a native bridge or agent is available

The capability matrix keeps TomorrowOS honest, practical and useful in real deployments.

Capability-first principle

Before using a feature, developers should check whether the device can safely support it. Example:

const support = await tomorrow.capabilities.check("playback.video.h264")

if (support.status === "supported") {
  await tomorrow.playback.play({
    type: "video",
    src: "/assets/promo.mp4"
  })
} else {
  await tomorrow.playback.play({
    type: "image",
    src: "/assets/fallback.jpg"
  })
}

Support statuses

Each feature should use one of the following statuses.

Status	Meaning
`supported`	Works through the standard TomorrowOS API
`unsupported`	Not available on this OS/device
`partial`	Works, but with known limits
`model-dependent`	Depends on the exact hardware model
`firmware-dependent`	Depends on firmware or OS version
`requires-bridge`	Requires an agent, native bridge or platform-specific layer
`unsafe`	Possible, but not recommended
`unknown`	Not yet tested

These statuses describe individual capabilities, not the overall release status of a platform. Overall platform status is defined by docs/data/platform-compatibility.json.

Capability record format

Every capability record should include enough information to explain what is supported and why. Example:

{
  "feature": "playback.video.h264",
  "os": "tizen",
  "status": "firmware-dependent",
  "testedModels": ["QM43C"],
  "testedFirmware": ["Tizen 7.0"],
  "runtime": "browser",
  "source": "tested",
  "notes": "Works in tested conditions. Codec and playback behaviour should still be validated per model and firmware.",
  "fallback": "Use fallback image if video preflight fails."
}

Capability categories

The matrix should cover every major area that matters in a real signage deployment.

Device

Device identity
Manufacturer
Model
Serial number, where available
Firmware version
OS version
Runtime type
Screen orientation
Display resolution
Storage availability
Memory availability

Playback

Image playback
Video playback
HTML playback
Widget playback
Playlist playback
Multi-zone playback
Scheduled playback
Looping
Pause
Resume
Stop
Restore last known good content

Image support

JPG
PNG
WebP
SVG
GIF
Transparency
Large image handling
Scaling behaviour
Aspect ratio handling
Rotation behaviour
Memory limits

Video support

MP4
H.264
H.265
VP9
AV1
MOV
WebM
Hardware decoding
Software decoding
First-frame readiness
Looping behaviour
Audio support
Muted autoplay
Video duration handling
Large file handling
Decoder failure behaviour

Transition support

Image to image
Image to video
Video to image
Video to video
Image to widget
Widget to image
Video to widget
Widget to video
Playlist to playlist
Zone to zone
Preloading
Crossfade
Hard cut
Black-frame-safe transition
First-frame guard
Rollback on failed transition

Black gap handling

Detect black screen risk
Keep previous content on screen
Preload next item
Confirm first video frame
Confirm widget entrypoint loaded
Timeout if next content fails
Use fallback content
Roll back to last known good content
Log black gap events

ZIP package validation
Manifest validation
Entrypoint detection
Safe extraction
Path traversal protection
File type validation
Package size limits
Local package mounting
Widget timeout handling
Widget crash detection
Widget fallback content
Package rollback
Package removal

Asset handling

Asset download
Asset checksum
Partial download detection
Local cache
Cache cleanup
Asset expiry
Storage pressure detection
Atomic activation
Download retry
Fallback on failed download
Last known good asset recovery

Display control

Power on
Power off
Reboot
Restart app
Brightness
Volume
Mute
Input source
Orientation
Screen resolution
Panel status
Temperature, where available
Usage hours, where available

Synchronisation

Sync group creation
Join sync group
Leave sync group
Master/follower mode
Start at timestamp
Drift measurement
Drift correction
Video wall support
Panel mapping
Bezel compensation
Network jitter tolerance
Recovery after screen drop-off
Approximate sync
Frame-accurate sync, where available

Telemetry

Heartbeat
Current content
Current playlist
App version
Runtime version
Online/offline state
Playback errors
Package errors
Asset errors
Storage pressure
Memory pressure
Crash logs
Screenshots, where supported
Last successful sync
Last successful proof-of-play

Proof

Proof-of-play
Proof-of-display
Screenshot proof
Timestamped event proof
Playlist proof
Zone proof
Duration proof
Failed playback proof
Exportable audit records

Security

Local API authentication
Permission checks
Safe command validation
Trusted package validation
Token handling
Credential handling
Secret redaction from logs
No unauthenticated destructive commands
No unsafe package extraction
No unnecessary customer data exposure

Example feature naming

Feature names should be predictable and easy to search. Examples:

device.info
device.firmware
playback.image.jpg
playback.image.png
playback.video.h264
playback.video.h265
playback.html
playback.widget
transition.image_to_image
transition.image_to_video
transition.video_to_image
transition.video_to_video
package.zip
package.manifest
package.rollback
asset.download
asset.checksum
asset.atomic_activation
display.power
display.brightness
display.orientation
network.status
sync.group
sync.wall
sync.drift
telemetry.heartbeat
telemetry.screenshot
proof.play
proof.display
security.local_api_auth

OS support table example

The following table illustrates the capability-matrix format. It is not the authoritative source for overall platform release status.

Feature	Tizen	BrightSign OS	Windows	webOS	Android
`playback.image.jpg`	supported	supported	supported	unknown	unknown
`playback.video.h264`	firmware-dependent	supported	supported	unknown	unknown
`package.zip`	requires-bridge	requires-bridge	requires-bridge	unknown	unknown
`display.power`	model-dependent	requires-bridge	partial	unknown	unknown
`telemetry.screenshot`	model-dependent	requires-bridge	supported	unknown	unknown
`sync.wall`	partial	supported	unknown	unknown	unknown

These values are examples of feature-level capability states. Actual support claims should be backed by certification evidence before being treated as production-supported.

Evidence requirements

A capability claim should ideally include:

Operating system
Device model
Firmware version
Runtime or browser engine
Test method
Result
Known limitations
Required bridge or permissions
Fallback behaviour
Date tested

Certification evidence should follow the process described in docs/testing/certification.md.

What not to do

Do not mark a feature as supported just because:

The OS documentation says it might be possible
A similar model supports it
A newer firmware may support it
A browser theoretically supports it
A native API exists but is not accessible from the runtime
A workaround exists but is unsafe or unreliable

If support is uncertain, mark it as unknown, partial, model-dependent, firmware-dependent or requires-bridge. Do not use this matrix to independently change the overall support status of a platform. Platform release status must remain aligned with docs/data/platform-compatibility.json.

Goal

The capability matrix should be the trusted reference for feature-level support and limitations across TomorrowOS player platforms. The canonical compatibility dataset remains the authoritative reference for overall platform support and certified baselines. The value of TomorrowOS is not pretending every platform is the same. The value is giving developers one API while being honest about what each platform can safely support.

Getting started

API

Guides

Platforms

Testing

Capability matrix

Capability Matrix

Source of truth

Why the capability matrix matters

Capability-first principle

Support statuses

Capability record format

Capability categories

Device

Playback

Image support

Video support

Transition support

Black gap handling

Package and widget support

Asset handling

Display control

Network

Synchronisation

Telemetry

Proof

Security

Example feature naming

OS support table example

Evidence requirements

What not to do

Goal

​Capability Matrix

​Source of truth

​Why the capability matrix matters

​Capability-first principle

​Support statuses

​Capability record format

​Capability categories

​Device

​Playback

​Image support

​Video support

​Transition support

​Black gap handling

​Package and widget support

​Asset handling

​Display control

​Network

​Synchronisation

​Telemetry

​Proof

​Security

​Example feature naming

​OS support table example

​Evidence requirements

​What not to do

​Goal

Capability Matrix

Source of truth

Why the capability matrix matters

Capability-first principle

Support statuses

Capability record format

Capability categories

Device

Playback

Image support

Video support

Transition support

Black gap handling

Package and widget support

Asset handling

Display control

Network

Synchronisation

Telemetry

Proof

Security

Example feature naming

OS support table example

Evidence requirements

What not to do

Goal