企业官网建设流程全解析

InstallerX Revived 完整指南：现代 Android 包安装器的功能、授权与构建

【免费下载链接】InstallerX-RevivedMore Expressive InstallerX !项目地址: https://gitcode.com/GitHub_Trending/ins/InstallerX-Revived

InstallerX Revived 是一个社区维护的现代 Android 包安装器，定位为原 InstallerX 的延续项目，旨在用更清晰的界面、更广的包格式支持、可配置的安装配置文件以及基于 Shizuku、Root、Dhizuku 或系统安装器模式的特权工作流，替代受限的原厂（Stock）与 OEM 安装器。阅读本篇后，你将掌握该项目支持的包格式与安装流程、四种授权方式的能力边界、安装/卸载配置文件的全部可调项、两种发布变体（Online/Offline）的差异，以及从环境准备到产物生成的完整构建流程。

项目定位与设计理念

InstallerX Revived 的目标并非简单的“换一个安装界面”，而是完整接管 Android 的包安装与卸载链路。正如其德语 README 所描述，它要替代的是受限的原厂或 OEM 安装器，并通过以下手段达成：

• 更清晰的界面：基于 Material 3 Expressive 与 Miuix 两套组件体系；
• 更广的包格式支持：不止 APK，还包括 APKS、APKM、XAPK 及 ZIP 压缩包内的 APK；
• 可配置的安装配置文件：为不同场景定义安装模式、授权方式、元数据与安全策略；
• 特权工作流：通过 Root、Shizuku、Dhizuku 或系统安装器模式获得超越普通应用的安装能力。

关于项目的工程形态，可从仓库结构直接印证：主应用位于 app 模块，特权进程与隐藏 API 适配分别由 app-process 与 hidden-api 模块承担，另有 baselineprofile 模块负责启动基准配置生成。

核心功能总览

包格式与解析链路

InstallerX Revived 支持的包格式包括：APK、APKS、APKM、XAPK、ZIP 压缩包内的 APK 文件，以及 APK 批量安装。对应地，仓库内置了一套完整的解析与预处理管线：

• ApkParser.kt：统一解析入口；
• FileTypeDetector.kt：识别文件真实类型，区分单 APK 与多包容器；
• 解析策略按格式分派：SingleApkStrategy.kt、ApksStrategy.kt、XApkStrategy.kt、ApkmStrategy.kt、MultiApkZipStrategy.kt 等；
• UnifiedContainerAnalyser.kt：将多包容器统一为可安装的拆分包集合。

在解析之前，PackagePreprocessor.kt 还会执行哈希校验等预处理，而 SplitNameUtil.kt 负责拆分包名称的规范化，为后续 SelectOptimalSplitsUseCase.kt 的智能分片选择提供基础。

安装流程模式

根据不同场景，InstallerX Revived 提供以下安装流程：

这些流程在领域层被建模为明确的安装状态与动作类型，见 DomainInstallState.kt 与 InstallActionType.kt。

现代界面与系统集成

界面层面同时提供Material 3 Expressive与Miuix两套风格，支持深色模式、动态取色、扩展调色板、系统图标包、彩色对话框、标准通知、Live Activity，以及在受支持的小米设备上的 HyperOS 风格 Island 通知。界面实现位于 ui 目录，其中 miuix 风格页面位于 ui/page/miuix。

系统集成方面，InstallerX Revived 可从首页状态卡片锁定为默认安装器，可与 LSPosed 模块（如 InxLocker）配合使用，高级用户也可以将其作为系统安装器的替代品安装。

四种授权方式（Authorizer）解析

授权方式决定了一次安装/卸载操作能以多大权限执行。README 列出了四种方式，其能力边界如下：

• Root：可执行全部特权操作；但由于app_process冷启动开销，速度可能较慢。
• Shizuku：根据激活方式获得 shell 级或 root 级权限，通常比直接 Root 更快。
• Dhizuku：基于 DevicePolicyManager，可执行锁定默认安装器、安装应用等操作，但其他特权任务受限。
• None：完全受系统限制；但当 InstallerX Revived 以系统安装器身份运行时，仍可静默安装。

在源码层面，授权方式被建模为 Authorization.kt 中的Authorizer枚举：

enum class Authorizer(val value: String, @field:StringRes val displayNameRes: Int) { Global("global", ...), None("none", ...), Root("root", ...), Shizuku("shizuku", ...), Dhizuku("dhizuku", ...), Customize("customize", ...); }

注意Global表示“跟随全局设置”，Customize允许指定自定义授权器。实际执行则由各实现类承担，位于 data/engine/executor/appinstaller 目录，包括ShizukuAppInstallerRepoImpl、ProcessAppInstallerRepoImpl、DhizukuAppInstallerRepoImpl、SystemAppInstallerRepoImpl、NoneAppInstallerRepoImpl等。

关于 Shizuku 权限的细粒度，ShizukuMode.kt 通过 UID 区分了三种模式：ROOT（UID 0）、SHELL（UID 2000）与NONE，这印证了 README 中“根据激活方式获得 shell 或 root 能力”的描述。

配置文件（Profile）：安装与卸载策略的可编程中心

配置文件定义了安装/卸载请求如何被处理，是 InstallerX Revived 最核心的可配置面。README 列举的关键维度包括：安装模式、授权器覆盖、安装者（Installer）/请求者（Requester）元数据、目标用户、DexOpt、自动删除、分片选择、黑名单策略与签名门禁。

在源码中，这一整套配置被建模为 ConfigModel.kt 中的ConfigModel数据类，字段与 README 维度一一对应：

此外，ConfigModel还携带安装原因（InstallReason：UNKNOWN/POLICY/DEVICE_RESTORE/DEVICE_SETUP/USER，与PackageManager.INSTALL_REASON_*对齐）与包来源（PackageSource：UNSPECIFIED/OTHER/STORE/LOCAL_FILE/DOWNLOADED_FILE）等与系统 API 同步的枚举，见 InstallModes.kt。

值得注意的细节：ConfigModel的伴生对象中预置了XiaomiDefault，其installerMode = InstallerMode.Custom、installer = "com.android.shell"——这正是 README 中“HyperOS 上以com.android.shell作为默认兼容安装器包”的源码依据，且generateOptimalDefault()会根据当前设备厂商（Manufacturer.kt）在小米设备上自动采用该默认值。

配置的解析与作用域匹配由 ConfigResolver.kt 完成（提供resolve(activity)与resolveForPackage(packageName)等入口），其领域接口见 ConfigRepository.kt，持久化则由 InstallerRoom.kt 及 app/schemas 下的迁移 schema 支撑。

安全控制

除了上述签名门禁与黑名单，README 还强调了以下安全机制：

• 黑名单（Sperrlisten）：支持按包名（PackageName）与 SharedUID 双重维度拉黑，相关用例见 ManagePackageListUseCase.kt 与 ManageSharedUidListUseCase.kt；
• 签名分析：签名不匹配与未知签名策略门禁，配合安装前的权限预览与安装标志展示，实现 PackageSignatureAnalyzer.kt、PendingApkSignatureAnalyzer.kt 等分析组件；
• 一次性智能建议：对选中的拦截情形给出一次性（不再重复打扰）的智能处理建议。

支持的 Android 版本

“受限支持”意味着 InstallerX Revived 可以运行，但部分功能可能因 Android 框架、OEM 或授权器限制而缺失或行为不同。这一分级在实际安装策略检查中也有对应体现，参见 PlatformInstallPolicyChecker.kt。

发布变体：Online 与 Offline

InstallerX Revived 以两种变体发布：

• Online：支持直接 APK 下载链接与在线更新功能；网络权限仅用于安装相关功能。
• Offline：不申请任何网络权限；仅在线功能会显示明确错误提示。

两者的包名、版本号与签名相同，因此会互相覆盖，不能并行安装。这一设计在 app/build.gradle.kts 中有直接实现：通过connectivity维度定义online/offline两个 flavor，分别注入INTERNET_ACCESS_ENABLED为true/false的BuildConfig字段；对应的网络模块实现分别位于 src/online 与 src/offline。同时，level维度定义了Unstable（默认，versionName 带 git hash）、Preview与Stable三个构建等级，通过BUILD_LEVEL区分。

从源码构建：环境与步骤

InstallerX Revived 是一个标准的 Android Gradle 项目（settings.gradle.kts中声明了:app、:app-process、:hidden-api、:baselineprofile四个模块）。

构建前提

• JDK 25，且正确配置JAVA_HOME；
• 安装了所需 platform 与 build-tools 的 Android SDK / Android Studio；
• 用于 snapshot 依赖miuix的 GitHub Packages 凭据。

GitHub Packages 认证

即使miuix是公开包，GitHub Packages 也要求认证。需要在全局 Gradle 属性文件中配置 GitHub 用户名与具有read:packages作用域的 classic personal access token：

• Linux / macOS：~/.gradle/gradle.properties
• Windows：%USERPROFILE%\.gradle\gradle.properties

gpr.user=YOUR_GITHUB_USERNAME gpr.key=YOUR_PERSONAL_ACCESS_TOKEN

切勿将这些凭据提交到本仓库。认证的实际解析逻辑位于 settings.gradle.kts 的dependencyResolutionManagement中：它优先读取gpr.user/gpr.key属性，也支持回退到GITHUB_ACTOR/GITHUB_TOKEN环境变量，并以命名仓库GitHubPackagesMiuix注入maven.pkg.github.com/compose-miuix-ui/miuix。

构建命令

本地 Debug 构建（Unstable 等级）：

./gradlew assembleOnlineUnstableDebug assembleOfflineUnstableDebug

PR 风格测试构建（使用独立的 applicationId，避免与正式发布冲突）：

./gradlew assembleOnlinePreviewDebug assembleOfflinePreviewDebug -PAPP_ID="com.rosan.installer.x.revived.test"

APP_ID属性的处理见 app/build.gradle.kts 第 36 行：applicationId = project.findProperty("APP_ID") as String? ?: "com.rosan.installer.x.revived"。versionCode取自 git 提交计数，versionName由构建插件基于基础版本号生成；若自定义keystore.properties或对应环境变量（KEYSTORE_FILE、KEYSTORE_PASSWORD、KEY_ALIAS、KEY_PASSWORD）提供了签名信息，Debug 与 Release 构建都会自动改用自定义签名。项目根目录的 gradle.properties 还默认开启了并行构建、构建缓存与配置缓存，便于 CI 复用产物。

常见问题与故障排查

无法将 InstallerX 锁定为默认安装器

部分 OEM 系统对默认包安装器的控制非常严格。可尝试从首页状态卡片进入默认安装器页面，在系统设置中锁定；若 ROM 仍然阻止，则需借助 LSPosed 模块（如 InxLocker）。

HyperOS 提示系统应用安装需要有效安装器

这是 OEM 安全限制。InstallerX Revived 可通过配置文件声明安装者元数据，在 HyperOS 上默认使用com.android.shell作为兼容安装器包（对应源码中的XiaomiDefault配置，见 ConfigModel.kt）。该工作流需要 Shizuku 或 Root，Dhizuku 权限不足。

通知安装进度卡住

部分 ROM 会激进地限制后台服务。若通知安装停滞，请将 InstallerX 设置为不受限制的后台/电池使用。InstallerX 会在安装任务完成后不久自动清理其前台服务。

如何替换系统安装器

这是一个仅供高级用户尝试的高风险流程。简要步骤为：使用 Core Patch 覆写 APK、刷入匹配的模块，或将匹配的包集成进super分区/ROM 构建。刷机或打包前务必核对目标 ROM 的包名、挂载路径与权限文件。该主题的详细说明见 docs 目录下各语言 README 指向的文档体系。

本地化、许可证与致谢

• 本地化：项目通过 Weblate 协作翻译，仓库中已包含 values-zh-rCN、values-ja、values-de 等二十余个语言目录；
• 许可证：InstallerX Revived 以 GNU General Public License v3 发布（见 LICENSE）。基于其工作成果时，须遵守你所使用的具体源码版本的开源许可条款；
• 致谢：项目实现参考或借用了 iamr0s/InstallerX、KernelSU、Shizuku、InstallWithOptions、PackageInstaller、miuix 等项目，对应代码在 docs/README.md 中列出。

参与贡献

如需报告可复现的缺陷或提出具体功能请求，请先阅读 CONTRIBUTING.md（注意其内部链接指向仓库根目录，原 README 中为../CONTRIBUTING.md），以便按要求提供日志与复现细节。报告问题时，建议尽可能使用最新 Alpha 或 CI 构建复现，因为 Stable 中的问题可能已被修复。

【免费下载链接】InstallerX-RevivedMore Expressive InstallerX !项目地址: https://gitcode.com/GitHub_Trending/ins/InstallerX-Revived