Skip to content

Add Settings.Secure.HIDE_NAVIGATION_HANDLE setting - #440

Open
0xALUCARD wants to merge 3 commits into
GrapheneOS:17from
0xALUCARD:hide-nav-hint
Open

Add Settings.Secure.HIDE_NAVIGATION_HANDLE setting#440
0xALUCARD wants to merge 3 commits into
GrapheneOS:17from
0xALUCARD:hide-nav-hint

Conversation

@0xALUCARD

@0xALUCARD 0xALUCARD commented Sep 5, 2026

Copy link
Copy Markdown

Adds a new secure setting, hide_navigation_handle, controlling whether the navigation handle in gesture navigation mode (the hint pill on the bottom of the screen) is drawn (default) or hidden.

This feature has been referenced as acceptable by the GrapheneOS team, by @thestinger in #2760, it has been implemented in this PR as instructed: "[It] should not remove the reserved space in apps without edge-to-edge support to avoid breaking app compatibility. It should only hide the navigation zone hint."

This feature is implemented in 3 repos:

  • Settings app: adds the user-facing toggle (link)
  • Launcher3: consumes the setting and hides the handle (link)
image

Comment on lines +12509 to +12513
/**
* Whether the navigation hint pill is hidden in gesture navigation mode.
* @hide
*/
public static final String HIDE_NAVIGATION_HANDLE = "hide_navigation_handle";

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GrapheneOS-specific settings should have an entry in https://github.com/GrapheneOS/platform_frameworks_base/blob/17/core/java/android/ext/settings/ExtSettings.java and all settings reads/writes should be through that ExtSettings class. This static String should also have the appropriate @Protected annotation

See the other GrapheneOS commits on this file for reference: https://github.com/0xALUCARD/platform_frameworks_base/commits/17/core/java/android/provider/Settings.java

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although for Launcher3, it's probably fine to just use the key for the settings cache

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please clarify your 2nd reply, should I migrate the branch to the ExtSettings paradigm that you described?

@inthewaves inthewaves Sep 7, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For Launcher3 it seems fine to just keep it as is to use the preexisting SettingsCache

For Settings, there's already ExtSettings-specific infrastructure, e.g. see GrapheneOS/platform_packages_apps_Settings@e32073a. BoolSettingPrefController can just be extended with override for the gesture availability

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've pushed this update. Note that I set the @Protected annotation of the key to restrictReads = false so that launcher3 could still read it as you said, since the KnownSystemPackage enum does not contain a value for launcher3.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can add an entry for Launcher3 to KnownSystemPackage (it is a known system package after all)

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call, I have done this now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants