* Add floating date indicator while scrolling the timeline (#6433)
* Add `FeatureFlags.FloatingDateBadge`. This enables displaying the floating date badge in the timeline as you scroll.
* Don't display the floating badge if the timeline isn't reversed. Otherwise, this will affect talkback users and break the existing navigation
* Use `TimelineItem.formattedDate()` to get the date to display. Always try finding the closest one (usually it will be just the 1st one we try).
* Align designs with iOS. Also fix shadows in fade animation by adding some paddings.
* Update screenshots
---------
Co-authored-by: Gianluca Iavicoli <gianluca.iavicoli04@gmail.com>
Co-authored-by: ElementBot <android@element.io>
Implement a `customDetectVerticalDragGestures` that matches the original `detectVerticalDragGestures` expect we conditionally consume the initial DOWN event in compose to decide whether we need to drag the bottom sheet or scroll inside the Android `EditText`
* Fix crash when using `View.hideKeyboardAndAwaitAnimation`
Remove the `View.OnApplyWindowInsetsListener` used in modern Android versions to detect if the insets changed after they do the first time: this is a single use operation and the listener will be called every time the insets change
Also, replace `Mutex` with `CompletableDeferred` so it doesn't matter if it's called several times, we only care about the first one.
* Don't try to hide the keyboard if it's already hidden. Also, add a 1s timeout in case everything goes wrong and we somehow never complete the future.
* 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.
* Fix long messages not being clickable
As @bmarty found out, `clip = true` causes the click event to be ignored in some cases. Since we have the shape we want to draw and we're using a custom `onDraw` modifier anyway to cut-out part of the path, we can just draw everything using the modifier and avoid using `clip = true`.
This seems to fix the issue.
* Fix clipping of images or other items that cover the bubble
* Fix borders being displayed for contents
* Extract the layer drawing logic into `drawInLayer` to simplify the inlined code. Remove redundant code, those changes are now in the `drawInLayer` block
* Workaround for lint issue: it seems like detekt can't properly detect usages in content receivers
* Update screenshots
---------
Co-authored-by: ElementBot <android@element.io>
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.
* Fix `TransactionTooLargeExceptions` caused by Appyx
After a long debugging session, we discovered the code Appyx uses to clear the saved state of nodes that have been removed is not working because of a race condition, causing this saved state to grow indefinitely.
To fix it, we need to wait until the node has been disposed, which will call `SaveableStateHolder.removeState` once, removing the associated `SaveableStateRegistry`, and *then* call `removeState` again when we detect the node has been removed from the navigation graph.
Since these classes and APIs are private in Appyx, we had to copy and modify and use these copies.
* Remove ktlint checks on `SafeChildrenTransitionScope.kt`
* Don't count the new code for coverage
`AnchoredDraggable.requireOffset` was called before it was populated when displaying `CreateDmConfirmationBottomSheet`, because the keyboard and the bottom sheet were causing conflicting animations related to the insets.
Hiding the keyboard before displaying the bottom sheet seems to fix the issue, and `skipPartiallyExpanded` results in a better UX (and also worked around the issue by itself).
* fix(deps): update dependency org.matrix.rustcomponents:sdk-android to v26.03.18
* Fix API breaks
* Add compatibility with rustls (#6367)
A new `rustls-platform-verifier-android` library has to be added to the project, it'll be called from Rust to get access to the certificates on Android.
Originally, this was supposed to be added as a local maven repo pointing to the rust crate that publishes the AAR, but that's just plain terrible (more details [here](https://github.com/rustls/rustls-platform-verifier#android).
Instead, what we can do is use a script that uses `cargo-download` to download the latest crate or a specified version, unzip it and add the `aar` file to the `:libraries:matrix:impl` module.
* Try fixing Sonar with local AAR files
* Remove `UserCertificatesProvider`: this is no longer needed after integrating rustls
* Added some docs for rustls and its `platform-verifier` library
* Upgrade SDK to `26.03.19`: this version contains a workaround that allows the app to use the same TLS verifier as before, fixing the Let's Encrypt issues we saw with some homeservers (like element.io)
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Jorge Martín <jorgem@element.io>
* 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
