• Intermediate
• 6 min read
• Updated 2026-10-09

The dashboard totals tell you what happened. The app view tells you who did it — and lets a single connection become a rule. It is the most hands-on part of ClearDeck, so this guide goes from finding it to writing a rule that sticks.

Getting there

The app list is not a bottom tab. The bottom bar has only Dashboard, Modules, Settings and Tools, and nothing else. You reach the app view from the dashboard, in one of two ways:

• Tap the Connections / 活跃连接 tile.
• Tap More / 更多 next to Top 5 apps.

Both open the same screen, which has two tabs, Live and History. Connections lands you on the live side; More leads into the history list.

Live and History

The list is split into two tabs, and the row text tells you which one you are reading:

Live is a snapshot of this instant and shifts as apps open and close connections. History is cumulative: it counts every attempt an app made in the current protection session, blocked or not. It is the tab to read when you want to know what an app has been up to rather than what it is doing right now.

Rows you may not recognise

A few rows do not carry an app name. When the system cannot attribute a connection to an installed app, the row shows Unknown source / 未知来源, or uid <number> when Android can name the owning user ID but not an app. These are not bugs. They are ClearDeck reporting what Android would and would not tell it, instead of inventing a name.

App detail

Tapping an app opens its detail page. Three tiles sit at the top, matching the vocabulary used at the top level:

Below them is a card of the blocked categories — which kinds of rules caught this app’s connections. An entry caught at the URL level rather than the domain level carries a Deep / 深度 badge. That badge is the sign that the block came from URL matching rather than a domain on a list — the clearest evidence that deep inspection is doing anything. See Deep inspection.

The access log

Access log / 访问日志 is an expandable list of the individual attempts this app made. Each record is one connection, with its host and result, and — this is the useful part — two buttons: Block / 拦截 and Allow / 放行. Those buttons are how a passive record becomes an active rule.

Above the list sit a filter and a sort control:

Group by site / 按站点聚合 collapses many records from the same site into a single row, which is what you want when an app talks to one host dozens of times and you are scanning for what it contacts at all. By time is better when you are chasing a single event — “what happened right after I opened it?”

Turning a record into a rule

Tapping Block or Allow does not write the rule straight away. It opens a chooser titled Apply to… / 应用到… with two options:

All apps is broad: it applies to every app rather than just the one you were looking at, and it becomes a global rule. This app only is the safer default when you are unsure, and you can always add the broader rule later. Rules you have added for this app also appear on the detail page, where you can remove them one at a time with Remove.

Either way, what you add lands in My block & allow / 我的拦截与放行 on the Modules tab. That card is deliberately not something you can switch off with one tap, because these are your decisions rather than a bundled list. Two rules of precedence apply there:

• An allow rule beats a block rule for the same host. If you allow a host, no module can re-block it.
• A rule you wrote beats a bundled module. Always.

Both are intentional: the built-in lists are defaults, and your decisions outrank them.

Export, and one warning

Export log / 导出日志 is available on this screen, so you can save a single app’s records. The format, the columns and the full procedure are in Export the access log.

Next

• Understand the dashboard — where these numbers come from
• Modules — the lists your own rules override
• Export the access log — keeping a record before it clears

This guide is also available in 简体中文