Skip to content

Hide message notification content by default when the app is locked#6902

Open
bxdxnn wants to merge 2 commits into
element-hq:developfrom
bxdxnn:feat/hide-notif-content
Open

Hide message notification content by default when the app is locked#6902
bxdxnn wants to merge 2 commits into
element-hq:developfrom
bxdxnn:feat/hide-notif-content

Conversation

@bxdxnn
Copy link
Copy Markdown
Contributor

@bxdxnn bxdxnn commented May 27, 2026

Content

New setting (enabled by default, not shown when the app PIN code is not setup) that makes the app use the fallback notification (the "You have (count) new messages" notification) when the app is closed (i.e. locked).

Motivation and context

ATM you can still read and reply from the notifications on new messages even when the app is locked, which almost defeats the entire purpose of having an app PIN lock.

Screenshots / GIFs

Tests

Setup the "Screen lock" PIN code

  • Have the option enabled
    • Have the app opened
      • You should receive notifications normally
    • Have the app closed
      • You should receive the fallback notification
  • Have the option disabled
    • You should receive notifications normally

Tested devices

  • Physical
  • Emulator
  • OS version(s): 16

Checklist

  • This PR was made with the help of AI:
    • Yes. In this case, please request a review by Copilot.
    • No.
  • Changes have been tested on an Android device or Android emulator with API 24
  • UI change has been tested on both light and dark themes
  • Accessibility has been taken into account. See https://github.com/element-hq/element-x-android/blob/develop/CONTRIBUTING.md#accessibility
  • Pull request is based on the develop branch
  • Pull request title will be used in the release note, it clearly defines what will change for the user
  • Pull request includes screenshots or videos if containing UI changes
  • You've made a self review of your PR

@bxdxnn bxdxnn requested a review from a team as a code owner May 27, 2026 20:22
@bxdxnn bxdxnn requested review from jmartinesp and removed request for a team May 27, 2026 20:22
@github-actions
Copy link
Copy Markdown
Contributor

Thank you for your contribution! Here are a few things to check in the PR to ensure it's reviewed as quickly as possible:

  • If your pull request adds a feature or modifies the UI, this should have an equivalent pull request in the Element X iOS repo unless it only affects an Android-only behaviour or is behind a disabled feature flag, since we need parity in both clients to consider a feature done. It will also need to be approved by our product and design teams before being merged, so it's usually a good idea to discuss the changes in a Github issue first and then start working on them once the approach has been validated.
  • Your branch should be based on origin/develop, at least when it was created.
  • The title of the PR will be used for release notes, so it needs to describe the change visible to the user.
  • The test pass locally running ./gradlew test.
  • The code quality check suite pass locally running ./gradlew runQualityChecks.
  • If you modified anything related to the UI, including previews, you'll have to run the Record screenshots GH action in your forked repo: that will generate compatible new screenshots. However, given Github Actions limitations, it will prevent the CI from running temporarily, until you upload a new commit after that one. To do so, just pull the latest changes and push an empty commit.

@github-actions github-actions Bot added the Z-Community-PR Issue is solved by a community member's PR label May 27, 2026
@bmarty
Copy link
Copy Markdown
Member

bmarty commented May 28, 2026

FTR we have this settings in Element Classic (but not defaulting to hiding message content in notification):

image

@jmartinesp
Copy link
Copy Markdown
Member

jmartinesp commented May 28, 2026

@mxandreas another PR to check once you're back 😅 .

We were also discussing this behaviour earlier and a valid point was whether we want to link the 2 options and only have this hiding of notification content option available if there's a PIN code, or if it should always be present (disabled by default) and the user can change it at any time.

@jmartinesp jmartinesp added the X-Needs-Product Issue needs input from Product team label May 28, 2026
@mxandreas
Copy link
Copy Markdown
Member

ATM you can still read and reply from the notifications on new messages even when the app is locked, which almost defeats the entire purpose of having an app PIN lock.

I am curious about the use cases or real life situations for this one. I understand the phone is unlocked (otherwise one could hide content in notifications, right), then a new message arrives and then you would not want its content to be shown? A few examples would be appreciated.

@jmartinesp
Copy link
Copy Markdown
Member

jmartinesp commented Jun 1, 2026

I think when this was asked before it was for the case where you have notifications as heads up (so, displaying above everything else even if you don't open the notification drawer) and someone is looking at your phone/recording it somehow.

So you want to know there is new content in the app, you just don't want to display the content unless you unlock the app.

@mxandreas
Copy link
Copy Markdown
Member

and someone is looking at your phone/recording it somehow

I understand that this can theoretically happen - you show your phone to someone and because of bad timing some sensitive message appears but for me this is an edge case. So, unless there is a very clear scenario in which it happens regularly and there is no workaround, I'd not spend time on it.

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

Labels

X-Needs-Product Issue needs input from Product team Z-Community-PR Issue is solved by a community member's PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants