Overview

Deb applications are native packages that run directly on the TOS 7 host system. They follow standard Debian packaging specifications, adapted for TOS service management and platform integration.

TOS 7 Deb applications are divided into three subtypes based on whether they have a frontend page and how it is opened:

Subtype	Use Case	Opening Method	Backend Communication
WebUI Internal Open	Backend is a local executable service, frontend is a static WebUI	TOS desktop embedded iframe	Unix Socket + Platform Proxy
WebUI External Open	Backend is a local executable service, frontend is a static WebUI	New browser tab	Nginx Reverse Proxy + HTTP Port
No UI Service	Background service without an interface	No frontend page	As needed (no mandatory requirements)

Subtype Selection Mandatory Constraints:

Application Characteristic	Required Subtype
Has Web UI and must open within the TOS desktop	WebUI Internal Open (iframe)
Has Web UI and must open in a browser tab	WebUI External Open (new tab)
No frontend / background daemon service	No UI Service
Needs to access device filesystem via TOS File Manager	WebUI Internal or External Open — if the application requires users to select file paths in the TOS File Manager, it must provide a WebUI (either internal or external) to embed the file picker component.

TOS 7 Deb applications support two packaging methods:

Packaging Method	Use Case	Description
Method 1: Single-Package Mode	New applications developed from scratch	Developers develop directly according to TOS 7.0 specifications, integrating all files into a single deb package
Method 2: Dual-Package Mode (also called Archive Mode)	Applications with existing generic standard deb packages	The original application package (deb source package) remains unchanged, with an additional data package (<appid>.deb) conforming to TOS 7.0 specifications provided; both are packaged into a tar.gz archive for submission

Dual-Package Mode Applicability Rules:

Scenario	Must Use	Must Not Use
Existing generic standard deb package, complex build	Dual-package mode	—
New application developed from scratch	—	Not recommended to use dual-package mode — unless there is a special reason (such as needing to separate configuration from binaries), new applications developed from scratch should use single-package mode.
Simple binary program, no existing packaging	—	Dual-package mode (should use single-package mode)
Third-party upstream Debian packages	Dual-package mode	—

Dual-Package Mode Mandatory Constraints:

• Version Display (not a consistency requirement): the platform does not require the two packages to carry the same Version, and does not compare them. The version shown in the App Center always comes from the version field in config.ini — make sure that field states the version you intend to release.
• Content Restrictions: The data package (<appid>.deb) must not contain any binary files, otherwise it will be immediately rejected.
• Installation Order: Automatically guaranteed by the APT repository dependency mechanism (data package Depends on the source package); no additional configuration required.
• Source Package Independence: The deb source package must be independently installable on the TOS 7.0 system using the dpkg -i command.
• Dependency Declaration: The Depends field in the deb data package metadata must include the deb source package, preferably specifying the version as well, to maintain healthy dependency relationships.