企业官网建设流程全解析

• 移动开发
• 文件管理

本指南基于 SD Maid 2/SE 官方隐私政策文档（PRIVACY_POLICY.md），结合项目源码逐项解析其隐私设计：应用如何处理应用安装清单（QUERY_ALL_PACKAGES）、何时使用无障碍服务、MOTD 每日消息与 FOSS 版本更新检查的网络请求路径，以及调试日志的生成与分享流程。读完本文，你将能准确判断该应用各类敏感行为的触发条件、数据流向和用户可控开关，并能依据源码定位验证每一项隐私声明。

SD Maid 2/SE 是一款面向 Android 的深度清理工具，其官方隐私政策明确承诺"不收集、不分享、不出售个人信息"。本文以该文档为骨架，深入到 app/src/main/java/eu/darken/sdmse 与 app/src/foss 的源码实现，把隐私声明中的每一句承诺映射到具体代码行为上，帮助开发者、审核人员与高级用户理解其边界与局限。

隐私原则：数据本地处理与唯一例外

隐私政策的前言（Preamble）部分阐明了项目方的核心立场：

I do not collect, share or sell personal information.

即"不收集、分享或出售个人信息"，其底层隐私原则被描述为"黄金法则"（Golden Rule），并以邮箱support@darken.eu作为问题反馈渠道。

在此基础上，政策给出了一个贯穿全文的总括性承诺：

In general, SD Maid only processes data locally, on your device. One edge case exists: If you record a debug log, the resulting file will contain a detailed log of SD Maids actions.

翻译过来即：SD Maid 通常只在你的设备本地处理数据，唯一例外是调试日志（Debug Log）——当你在设置中主动录制调试日志时，生成的日志文件会包含 SD Maid 各项操作的详细记录，这些记录理论上可能包含敏感信息。

这一"本地处理 + 唯一例外"的总纲，在后续章节中被细化为四个具体主题：应用查询权限、无障碍服务、MOTD 网络请求、更新检查网络请求，以及调试日志。下面逐一拆解。

敏感权限：QUERY_ALL_PACKAGES 的用途清单

QUERY_ALL_PACKAGES（查询所有已安装应用）是 Android 中风险等级较高的权限，允许应用读取设备上已安装应用的清单。该权限已在 AndroidManifest.xml 中声明，隐私政策声明：关于你已安装应用的信息仅在设备本地处理。

从源码结构看，权限的授予提示位于设置流程中，例如 InventorySetupModule.kt 会在API level >= 34时要求该权限（Android 14 及以上的包可见性收紧），而 SetupViewModel.kt 中对该权限的授予结果做静默处理。

隐私政策列出了使用该权限的五个功能模块，均可在 app/src/main/java/eu/darken/sdmse 的对应包中找到实现：

核心要点：该权限的用途全部指向"本地功能实现"，而非数据外传。判断 APK 是否已安装、归类残留文件、统计应用占用，这些都是离线即可完成的本地计算，代码中并未看到将应用清单上传的路径。

无障碍服务：可选、opt-in、可随时关闭

隐私政策对无障碍服务（AccessibilityService）的描述非常克制：

SD Maid contains optional features that utilize Android's AccessibilityService API to automate tedious actions. Usage of the AccessibilityService API is optional, opt-in and can be disabled at any time. SD Maid does not use the AccessibilityService API to collect or send or information.

要点有三：

1. 存在可选功能利用 Android 的无障碍服务 API 来自动化繁琐操作；
2. 该 API 的使用是可选（optional）、主动选择（opt-in）的，且可随时禁用；
3. 无障碍服务 API不用于收集或发送信息。

无障碍服务在清单中声明于 AndroidManifest.xml，对应的自动化模块位于 app-common-automation（68 个 Kotlin 文件，封装自动化任务执行）与 app-common-root。从 DebugTaskModule.kt 可以看到服务配置项（如FLAG_INCLUDE_NOT_IMPORTANT_VIEWS、FLAG_REPORT_VIEW_IDS、FEEDBACK_GENERIC），这些 flags 用于模拟点击等 UI 自动化场景，与"收集信息"无直接关联。

值得留意的是清单中还有一条注释（AndroidManifest.xml）：针对 Android 17+ 检测"高级保护"机制，以便向用户解释无障碍服务为何被系统阻止——这进一步说明该服务仅用于设备本地操作自动化。

MOTD 每日消息：一次指向 GitHub API 的 HTTP GET

隐私政策明确披露，应用内置"Message of the day"（MOTD，每日消息）系统，可在首页展示一次性可关闭的消息，并如实说明其网络行为：

SD Maid sends HTTP GET requests (similar to visiting a link with a web browser) to GitHub's servers to check for new MOTDs. A GitHub account is not required.

即：SD Maid 向 GitHub 服务器发送 HTTP GET 请求以检查新 MOTD，无需 GitHub 账号；检查可选，可在引导流程（onboarding）或设置中关闭。MOTD 数据托管在仓库的 motd 目录下，按foss/gplay × beta/dev组合存放motd-{de,en}.json。

源码层面，这条链路由三个文件构成，可从 MotdRepo.kt 一路追踪到网络层：

1. MotdRepo.kt：仓库层，用combine合并四个信号——刷新触发器、settings.isMotdEnabled（是否启用）、generalSettings.isOnboardingCompleted（引导是否完成）、localeManager.currentLocales（当前语言）。只有引导完成且 MOTD 启用时才会发起请求；拿到结果后还会按minimumVersion/maximumVersion过滤版本范围，并通过dismiss(id)支持一次性关闭。
2. MotdEndpoint.kt：端点上装配 Retrofit，baseUrl指向https://api.github.com。请求路径为repos/d4rken-org/sdmaid-se/contents/{path}，其中：
   • path形如motd/{flavor}/{buildType}（如motd/foss/dev）；
   • branch按构建类型选择：DEV用motd分支，BETA/RELEASE用main分支；
   • 语言选择有回退链：优先-{语言}.json，缺失则回退-en.json，再缺失则取任意.json。
3. MotdApi.kt：Retrofit 接口定义，@GET("repos/d4rken-org/sdmaid-se/contents/{path}")携带@Query("ref")指定分支，再用@GET @Url下载具体 JSON 文件。

隐私影响评估：请求仅携带 flavor、buildType、语言等构建相关参数，属于典型的"拉取远程内容"模式，数据流向是 GitHub → 设备，方向单一；MOTD 是否启用完全由用户控制。政策还指出 GitHub 的隐私政策适用于该请求（原文以链接形式给出，此处不展开外部链接）。

更新检查：FOSS 构建专属的 GitHub Release 查询

隐私政策特别区分了构建变体（build flavor）：

TheFOSSbuild flavor (i.e. not the Google Play version) of SD Maid includes an "update check" mechanism that can show a card on the dashboard if a newer version is available.

即更新检查机制仅存在于 FOSS 构建变体（非 Google Play 版本）。原因从源码可以推断：Google Play 版本由 Play 商店渠道负责更新，无需应用自行检查；而 FOSS 版本面向 F-Droid 等第三方渠道分发，需要自建更新提示。源码上，app/src/foss/java/eu/darken/sdmse/common/updater 提供了FossUpdateChecker，而 app/src/gplay 目录下是GplayUpdateChecker，两者通过各自 flavor 的 UpdaterModule.kt 完成依赖注入。

隐私政策对网络行为同样作了披露：SD Maid 向 GitHub 服务器发送 HTTP 请求以获取"最新发布"信息，无需 GitHub 账号，检查可选，可在引导流程或设置中关闭。

从 FossUpdateChecker.kt 可以还原完整实现细节：

• 端点：经 GithubReleaseCheck.kt 访问https://api.github.com，查询仓库d4rken-org/sdmaid-se的 release 信息；latestRelease()只取非预发布版本，allReleases()用于 Beta 通道。
• 缓存节流：两次检查之间间隔至少 6 小时（UPDATE_CHECK_INTERVAL = Duration.ofHours(6)），间隔内直接使用本地缓存的 release 数据（lastReleaseBeta/lastReleaseProd），避免频繁请求。
• 通道选择：RELEASE 构建默认查 PROD 通道，用户同意 Beta 后查 BETA 通道；BETA/DEV 构建固定查 BETA 通道，见 UpdaterExtensions.kt。
• 版本比较：用语义化版本库解析VERSION_NAME与远端tagName，仅当远端版本更新时才提示。
• F-Droid 默认禁用：isEnabledByDefault()检测安装来源，若安装器属于 F-Droid 及其衍生客户端（如org.fdroid.fdroid、com.machiav3lli.fdroid、com.looker.droidify、com.aurora.store等），更新检查默认关闭——因为 F-Droid 渠道本身承担更新职责，避免重复提示。源码中完整名单见FDROIDS集合。
• 动作落地：startUpdate()打开 APK 下载链接，viewUpdate()打开 changelog 页面，dismissUpdate()记录忽略状态。

调度入口在 UpdateService.kt：combine(isOnboardingCompleted, isUpdateCheckEnabled, updateCheckTrigger)，与 MOTD 类似，引导未完成或用户关闭时不会发起任何请求。首页的提示卡片实现见 UpdateDashboardCard.kt。

调试日志：唯一的数据外发例外路径

隐私政策将调试日志列为本地处理原则的唯一例外，描述如下：

The app has a debug log feature that can be used to assist troubleshooting efforts. This feature creates a log file that contains verbose output of what the app is doing. It is manually triggered by the user through an option in the app settings. The recorded log file can be shared through compatible apps (e.g. your email app) using the system's share dialog. As this log file may contain sensitive information (e.g. details about files or your installed applications) it should only be shared with trusted parties.

翻译要点：

1. 手动触发：日志录制只能由用户在应用设置中手动开启，不存在后台自动录制；
2. 本地生成：生成的是包含应用详细操作的日志文件；
3. 系统分享：文件通过系统分享对话框交给兼容应用（如邮件应用）发送，即"外发"动作由用户主动完成；
4. 敏感警告：日志可能包含文件细节、已安装应用信息等敏感内容，只应分享给可信对象。

实现层面，日志会话由 DebugLogSession.kt 建模，是一个清晰的有限状态机：

• Recording（录制中，日志写入缓存目录/cache/debug/logs或外部目录）；
• Zipping（打包压缩）；
• Finished（完成，产出zipFile与compressedSize）；
• Failed（失败，原因枚举：EMPTY_LOG、MISSING_LOG、CORRUPT_ZIP、ZIP_FAILED）。

会话管理由 DebugLogSessionManager.kt、日志压缩由 DebugLogZipper.kt 负责，录制界面与逻辑分别在 RecorderScreen.kt 与 RecorderViewModel.kt。此外，LogHistoryRecorder.kt 承担日志历史记录，供应用内的日志查看器使用。

边界小结：录制、压缩、存储全部在设备本地完成；跨设备传播的唯一途径是用户主动通过系统分享菜单选择目标应用。这也是政策中唯一承认的"信息可能离开设备"的场景。

用户可控性：引导流程与设置开关的完整闭环

隐私政策反复强调各项网络功能的"可选性"，其在代码中的落地位置集中在引导（onboarding）环节与设置界面：

• OnboardingPrivacyViewModel.kt：暴露toggleMotd()（写入motdSettings.isMotdEnabled）与toggleUpdateCheck()（写入generalSettings.isUpdateCheckEnabled），并汇总isUpdateCheckSupported状态——用户在首次引导时即可决定是否开启这两项网络功能。
• OnboardingPrivacyScreen.kt：对应的 Compose UI，在引导页中渲染 MOTD 与更新检查的开关条目。
• 设置界面（GeneralSettingsViewModel.kt）允许用户在引导之后随时重新开关。

结合前文可知，这两个开关会直接流入 MotdRepo.kt 与 UpdateService.kt 的combine逻辑——开关关闭后，网络请求根本不会发出。这是一个"声明 → 设置 → 请求门控"的完整闭环，也是评估该应用隐私设计时最值得验证的代码路径。

总结：一份可被源码验证的隐私声明

从 PRIVACY_POLICY.md 出发对照源码，可以得出如下核实结论：

1. 本地优先：QUERY_ALL_PACKAGES、无障碍服务等敏感能力的全部用途都落在本地功能实现上（残留识别、存储统计、应用管理、UI 自动化），源码中未发现上传应用清单或无障碍事件流的路径；
2. 网络行为透明且受限：应用仅有的两类出站请求——MOTD 与 FOSS 更新检查——都指向 GitHub API，且都满足"引导完成 + 用户开启"的双重门控，并带有 404 容错、6 小时节流、语言回退与版本过滤等工程化约束；
3. 唯一例外被明确标注：调试日志是政策承认的唯一天然携带敏感信息的数据载体，但其生命周期完全由用户手动触发，外发必须经系统分享对话框；
4. 验证路径清晰：读者可沿 MotdEndpoint.kt、FossUpdateChecker.kt、DebugLogSession.kt 逐层核对每一项承诺，这是审计该类应用隐私设计时的标准做法。

需要指出的是，本文所有结论均以当前仓库快照为准：涉及版本判断、构建类型分支选择、默认开关策略等行为，随仓库演进可能变化，读者应以其所持版本的源码与 PRIVACY_POLICY.md 为准。若对某一具体行为存疑，官方建议直接邮件联系项目方（support@darken.eu）。

• 移动开发
• 文件管理