This differential implements JNI layer over NotificationsCryptoModule, so that native Android Java code can decrypt encrypted notifications
Details
- Apply the following diff to CommNotificationsHandler.java: https://gist.github.com/marcinwasowicz/b90db78cb695e658ca3e2b1e1fd85c75
- Build the app and log in.
- Get cookie_id of the notifications olm session created for currently logged in android user (query db).
- Apply this diff to send.js file in keyserver (push directory). Remember to replace cookieID with data pulled from db in step 2.: https://gist.github.com/marcinwasowicz/873ec48a8b332c1e2324771d52e11ee0
- Send notification. Examine logs in Android Studio.
Example:
2023-05-18 18:03:35.098 12796-12842 COMM app.comm.android W Encrypted sample: AwoguiD1LCV7sLJPq6lHWT5MARaNb3HEd+G/pIQzVyMqnw8QHiJAXQ0fCykph234akrN1RKigZzuDvfx4v++So74g7DoDCRLK+lMdtw06WMXuaGAAXVOOY2Ii63zLClgz7XE+me1qlWw766wN7al 2023-05-18 18:03:35.098 12796-12842 COMM app.comm.android W Decrypted sample: This is data that is sent encrypted over the wire.
Diff Detail
- Repository
- rCOMM Comm
- Branch
- marcin/eng-3026
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
native/android/app/src/cpp/NotificationsCryptoModuleJNIHelper.cpp | ||
---|---|---|
29 | Please add missing newlines. |
I think the wording here may be a bit confusing. In my experience, 'cancel' typically means close the alert, and there's another option like 'confirm' or something that will mean you're ok with discarding changes.
Here it seems like 'cancel' means we're ok with discarding changes. Not sure if it's just me though (cc @ted)