feat(pushNotifications): Adding infrastructure for Android push notifications #19576
+3,075
−115
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit adds the status-keycard-qt submodule and updates the build configuration to support it. In this initial version the `status-keycard-qt` option can be enabled by using the `USE_STATUS_KEYCARD_QT` flag. - desktop: `USE_STATUS_KEYCARD_QT` will enable/disable the qt implementation. By default the go version is used - ios: `USE_STATUS_KEYCARD_QT` will enable/disable the qt implementation - android: the qt implementation is enabled by default
- src/app/modules/main/wallet_section/send_new/module.nim Verify if both password and pin are empty before emitting the `authenticationCancelled` signal - handle card disconnect/reconnect when the user input is needed (enter pin, puk etc) - treat keycard message with empty error as successful - src/app_service/service/keycard/service.nim - avoid modifying the json container with itself. We're currently iterating the container and modifying the service member - leading to a freeze.
This is a fix for the mobile platforms that will show a drawer when the keycard is needed. We'll need to avoid showing the drawer every time at app start.
The keycard channel events will inform the app of the channel state (waiting for keycard, reading, error, idle). This will be used on mobile platforms to control a drawer that informs the user when it's required to tap the keycard.
…keycard interactions Adding a `KeycardChannelDrawer` that's guiding the user whenever the keycard is needed. On IOS the system drawer is used
…ications This commit connects the native code with status-go push notification infrastructure. It handles: - Firebase token generation - App config - Android permissions - Forwarding the token to status-go
Member
Jenkins Builds
|
Member
✔️ status-app/prs/linux/x86_64/tests-nim/PR-19576#1 🔹 ~12 min 🔹 3843c63 🔹 📦 tests/nim package |
alexjba
force-pushed
the
fix/keycard-nfc-4
branch
from
b1b5809 to
1daf137
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does the PR do
Iterates: #19532 #18403
This commit connects the native code with status-go push notification infrastructure. It handles:
What's not included here:
How does it do it
In terms of Firebase config I've created a new project here https://console.firebase.google.com/u/0/project/status-react-app/overview. It's using the status-app app id. This firebase project config is checked-in now as a json config.
StatusQ will now expose the c APIs needed to generate the firebase token and to request the notification permissions for Android. nim_status_client.nim will initialize the push notifications (generating the token at start-up). After login we'll register the token in status-go.
Affected areas
Android push notifications
App start-up
Architecture compliance
My PR is consistent with this document: QML Architecture Guidelines
Screencapture of the functionality
Screen_Recording_20251212_123209_Status2.mp4
Impact on end user
The end user will receive notifications if permissions are allowed.
How to test
Open the app, allow for permissions. Close the app or place it in background and make sure to receive a 1-1 message or contact request
Risk
Exposed Firebase API. It seems to be considered here the first time we've published it https://github.com/status-im/status-legacy/pull/21983/changes#r2005830459. No idea though if this is a real risk or not.