* Tentative fix for `ForegroundServiceStartNotAllowedException`
When failing to start the service in foreground, don't crash. This is a helper to speed up the scheduling by keeping the CPU awake, not a critical part that should succeed
* Simplify `DefaultPushHandlingWakeLock`
It seems like restarting the service from background won't work in some cases, so don't try it.
* Try handling `ForegroundServiceStartNotAllowedException` better
The docs mention starting a foreground service when the app is on background is allowed when FCM receives a high priority notification, so we don't do it if the priority is not high.
Also, we handle the case where starting the foreground service fails so it doesn't crash the app.
* 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.
* Update metro to v0.11.2
* Bind push tests to the right scope .Add a comment so we don't forget to do it for future ones.
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Jorge Martín <jorgem@element.io>
- Added `MediaSource.safeUrl` property replacing `withCleanUrl` method.
- Made `url` private so it can't be used externally.
- Reverted code in `CoilMediaFetcher`
- Also add tests
* Update metro to v0.11.0
* Fix `@AssistedInject` usages
Now the injected variables in the factories must match the names in the constructors
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Jorge Martín <jorgem@element.io>
* Add `NetworkMonitor.isNetworkBlocked()`, use it to check if Doze prevented us from loading notifications
* Only check if network is blocked after checking if we have a network available, otherwise it's always `true`
* Extract `NetworkBlockedChecker` to handle deprecations more carefully
* Add extra analytics for notification performance
Add technical spans to track how long a notification fetching work request takes to run, then how long it takes to actually fetch the events for the notifications
* Remove `withContext(io)` for `FetchNotificationsWorker`
The default `Dispatchers.Default` dispatcher used should be good enough and more performant
* Add network check span
