* 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>
* Initial threads support: parse `ThreadSummary`.
Replace several `isThreaded` values with `EventThreadInfo`, which contains the info about the event either being the root of a thread or part of it.
* Add `Threaded` timeline mode
* Add a `liveTimeline` parameter to `TimelineController`'s constructor. This way we can customise which timeline will be used as the 'live' one. Also add `@LiveTimeline` DI qualifier for the actual live timeline of the room.
* Create `ThreadedMessagesNode`. Allow opening a thread in a separate screen.
* Add the callbacks for the list menu actions - even if they're the wrong ones and will send the data to the room instead
* Send attachments and location in threads
* Fix polls in threads, add support for sending voice messages in threads
* Display thread summaries only when the feature flag is enabled
* Use 'Reply' instead of 'Reply in thread' when in threaded timeline mode
* Remove incorrect usage of `Timeline` in `MessageComposerPresenter`. This led to replies to threaded events not appearing as actual replies.
---------
Co-authored-by: ElementBot <android@element.io>
* Update dependency org.matrix.rustcomponents:sdk-android to v25.8.18
* Fix broken API changes:
- The send queue usage is now mandatory.
- The media upload progress now comes back in the send queue state (this still hasn't been applied to the UI in the timeline).
* Update screenshots
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Jorge Martín <jorgem@element.io>
Co-authored-by: ElementBot <android@element.io>
* Provide calculated server names when opening a room from another, based on the most frequently used domain names in the user ids for the users in the room.
This helps when following permalinks or navigating to the successor room of a tombstoned one. Previously, the `/summary` endpoint was failing because no server names were used in the `via` parameters.
* Add `VideoCompressorPreset` enum
This represents the different compression presets used for processing videos before uploading them
* Add `VideoCompressorHelper` util class to calculate the scaled output size of the video given an input size and its optimal bitrate
Also add `MediaOptimizationConfig` which will be used to decide how to apply compression in `MediaPreProcessor`
* Add `RustMatrixClient.getMaxFileUploadSize()` function and `MaxUploadSizeProvider` so we can import only this functionality into other components
* Try preloading the max file upload size the first time we get network connectivity - it's a best effort
This should help ensure we'll have this value available later, even if we still need to load it asynchronously.
* Split the `compressMedia` preference into `compressImages` and `compressMediaPreset`
* Modify the media processing parts to use the new classes and utils
* Add `MediaOptimizationSelectorPresenter`, which will retrieve the compression values and the max file upload size, also estimating the compressed video file sizes if needed.
* Add a feature flag to allow selecting the media upload quality per upload
* Integrate the previous changes with the attachments preview screen
Add strings from localazy too.
* Adapt the rest of the app calls to upload media to using the media optimization configs
* Allow modifying the default compression values in advanced settings, based on the feature flag value
* Pass the `fileSize` in `MediaUploadInfo` too, to be able to check it against the `maxUploadSize`
* Update screenshots
---------
Co-authored-by: ElementBot <android@element.io>
* Move `ChangeRoles*` classes to their own module so they can be shared
* Hook the change roles screen to the leave room action, add confirmation dialogs
* Use enum instead of sealed interface for `ChangeRoomMemberRolesListType`
* Try to improve communications between nodes
* refactor (leave room) : makes sure to expose only necessary code from api module
* Add `:libraries:previewutils` module to share some test fixtures used for UI previews
* Update screenshots
---------
Co-authored-by: ElementBot <android@element.io>
Co-authored-by: ganfra <francoisg@matrix.org>
* Stop sending call notifications manually: the Element Call widget can now assume responsibility for sending them when you start a call.
* Upgrade SDK version to `v25.8.5`, fix API breaks
* Upgrade Element Call embedded to `v0.14.1`
* Fix tests and lint issues
* Add `RoomListEntriesDynamicFilterKind.NonSpace` to avoid displaying spaces in the room list
---------
Co-authored-by: Robin <robin@robin.town>
* Replace `RoomMember.Role.CREATOR` with `RoomMember.Role.Owner` - Make `RoomMember.Role` a sealed interface instead
* Adapt room member role mapping to include the power level to distinguish between admins and owners
* Use new `RoomMember.Role` sealed interface through the app
* Change how `MembersByRole` groups members to add owners to the admins section
* Adapt the `ChangeRoles` screen to the new roles:
- Owners can't modify other owner's roles.
- They can modify the roles of any other user, without confirmation.
* Adapt 'roles and permissions' screen:
- Owners can't demote themselves.
- The admin count also counts owners.
* Add more tests and screenshots
* Add owners to its own section in the 'change roles' screen
* Update screenshots
---------
Co-authored-by: ElementBot <android@element.io>
* Update dependency org.matrix.rustcomponents:sdk-android to v25.7.23
* Adapt to SDK changes:
- Add 'creator' role, adapt existing logic to it.
- Remove `ReplyParameters`, replace with `EventId` where possible.
- Fix changes in OIDC auth methods.
- Add more join rules.
* Make sure both creators and users with power level >= 150 are displayed as 'owners' in the room member list.
* Don't close the roles and permissions screen if the user is a creator
* Use `MediaPreviewValue.DEFAULT` for `MediaPreviewConfig.DEFAULT` too
* Improve APIs around checking roles and power levels:
- Ensure `RoomInfo.RoomPowerLevels.users` can't be directly used to check power levels since it can't check the power levels for creators.
- Add a few helper functions to handle actions that relied on the previous `users` property, and docs to explain their usages.
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Jorge Martín <jorgem@element.io>
Make sure we distinguish between notification events that were filtered out and those that couldn't be resolved.
---
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Jorge Martín <jorgem@element.io>
Fix broken API changes:
- `RoomInfo.isPublic` is now optional, so we need to assume its default value in some places of the app.
- `RoomInfo.userPowerLevels` is now `RoomInfo.roomPowerLevels` and also contains this info.
- `ClientBuilder` now uses a `DecryptionSettings` value.
- The call widget settings provider now internally uses a different Rust type.
- `Client.clearCache` now takes a `syncService` so it can stop it.
---
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Jorge Martín <jorgem@element.io>
- Add `runCatchingExceptions` and `mapCatchingExceptions` to replace `runCatching` and `mapCatching`.
- Make `tryOrNull { ... }` catch only exceptions too.
- Apply the changes to the whole project.
- Add new Rust fakes for tests to handle the code that's now unblocked - previously it just threw an `UnsatisfiedLinkError` which we ignored.
- Add a new `detekt-rules` project with a `RunCatchingRule` to prevent `runCatching` and `mapCatching` usages.
- Use `NotiticationService.getNotifications()` function so we resolve the events in bulk.
- Added `NotifierResolverQueue` to group the notifications to resolve based on a debounce strategy.
- Batch rendering of these events as notifications.
* Add support for login link
https://mobile.element.io/element?account_provider=example.org&login_hint=mxid:@alice:example.org
* Update screenshots
* Reduce code duplication
* Add test on OnBoardingPresenter
* Fix tool
* Ignore login parameter if user is not allowed to connect to the provided server.
* Improve tests.
* Cleanup
* Revert change on Project.xml.
* Add documentation
* Improve LoginHelper
* Rename LoginFlow to LoginMode
Move LoginFlow to package io.element.android.features.login.impl.login
Rename some implementation of LoginMode
Rename LoginFlowView to LoginModeView
* Change launchMode of MainActivity from `singleTop` to `singleTask`
Using launchMode singleTask to avoid multiple instances of the Activity when the app is already open. This is important for incoming share and for opening the application from a mobile.element.io link.
Closes#4074
---------
Co-authored-by: ElementBot <android@element.io>
* Import type
* Add test to cover an existing issue. roomCoroutineScope is not cancelled when the class is destroyed
* Cancel roomCoroutineScope when the class is destroyed
* Move `isOneToOne` to BaseRoom, we do not need a JoinedRoom for it.
* Let `roomInfoFlow` be implemented by RustBaseRoom.
It should fix a few issues where we rely on the room info to be live, and it was not the case on RustBaseRoom.
* Add more assertions.
The test would fail anyway if roomCoroutineScope was still active, but it's more explicit with these assertions.
