* Handle preference stores corruption by clearing them:
- Use the centralised `PreferenceDataStoreFactory` instead of `preferences by`.
- Add `DefaultPreferencesCorruptionHandlerFactory.replaceWithEmpty` to its `create(name)` method so all preference stores are cleared if they're corrupted.
* Add detekt rule to make sure we use `PreferenceDataStoreFactory` instead of `by preferencesDataStore`
* Remove `@SingleIn` annotations as the annotated class no longer have to be singletons
This is the missing piece for Android to treat a notification as a
"conversation". Note that this requires shortcuts to have already been
created prior to receiving the notification.
Signed-off-by: Joe Groocock <me@frebib.net>
* 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>
* 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>
