SystemUI-下拉去掉后去掉用户切换-去掉电源按键中的紧急呼叫

原创于 2025-12-03 17:46:26 发布 · 615 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#SystemUI去除紧急呼叫 #去除紧急呼叫 #去除用户切换 #去除用户选择 #SystemUI

Android 系统专栏收录该内容

5 篇文章

订阅专栏

提示：SystemUI-下拉去掉后去掉用户切换-去掉电源按键中的紧急呼叫

文章目录

需求
一、参考资料
二、修改文件-实现方案
三、实际效果
四、源码分析
五、知识点扩展-Compose
总结

需求

如下产品顶部下拉，展示SystemUI下拉框，去掉用户切换UI 和 Power 按键中的紧急呼叫UI

分析：这里面其实就有两个需求了

去除用户管理、切换UI
去除紧急呼叫UI

在这里插入图片描述

一、参考资料

去掉用户切换选择按钮UI 相关参考：这里暂无直接相关文章参考，但是整理之前的笔记和文章，方便查看思路。
实际思路就是阅读源码，知道如何找UI、搞清除SystemUI 基本架构是第一步。 Android12 SystemUI QS面板新增截屏功能

假若以前对SystemUI有所了解，可以略过；无了解建议首先看看SystemUI架构、组成、UI 相关内容，搞清楚基本组成和架构。以下仅供参考
Android12 SystemUI QS面板新增截屏功能
 SystemUI 专栏

在这里插入图片描述

Power按键弹框相关参考：
长按power弹出的弹框有紧急呼叫按钮需要去掉这是之前自己整理过想通需求的案例，实践过，有详细的修改说明。

二、修改文件-实现方案

涉及到文件修改


去用户切换、用户管理UI 修改
\frameworks\base\packages\SystemUI\compose\features\src\com\android\systemui\qs\footer\ui\compose\FooterActions.kt
\frameworks\base\packages\SystemUI\src\com\android\systemui\qs\footer\ui\viewmodel\FooterActionsViewModel.kt

去 紧急呼叫功能UI
frameworks\base\packages\SystemUI\src\com\android\systemui\globalactions\GlobalActionsDialogLite.java
frameworks/base/core/res/res/values/config.xml

修改方案

1、去除USER相关-FooterActions.kt

去除user 相关内容
在这里插入图片描述

2、去除USER相关-FooterActionsViewModel.kt

去除user 相关内容：frameworks\base\packages\SystemUI\src\com\android\systemui\globalactions\GlobalActionsDialogLite.java

在这里插入图片描述

3、去除紧急呼叫添加UI-GlobalActionsDialogLite.java

去除加载紧急呼叫UI的添加项：frameworks\base\packages\SystemUI\src\com\android\systemui\globalactions\GlobalActionsDialogLite.java
在这里插入图片描述

4、去除紧急呼叫配置

去除系统中默认的配置：frameworks/base/core/res/res/values/config.xml

在这里插入图片描述

三、实际效果

在这里插入图片描述

四、源码分析

这里只分析去除用户切换UI 的源码分析；对于去除紧急呼叫的需求，强烈参考长按power弹出的弹框有紧急呼叫按钮需要去掉，之前单独篇章分析过。

找UI布局-qs_footer_actions

**初步分析：**首先把UI布局边界打开，看底部几个按钮位置，并试图上下滑动界面，感觉上来说它不是之前一直调试的QS 面板布局里面的布局文件，像是整体布局底部UI文件。
在这里插入图片描述
查看布局：qs_panel.xml

所以，基本锁定到了布局位置：androidx.compose.ui.platform.ComposeView ，居然用的是最新的UI方式：Compose

QSImpl-查看布局加载逻辑-组件加载逻辑

位置：/frameworks/base/packages/SystemUI/src/com/android/systemui/qs/QSImpl.java
在这里插入图片描述
找到如下代码：

  private void bindFooterActionsView(View root) {
        mFooterActionsView = root.findViewById(R.id.qs_footer_actions);
        QSUtils.setFooterActionsViewContent(mFooterActionsView,
                mQSFooterActionsViewModel, mListeningAndVisibilityLifecycleOwner);
    }

QSUtils-工具类创建Compose UI界面

位置：/frameworks/base/packages/SystemUI/src/com/android/systemui/qs/QSUtils.kt

    @JvmStatic
    fun setFooterActionsViewContent(
        view: ComposeView,
        viewModel: FooterActionsViewModel,
        qsVisibilityLifecycleOwner: LifecycleOwner,
    ) {
        view.setContent { PlatformTheme { FooterActions(viewModel, qsVisibilityLifecycleOwner) } }
    }

这里看到 view.setContent 方法，不就是Compose 标准方法来添加子布局嘛。

FooterActions-声明是UI布局创建

这个就是Compose 语法，来声明式创建UI子布局地方，那么在这个布局中去除用户的创建不就可以了嘛。
在这里插入图片描述

如下，创建三个按钮的地方：根据实际需要，直接去掉。
在这里插入图片描述

FooterActionsViewModel - ViewModel 中去除用户

如上 FooterActions 创建UI布局中，如下代码：


/** The Quick Settings footer actions row. */
@Composable
fun FooterActions(
    viewModel: FooterActionsViewModel,
    qsVisibilityLifecycleOwner: LifecycleOwner,
    modifier: Modifier = Modifier,
) {

那么就搞清楚这个 FooterActionsViewModel 是做什么的，这个跟Compose 架构及Android架构有关，View-MODE 都要看一看的

如下看类定义：所以在这个类中去掉用户相关的 userSwitcher
在这里插入图片描述

FooterActionsButtonViewModel - 底部按钮ViewModel

这个和本需求无关，但是比较有意思，如下看类定义：有兴趣可以自行查看代码，多看看。

/**
 * A ViewModel for a simple footer actions button. This is used for the user switcher, settings and
 * power buttons.
 */
data class FooterActionsButtonViewModel(
    val id: Int,
    val icon: Icon,
    @ColorInt val iconTint: Int?,
    @AttrRes val backgroundColor: Int,
    val onClick: (Expandable) -> Unit,
)

五、知识点扩展-Compose

这个本身是应用相关的谷歌推荐的编程方式，包括现在的跨平台开发Flutter、鸿蒙应用开发都是这个思想。这个在这里简单理解下，实际开发需要实际实战。对于系统工程是简单了解，如果需要修改UI和定制UI，如当前这个需求模块上修改等，那就必须掌握这个技能了。

这里简单对比一下：其它知识点不做讨论

在 Android 开发中，ComposeView 是一个传统的 Android View 子类，其主要作用是在基于传统 View 的界面中，作为承载 Compose UI 的“容器”。简单来说，它是连接声明式 UI（Compose）和命令式 UI（传统 View）的桥梁。

下面这张表格清晰地列出了两者的核心关系、区别和各自的优劣势。

维度	ComposeView (桥梁/容器)	普通 View (传统 UI 组件)
本质与角色	一个特殊的 ViewGroup，作为 Compose UI 的容器和宿主。	构成传统 UI 界面的基础组件（如 TextView, Button）或容器（如 LinearLayout）。
编程范式	内部使用声明式范式（通过 setContent 设置 Composable 函数）。	命令式范式，需要手动查找视图并调用方法（如 setText(), setVisibility()）来更新。
层级嵌套	嵌套层级极浅。一个 ComposeView 内部通常只有一个 AndroidComposeView，所有 Compose 组件都在此内部绘制，无需担心传统 View 的深层嵌套性能问题	嵌套层级深。复杂的界面会导致 ViewGroup 层层嵌套，可能引发多次测量和布局，影响性能
主要用途	1. 在现有 View 项目中集成 Compose 界面（如在 XML 布局中插入）。2. 作为 Compose 在 Android 窗口系统中的底层实现入口	构建和维护所有传统的 Android 界面。
优点	- 无缝混合开发：是渐进式迁移到 Compose 的关键，允许在旧项目中局部使用 Compose。- 性能潜力：其承载的 Compose UI 具备智能重组、单次测量等优化潜力	- 成熟稳定：拥有完善的 API、丰富的第三方库和深厚的开发者基础。- 完全掌控：对视图的生命周期和绘制过程有精细的控制力，适合极端定制化场景。
缺点	- 仅是容器：其优势完全取决于内部编写的 Compose 代码质量。如果使用不当（如在 View 树的非生命周期感知处嵌入），可能引发问题。- 过渡性技术：在纯 Compose 应用中不会直接使用。	- 开发效率低：需要编写大量样板代码（如 findViewById），且状态与UI同步容易出错。- 性能陷阱：深层嵌套布局、手动更新遗漏易导致性能问题和 bug