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 Consistency: The Version fields of the data package and source package must be exactly the same; inconsistencies result in immediate rejection.
• 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.