* Notification settings: pick custom sounds for messages and call ringtones (#6702)
* Feature: add notification sound settings for messages and calls
* Add sound not available banner, accessibility checks
* Fix build and Konsist convention violations
- libraries:preferences:api now uses io.element.android-compose-library
so NotificationSound's @Immutable annotation can resolve, matching the
pattern in libraries:matrix:api.
- Rename SoundUnavailableBannerStateProvider to
NotificationSoundUnavailableStateProvider so the class name contains
the parameter type as required by KonsistClassNameTest.
* Suppress LargeClass on RoomListPresenterTest
The three new sound-unavailable tests pushed the class past Detekt's
default LargeClass threshold. Matches the suppression pattern already
used on five presenter test classes under features/messages/impl/test.
* NotificationSettingsView: guard ringtone-picker launchers in inspection mode
rememberLauncherForActivityResult requires a LocalActivityResultRegistryOwner,
which Paparazzi-driven preview snapshot tests don't provide, causing
NotificationSettingsViewPreview to throw IllegalStateException for every
preview parameter. Extract the click handlers into a helper that returns a
no-op when LocalInspectionMode.current is true; the runtime path is unchanged.
* Handle unresolved notification sounds mid session
* Quality checks, refactor mid session error ui
* Suppress detekt LargeClass on NotificationSettingsPresenterTest
* Remove notification sound resilience layer, replace with file copy
* Reselect element sound option, code cleanup
* Add element fade notification sound option
* Fix new file headers
* Revert to flowOf(Unit) for announcement service
* Add ringtone picker dialog to match message selector
* Update strings in conjunction with ios
* Update test to reflect new string
* Sync strings.
* Update screenshots
* Fix test
* Remove not properly located translations.
This will be fixed in the next String sync.
* Fix test on CI
---------
Co-authored-by: Jenna Vassar <jenna.vassar@toptal.com>
Co-authored-by: ElementBot <android@element.io>
This happens when building a `ShortcutInfoCompat` in `DefaultNotificationConversationService.onSendMessage` when the provided room name is not null but it's empty.
* Rename `PushHandlingWakeLock` to `FetchPushForegroundServiceManager`. Move the start/stop logic from `FetchPushForegroundService.Companion` to it.
* Add more tests using Robolectric.
* Remove `FeatureFlags.SyncNotificationsWithWorkManager` and associated code: this should have been removed in one of the previous refactors, since we don't have the 2 ways to sync notifications anymore, everything uses the `WorkManager`
---------
Co-authored-by: Benoit Marty <benoit@matrix.org>
* Start the `FetchPushForegroundService ` in foreground ASAP. This is a first step to mitigate `ForegroundServiceDidNotStartInTimeException` being thrown.
* Don't stop the service immediately if it's running but not in foreground. Try waiting up to 5s for it to be in foreground.
If notifications for a device are disabled when there is no connection with the HS, the push registration will still exist, so the device can still receive push notifications.
In that cases, we were running into an issue where the wakelock for push notifications was started immediately after receiving a push but was never stopped and it ran for 3 minutes until its timeout, keeping the device awake for no reason.
This patch changes `DefaultPushHandler` so if we don't need the wakelock it returns `false` and we can stop the wakelock early.
* Create `PushHandlingWakeLock` to start a foreground service:
When receiving a push and scheduling the notification fetching, several problems can happen:
1. Some async operation is waiting for a timeout and it takes way longer than that to finish (i.e. timeout of 10s but it took 30s to advance).
2. The same, but when starting new coroutines. I've seen the time between scheduling a coroutine and it running sometimes take up to 1 minute.
3. Notification fetching can be scheduled immediately, but it can take a while to actually run because the OS understands the app is now in Doze.
Having a wakelock that runs as soon as the push handling starts fixes these: it continues the previous wakelock held by either Firebase or the UnifiedPush distributor.
* Acquire the wakelock as soon as we received the pushes in both receivers
* Also release the wakelock ahead of time if possible
* Add `isNetworkBlocked` and `isInAirGappedEnvironment` to `NetworkMonitor`.
* Improve the DI of `SyncPendingNotificationsRequestBuilder` to simplify its usage.
* Only update `isInAirGappedEnvironment` in `DefaultNetworkManager` if the current build is an enterprise one.
* Add network constraints to `DefaultSyncPendingNotificationsRequestBuilder` based on the air-gapped status.
* Add a feature flag to disable the new check, in case it doesn't work as expected.
* Create `PushRequest` in push history DB: this will be used to store requests for push notifications, either pending or completed ones.
* Rename `WorkManagerRequest` to `WorkManagerRequestBuilder`: make its `build` method return a list of `WorkManagerRequestWrapper`, which can be used to enqueue normal or unique workers.
* Rename `PerformDatabaseVacuumRequestBuilder` and adapt it to the new API.
* Adjust other components using `WorkManagerRequest`.
* Replace `SyncNotificationWorkManagerRequestBuilder` with `SyncPendingNotificationsRequestBuilder` and `FetchNotificationsWorker` with `FetchPendingNotificationsWorker`: this new pair of request builder and worker allow enqueuing requests for a session id and, once the worker runs, retrieve all the pending request data and use it to fetch the associated events. This simplifies quite a bit how this data had to be passed or grouped, since it's no longer necessary to do so
* Add new methods to `PushHistoryService` to modify the `PushDatabase`:
- insertOrUpdatePushRequest
- insertOrUpdatePushRequests
- getPendingPushRequests
- removeOldPushRequests
* Make `PushHandler` just handle incoming pushes: those will be inserted into the pending push request table in DB, then handled by the new worker. Once the process finished, a new `NotificationResultProcessor` will handle the results and what needs to be done with them (call ringing, displaying notifications, etc.)
* Add `requestType` optional parameter to `WorkManagerScheduler.cancel` so we can decide to only cancel some kinds of requests.
* Add migration to remove existing work manager requests for fetching notifications, since the previous worker class no longer exists.
Note that I did not manage to have the method `onRegistrationFailed` invoked. If the network is not available for instance, unregistering the previous pusher will fail first.
* Separate thread notifications into their own notifications when the feature flag is enabled.
Otherwise, set the `threadId` to null so it'll behave as usual. It's done this way to avoid having to inject `FeatureFlagService` in several places.
* Add permalink navigation to threads from notifications, focusing on the latest event in the list of messages of the notification tapped
* Fix redactions in threads
* Clear notifications for a thread when visiting it
* Fix opening a thread happening twice, first because of the `openThreadId` value, then because of the `focusedEventId` one
* Make opening a room through a notification also focus on the latest event
* Add helper `NotificationCreator.messageTag` function
* Remove unused `ROOM_CALL_NOTIFICATION_ID`: `FOREGROUND_SERVICE_NOTIFICATION_ID`+ `ForegroundServiceType` is used instead
* Simplify `DefaultDeepLinkCreator`
* Make sure the main timeline focuses on the thread root id too when navigating to a thread
* Handle "Mark as read" action for thread notification, using `timeline.markAsRead`
* Log failures to mark rooms as read using the notification action
---------
Co-authored-by: Benoit Marty <benoit@matrix.org>
* Initial implementation of notification sync using `WorkManager`
* Use custom `MetroWorkerFactory` to allow assisted injection in WorkManager Workers
* Add tests for `FetchNotificationWorker`. Create `FakeNotificationResolverQueue` to help testing.
* Add more tests, fix Konsist checks
* Add tests for `SyncNotificationWorkManagerRequest`
* Simplify `FakeNotificationResolverQueue`
* Report shortcut usage for outgoing messages
This patch adds support for creating and pushing dynamic
long-lived shortcuts for outgoing messages. This together
with an existing reference to the roomId used by the
shortcuts as an identifer allows conversations to be
prioritized.
See https://developer.android.com/training/sharing/direct-share-targets#report-usage-outgoing
* Simplify how to get the other user in a DM room
* Add initial avatar icons to shortcuts
* Remove room shortcuts when they're no longer joined
* Try using API 33 for the new tests. They worked locally with API 30, so it's weird the CI asks for a higher API version.
* Add observers for the pin code and session logout states. With this we can prevent new shortcuts from being created and remove existing ones when needed.
* Wrap all calls to `ShortcutManagerCompat` with `runCatchingExceptions` to avoid crashes
* Make `DefaultNotificationConversationService` a singleton.
---------
Co-authored-by: networkException <git@nwex.de>
Co-authored-by: ElementBot <android@element.io>
* Add adb tools to help with doze mode and app standby
* Add info about the device state when an error occurs in push.
* Keep more events in the DB.
* Push history: add confirmation dialog when resetting the data
* Push history: add a filter to see only the errors
* Update screenshots
* Push history: print out invalid/ignored data received.
* Increase log level for push, to make such log more visible.
It also appears that sometimes Timber.d are not present in the rageshakes.
* Log priority
* Do not include device state for invalid/ignored event.
* Fix tests.
* Fix format issue.
* Fix mistake in code blocks and do not filter when not necessary.
* Improve formatting and add missing unit test.
* Reduce nesting of blocks.
---------
Co-authored-by: ElementBot <android@element.io>
* Introduce PushHistoryService to store data about the received push
Add a push database.
* Update screenshots
* Improve preview.
* Update screenshots
* Add missing test.
* Add test for PushHistoryView
* Fix configuration issue.
Was: w: /libraries/troubleshoot/impl/src/test/kotlin/io/element/android/libraries/troubleshoot/impl/history/PushHistoryPresenterTest.kt:35:27 Cannot access class 'PushProvider' in the expression type. While it may work, this case indicates a configuration mistake and can lead to avoidable compilation errors, so it may be forbidden soon. Check your module classpath for missing or conflicting dependencies.
---------
Co-authored-by: ElementBot <android@element.io>
2 replace all actions have been performed:
- "SPDX-License-Identifier: AGPL-3.0-only" to "SPDX-License-Identifier: AGPL-3.0-only OR LicenseRef-Element-Commercial"
- "Please see LICENSE in the repository root for full details." to "Please see LICENSE files in the repository root for full details."
- Add `ActiveCallManager` to handle incoming and ongoing calls.
- Add ringing call notifications with full screen intents and missed call ones as part of the 'conversation' notifications.
---------
Co-authored-by: ElementBot <benoitm+elementbot@element.io>
Benoit Marty