企业官网建设流程全解析

在 UOS 应用适配过程中，有时需要判断系统是否已经开启开发者模式。常见的实现思路有两种：检查系统中的开发者模式标志文件，或者通过 DBus 接口查询。

下面分别记录这两种方式的实现，以及使用时需要注意的地方。

先判断当前系统是不是 UOS

无论采用哪种方式，都可以先读取/etc/os-release，根据其中的ID判断当前系统。

bool isUosSystem() { const QString path = "/etc/os-release"; if (!QFile::exists(path)) { return false; } QSettings releaseFile( path, QSettings::IniFormat ); const QString systemId = releaseFile.value("ID").toString(); return systemId.contains( "uos", Qt::CaseInsensitive ); }

/etc/os-release是 Linux 中常见的系统信息文件。这里只读取ID字段，不需要根据系统显示名称或者版本字符串进行判断。

方式一：检查开发者模式标志文件

UOS 开启开发者模式后，可以通过下面的标志文件判断状态：

/var/lib/deepin/developer-mode/enabled

使用 Qt 判断时，代码比较简单：

bool isDeveloperModeEnabledByFile() { if (!isUosSystem()) { return false; } return QFile::exists( "/var/lib/deepin/developer-mode/enabled" ); }

这种方式本质上是判断标志文件是否存在，并不需要读取文件内容。

它的特点是实现简单，不需要创建 DBus 对象，也不依赖目标服务当前是否正常响应。需要注意的是，代码会依赖具体文件路径，因此在不同系统版本或不同发行版中使用时，要确认对应路径是否一致。

需要额外注意的是，在实际签名过程中，程序直接访问这个路径曾被签名检测判定为风险操作，并导致签名被拒。使用文件判断方式时，最好提前确认目标系统的签名规则。

方式二：通过 DBus 接口查询

另一种方式是连接 System Bus，通过系统服务查询开发者模式。

接口信息如下：

Service: com.deepin.sync.Helper Path: /com/deepin/sync/Helper Interface: com.deepin.sync.Helper Method: IsDeveloperMode

使用 Qt DBus 调用的示例：

bool isDeveloperModeEnabledByDBus() { QDBusConnection bus = QDBusConnection::systemBus(); if (!bus.isConnected()) { qWarning() << "System Bus is not connected"; return false; } QDBusInterface iface( "com.deepin.sync.Helper", "/com/deepin/sync/Helper", "com.deepin.sync.Helper", bus ); if (!iface.isValid()) { qWarning() << "Invalid DBus interface:" << bus.lastError().message(); return false; } QDBusReply<bool> reply = iface.call("IsDeveloperMode"); if (!reply.isValid()) { qWarning() << "Query failed:" << reply.error().message(); return false; } return reply.value(); }

调用过程可以分成三步：

1. 连接系统总线QDBusConnection::systemBus()；
2. 创建com.deepin.sync.Helper接口对象；
3. 调用IsDeveloperMode并读取布尔返回值。

使用这种方式时，除了方法返回的开发者模式状态，还需要处理 System Bus 未连接、服务不存在、接口无效以及调用失败等情况。

两种方式的差异

标志文件方式的代码更少，调用过程也比较直接，但会依赖固定的文件路径。

DBus 方式不需要了解状态文件的具体保存形式，不过运行时依赖 System Bus 和对应的系统服务。如果服务没有启动或者接口不可用，就无法得到有效结果。

两种方式可以简单归纳为：

• 已知系统版本和标志文件路径时，可以使用文件判断；
• 希望通过系统服务获取状态时，可以使用 DBus；
• 文件方案要处理路径变化，DBus 方案要处理服务和调用异常；
• 两种方案都建议在无法确认状态时返回false。

对 UOS 拒签原因的推测

下面这部分只是根据现象做的技术推测，并不是 UOS 官方给出的结论。准确原因仍应以签名审核结果或官方反馈为准。

从现象来看，使用QFile::exists()检查开发者模式标志文件时，程序会被识别为存在风险操作，最终导致签名被拒。可能有以下几个原因。

第一，敏感字符串和路径访问可能触发同一类检测规则。

当时的检测反馈截图中命中了developer-mode相关内容。标志文件路径会以字符串常量保存在编译产物中，签名工具可能在静态扫描时识别到该字符串。

同时，QFile::exists()虽然不会读取或修改文件内容，底层仍会查询/var/lib/deepin/developer-mode/下文件的元数据。因此，拒签既可能由敏感字符串触发，也可能与对系统敏感路径的实际访问有关。

第二，检测规则可能更关注访问对象，而不是访问目的。

签名检测通常无法仅凭一次文件存在性判断准确推断业务目的，因此可能采用相对保守的规则：只要程序引用或访问特定系统目录，就将其标记出来，而不会因为操作是只读的就自动放行。

第三，系统可能更希望应用通过服务接口获取状态。

开发者模式可以通过com.deepin.sync.Helper的IsDeveloperMode查询。和直接检查内部文件相比，DBus 接口的调用边界更明确，系统服务也可以统一处理状态读取和权限控制。