1. 为什么要在Android 14平板上折腾导航栏和状态栏如果你手头有一台Android 14的平板不管是用来刷剧、记笔记还是轻度办公你可能会发现一个挺有意思的现象平板的界面逻辑和手机不太一样。最明显的就是屏幕底部那一排“返回、主页、最近任务”的虚拟按键——在手机上我们叫它“导航栏”Navigation Bar通常老老实实地待在屏幕最下方但在平板上它摇身一变成了一个更接近桌面电脑任务栏的“Taskbar”而且图标位置也常常靠右排列而不是居中。这种设计初衷是为了更好地利用平板的大屏幕空间让多任务操作更高效。但问题来了有时候我们就是想要一块“干干净净”的屏幕。比如在沉浸式阅读、看视频、或者玩游戏的时候底部的Taskbar和顶部的状态栏显示时间、电量、信号的那一条就显得有点碍眼破坏了那种全屏的沉浸感。虽然Android系统本身有“沉浸模式”但它的触发和退出往往依赖于应用自身用户没法自己随心所欲地控制。所以一个能由用户主动控制的“显示/隐藏”开关就显得非常实用了。这不仅仅是“隐藏”那么简单它背后涉及到Android系统UI框架的深度定制。你需要理解在平板模式下SystemUI负责系统状态栏、导航栏等和Launcher3负责桌面和Taskbar是如何分工协作的然后才能精准地“告诉”它们什么时候该出现什么时候该消失。我自己在给设备做定制开发时就经常遇到这个需求用户反馈说想要更纯净的视觉体验而原生系统并没有提供这么一个直接的开关。今天我就把自己踩过坑、验证过的完整方案分享出来从设置界面加开关到Launcher3和SystemUI的联动修改手把手带你实现这个功能。2. 动手前的准备理解平板模式下的UI架构在开始敲代码之前我们得先搞清楚Android 14平板模式下导航栏和状态栏到底是谁在管。这能帮你避免改错地方白费功夫。2.1 手机模式 vs. 平板模式核心差异在手机或小屏设备上导航栏是SystemUI模块的“亲儿子”由NavigationBarController等类直接管理代码路径主要在frameworks/base/packages/SystemUI/下面。它是一个全局的、系统级的组件。而到了平板或大屏设备上事情就变了。Android为了更好的大屏交互引入了“Taskbar”的概念。这个Taskbar的创建和管理权移交给了Launcher3应用也就是你的桌面。它的代码在packages/apps/Launcher3/里。你可以把Taskbar理解为一个更高级的、集成在Launcher中的导航栏它除了有导航键还能显示最近应用、常驻应用图标等。系统判断是否进入平板模式的一个关键依据是屏幕的“最小宽度”smallest width是否大于600dp。这个逻辑在Utilities.isLargeScreen()这类方法里随处可见。2.2 我们的目标建立一条控制链路明白了谁管谁我们的改造思路就清晰了。我们需要建立一条从用户操作到UI响应的完整控制链用户界面层在系统的“设置-显示”菜单里增加两个开关选项“显示导航栏”和“显示状态栏”。控制逻辑层当用户点击开关时不仅要更新系统设置Settings.Global的值还要发送一个广播Broadcast把“显示”或“隐藏”的指令传递出去。执行层 - Launcher3接收指令或读取设置决定是否创建和显示Taskbar。执行层 - SystemUI接收指令或读取设置动态地控制导航栏NavigationBarView和状态栏StatusBarView的可见性。这样我们就实现了“一处设置两处生效”的动态控制。下面我们就分步拆解看看具体怎么改。3. 第一步在系统设置中新增控制开关所有交互的起点都在设置里。我们要在“显示”设置页面加入两个SwitchPreference开关选项。3.1 添加字符串资源和布局首先需要定义开关显示的文字。在Settings应用的资源文件里添加中英文字符串。打开文件packages/apps/Settings/res/values/strings.xmlstring nameshow_navigateShow navigation bar/string string nameshow_statusbarShow status bar/string同时在中文翻译文件res/values-zh-rCN/strings.xml中也添加string nameshow_navigate显示导航栏/string string nameshow_statusbar显示状态栏/string接着我们需要把这两个开关放到“显示”设置页面的布局里。找到显示设置的布局文件res/xml/display_settings.xml在合适的位置比如“外观”分类下添加PreferenceCategory android:titlestring/category_name_appearance !-- 其他原有设置项... -- SwitchPreference android:keyshow_navigate android:titlestring/show_navigate settings:controllercom.android.settings.display.ShowNavigatePreferenceController / SwitchPreference android:keyshow_statusbar android:titlestring/show_statusbar settings:controllercom.android.settings.display.ShowStatusBarPreferenceController / /PreferenceCategory这里的关键是settings:controller属性它指定了处理这个开关逻辑的控制器类。3.2 实现开关控制器PreferenceController这是整个设置功能的核心。控制器负责管理开关的状态开/关并在用户操作时执行相应的动作。我们需要创建两个控制器类。以ShowNavigatePreferenceController为例我来详细解释一下关键代码public class ShowNavigatePreferenceController extends TogglePreferenceController { // ... 省略部分代码 ... Override public boolean isChecked() { // 读取全局设置判断当前是否是“显示”状态 return (Settings.Global.getInt(mContext.getContentResolver(), Settings.Global.SHOW_NAVIGATE, 0) 1); } Override public boolean setChecked(boolean isChecked) { // 用户切换开关时调用 Intent i new Intent(com.fuzhou.statusbar.SHOW_OR_HIDE); if(isChecked) { i.putExtra(mode, 1); // 模式1显示导航栏 } else { i.putExtra(mode, 2); // 模式2隐藏导航栏 } // 发送广播通知SystemUI mContext.sendBroadcast(i); // 将用户选择持久化到Settings.Global数据库 Settings.Global.putInt(mContext.getContentResolver(), Settings.Global.SHOW_NAVIGATE, isChecked ? 1 : 0); return true; } // 这个方法决定这个开关是否应该显示在设置中。 // 例如我们可以让它只在平板设备上显示。 Override public int getAvailabilityStatus() { // 这里可以加入更精确的判断例如检查设备是否为大屏 return AVAILABLE; } }ShowStatusBarPreferenceController的实现几乎一样只是广播中传递的mode值不同3表示显示状态栏4表示隐藏以及操作的设置项是Settings.Global.SHOW_STATUSBAR。3.3 在DisplaySettings中注册控制器创建好控制器后需要在DisplaySettings.java中声明它们这样系统才知道去管理这两个新的设置项。在DisplaySettings类中添加private static final String KEY_SHOW_NAVIGATE show_navigate; private static final String KEY_SHOW_STATUSBAR show_statusbar; Override public int getPreferenceScreenResId() { return R.xml.display_settings; } Override protected ListAbstractPreferenceController createPreferenceControllers(Context context) { // ... 构建控制器列表 ... controllers.add(new ShowNavigatePreferenceController(context, KEY_SHOW_NAVIGATE)); controllers.add(new ShowStatusBarPreferenceController(context, KEY_SHOW_STATUSBAR)); // ... return controllers; }做完这一步编译并刷入系统后你应该就能在“设置 - 显示”里看到这两个新开关了。不过现在点了还没用因为我们只完成了“发号施令”的部分还没人“听令行事”。4. 第二步让Launcher3的Taskbar听指挥在平板模式下导航栏Taskbar是由Launcher3创建和管理的。所以我们需要修改Launcher3的代码让它根据我们的系统设置来决定是否创建Taskbar。4.1 找到控制Taskbar创建的关键点经过分析TaskbarManager类中的isTaskbarPresent方法是决定Taskbar是否存在的关键。它返回trueTaskbar就会被创建返回false则不会创建。原始代码可能类似于private boolean isTaskbarPresent(DeviceProfile deviceProfile) { return FLAG_HIDE_NAVBAR_WINDOW || deviceProfile.isTaskbarPresent; }这里的逻辑是如果系统有隐藏导航栏的标志或者当前设备配置文件支持Taskbar就创建。4.2 修改逻辑接入我们的控制我们的目标是当用户关闭了“显示导航栏”的开关就让这个方法返回false。修改如下private boolean isTaskbarPresent(DeviceProfile deviceProfile) { // 读取全局设置如果设置为0不显示则直接返回false boolean showNavigate Settings.Global.getInt(mContext.getContentResolver(), Settings.Global.SHOW_NAVIGATE, 1) 1; if (!showNavigate) { return false; } // 否则执行原有的判断逻辑 return FLAG_HIDE_NAVBAR_WINDOW || deviceProfile.isTaskbarPresent; }4.3 处理动态切换的挑战这里有一个细节需要注意isTaskbarPresent方法可能在Launcher启动时或配置变化时被调用。如果用户在系统运行中通过设置开关关闭了导航栏Launcher3如何能即时知道并做出反应呢有两种思路监听广播在Launcher3中也注册一个广播接收器监听我们之前发出的com.fuzhou.statusbar.SHOW_OR_HIDE广播针对mode 1和2收到后重新初始化Taskbar相关组件。这种方式响应及时但改动点较多需要小心处理生命周期。依赖重启或配置变更更简单稳定的做法是让修改在下次Launcher重启或屏幕旋转等配置变更时生效。对于大多数用户场景关闭导航栏可能不是一个需要秒级响应的操作这种方式完全可接受。我们上面的修改就是这种思路它保证了开关状态在Launcher下一次创建Taskbar时如下次启动或从最近任务返回一定会被尊重。在实际项目中我通常先采用第二种简单方案如果产品有强实时性要求再考虑补充广播监听。这能有效控制代码复杂度和潜在风险。5. 第三步在SystemUI中动态控制导航栏和状态栏这是整个方案的“重头戏”也是效果最直观的部分。我们需要在SystemUI中接收广播并实时控制导航栏和状态栏的显示与隐藏。5.1 在CentralSurfacesImpl中注册广播接收器CentralSurfacesImpl是SystemUI的核心入口类之一状态栏和导航栏的视图都在这里初始化和管理。我们在这里注册广播接收器非常合适。首先在CentralSurfacesImpl类中添加一个广播接收器成员变量private final BroadcastReceiver mStatusShowHide new BroadcastReceiver() { Override public void onReceive(Context context, Intent intent) { String action intent.getAction(); if (com.fuzhou.statusbar.SHOW_OR_HIDE.equals(action)) { final int mode intent.getIntExtra(mode, 1); switch (mode) { case 1: // 显示导航栏 if (getNavigationBarView() ! null) { getNavigationBarView().getRootView().setVisibility(View.VISIBLE); } break; case 2: // 隐藏导航栏 if (getNavigationBarView() ! null) { getNavigationBarView().getRootView().setVisibility(View.GONE); } break; case 3: // 显示状态栏 if (mStatusBarView ! null) { mStatusBarView.getRootView().setVisibility(View.VISIBLE); } // 关键恢复通知面板下拉功能 mCommandQueue.mEnablePanel true; break; case 4: // 隐藏状态栏 if (mStatusBarView ! null) { mStatusBarView.getRootView().setVisibility(View.GONE); } // 关键禁用通知面板下拉功能 mCommandQueue.mEnablePanel false; break; } } } };然后在start()方法中注册这个接收器Override public void start() { // ... 原有初始化代码 ... createAndAddWindows(result); // 注册我们的广播接收器 IntentFilter statusFilter new IntentFilter(); statusFilter.addAction(com.fuzhou.statusbar.SHOW_OR_HIDE); mBroadcastDispatcher.registerReceiver(mStatusShowHide, statusFilter); // ... 后续代码 ... }5.2 修改CommandQueue以持久化状态栏面板控制仅仅隐藏状态栏的视图是不够的。在Android SystemUI中状态栏的“下拉通知面板”功能是由CommandQueue的panelsEnabled()方法控制的。如果只隐藏视图用户从屏幕顶部下拉可能依然能拉出通知面板这就不够彻底。我们需要修改CommandQueue类增加一个标志位来记录我们的控制状态并让panelsEnabled()方法参考这个标志位。首先在CommandQueue类中添加一个公共变量public Boolean mEnablePanel true; // 默认启用面板然后修改其构造函数从系统设置中初始化这个值public CommandQueue(Context context, ...) { // ... 原有代码 ... mEnablePanel Settings.Global.getInt(context.getContentResolver(), Settings.Global.SHOW_STATUSBAR, 1) 1; }最后修改panelsEnabled()方法public boolean panelsEnabled() { // 注释掉原有的复杂判断直接使用我们的控制标志 // final int disabled1 getDisabled1(mDisplayTracker.getDefaultDisplayId()); // final int disabled2 getDisabled2(mDisplayTracker.getDefaultDisplayId()); // return (disabled1 StatusBarManager.DISABLE_EXPAND) 0 // (disabled2 StatusBarManager.DISABLE2_NOTIFICATION_SHADE) 0; return mEnablePanel; }这样当广播接收器将mEnablePanel设置为false时状态栏不仅视图隐藏其交互功能也被完全禁用了。5.3 处理导航栏的特殊情况平板模式的判断你可能已经注意到我们控制导航栏视图的代码getNavigationBarView()在纯平板模式下可能返回null因为平板默认使用Launcher3的Taskbar。我们之前的修改已经通过Launcher3关闭了Taskbar的创建。那么getNavigationBarView()何时不为空呢这涉及到系统对“大屏”的判断。在SystemUI的共享工具类Utilities.java中有一个isLargeScreen()方法它根据屏幕最小宽度判断是否为大屏平板。为了让我们的导航栏控制逻辑在平板上也能生效即让SystemUI去管理一个传统的导航栏而不是交给Launcher的Taskbar我们可能需要临时“欺骗”一下系统。找到packages/SystemUI/shared/src/com/android/systemui/shared/recents/utilities/Utilities.java中的isLargeScreen方法public static boolean isLargeScreen(Context context) { // ... 计算逻辑 ... float smallestWidth dpiFromPx(Math.min(bounds.width(), bounds.height()), densityDpi); return smallestWidth TABLET_MIN_DPS; // TABLET_MIN_DPS通常是600 }我们可以将其强制返回false让系统认为这不是一个大屏设备从而启用传统的SystemUI导航栏管理逻辑。public static boolean isLargeScreen(Context context) { // 为了兼容我们的动态控制方案暂时强制返回false让SystemUI接管导航栏 // return smallestWidth TABLET_MIN_DPS; return false; }请注意这是一个比较“硬核”的修改它会改变系统的默认行为。在实际产品中需要更精细地评估或许可以增加一个条件判断只在我们的开关关闭时才干预此逻辑避免影响其他依赖此判断的功能。这里为了清晰演示核心思路采用了直接修改的方式。6. 第四步固化设置与系统集成为了让我们的开关设置能在系统重启后依然生效并且成为系统设置的一部分我们需要做两件事定义全局设置键并为其提供默认值。6.1 在SettingsProvider中定义新键首先需要在Android框架的Settings.Global表中定义两个新的键Key。修改frameworks/base/core/java/android/provider/Settings.java文件public final class Settings { public static final class Global { // ... 其他已有的键 ... SuppressLint(NoSettingsProvider) public static final String SHOW_STATUSBAR show_statusbar; SuppressLint(NoSettingsProvider) public static final String SHOW_NAVIGATE show_navigate; } }同时需要更新API列表文件core/api/current.txt添加这两个新字段。6.2 为设置提供默认值然后我们需要在SettingsProvider系统设置数据库提供者中为这两个新键设置默认值。修改packages/SettingsProvider/res/values/defaults.xmlresources bool namedef_show_statusbartrue/bool !-- 默认显示状态栏 -- bool namedef_show_navigatetrue/bool !-- 默认显示导航栏 -- !-- ... 其他默认值 ... -- /resources接着修改packages/SettingsProvider/src/com/android/providers/settings/DatabaseHelper.java在初始化数据库时插入默认值private void loadGlobalSettings(SQLiteDatabase db) { // ... 原有代码 ... stmt db.compileStatement(INSERT OR IGNORE INTO global(name,value) VALUES(?,?);); // 插入我们的新设置 loadBooleanSetting(stmt, Settings.Global.SHOW_NAVIGATE, R.bool.def_show_navigate); loadBooleanSetting(stmt, Settings.Global.SHOW_STATUSBAR, R.bool.def_show_statusbar); // ... 后续代码 ... }完成这一步后我们的开关设置就成为了系统全局设置的一部分会随着系统设置一起被备份和恢复重启后也不会丢失。7. 测试、调试与可能遇到的坑代码修改完成后编译一个系统镜像并刷入到你的Android 14平板设备或模拟器进行测试。测试流程应该是进入“设置 - 显示”找到新增的两个开关。关闭“显示导航栏”开关。观察底部Taskbar是否消失可能需要回到桌面或触发一下Launcher重绘。同时观察是否出现了传统的三键导航栏如果isLargeScreen被修改了的话。关闭“显示状态栏”开关。观察顶部状态栏是否立即隐藏并且从顶部下拉是否无法再拉出通知面板。分别重新打开两个开关确认UI元素能正确恢复显示和功能。重启设备检查开关状态是否保持UI状态是否正确应用。在这个过程中你可能会遇到一些坑广播权限问题我们使用的sendBroadcast是普通广播如果系统有严格的安全策略可能需要使用sendBroadcastWithIntent或指定权限。确保广播能顺利到达SystemUI。UI刷新时机隐藏/显示视图的代码setVisibility(View.GONE/VISIBLE)是立即生效的。但如果视图正在执行动画或者被其他系统状态如沉浸模式覆盖可能会产生冲突。需要确保我们的操作在正确的UI线程和时机执行。多用户支持Settings.Global是设备全局设置所有用户共享。如果你的设备需要支持多用户并且希望每个用户有自己的偏好则需要考虑使用Settings.Secure并修改广播和读取逻辑加入用户ID标识。与系统沉浸模式的冲突当应用自己进入沉浸模式如全屏视频播放时系统会自动隐藏状态栏和导航栏。我们的手动开关可能会与这个行为冲突。一个更完善的方案是监听系统沉浸模式状态在应用退出沉浸模式时再根据我们的开关设置来恢复UI这需要更复杂的状态管理。实现这样一个系统级的功能定制就像在给一个正在奔跑的机器人做手术需要你对它的骨骼框架和神经系统消息传递有清晰的了解。每一次修改都要小心验证确保不会引起其他功能的“瘫痪”。但当你看到开关拨动界面随之变化的那个瞬间那种对系统深度掌控的成就感绝对是驱动我们不断折腾下去的最大乐趣。希望这份详细的指南能帮你少走弯路顺利实现你想要的大屏UI自由。如果在实践中遇到新的问题不妨多看看AOSP源码中相关的生命周期和状态管理总能找到线索。