AppMigration11 was run once, in the first release containing it, whatever
the state of the MultiAccount feature flag. Users installing the app
while the feature flag was disabled were considered as new users and
would never see the announcement once the feature flag got enabled.
The multi-account announcement is now pending by default (NeverShown),
and is marked as shown when the user enters the login flow while the
feature is enabled, either for the first time or to add another account.
Users who were already logged in before the feature became available
will see the announcement.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
If the announcement was queued at upgrade while the user had a single
account, and the user then added another account without seeing it, the
announcement stayed pending and was shown later if the user removed an
account. Mark it as dismissed as soon as several accounts are detected.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Show a one-time bottom sheet on the home screen to announce that several
accounts can now be added (element-hq/element-meta#3349).
- Add `Announcement.MultiAccount`, which is never shown by default.
- AppMigration11 queues the announcement on application upgrade only,
and marks it as shown if the user already has several accounts.
- HomePresenter shows the bottom sheet only when the announcement is
pending, the MultiAccount feature flag is enabled and the user has a
single account.
- The "Add account" button hides the sheet, marks the announcement as
dismissed and starts the add account flow through the new
`HomeEntryPoint.Callback.navigateToAddAccount()`.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Add the `screen.multi_account_announcement.*` keys to the home module
Localazy configuration and import the latest strings.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Since Android 13, the system displays its own confirmation when content
is copied to the clipboard, so the application does not render its own
Toast or Snackbar anymore on those versions.
Context.copyToClipboard, CopyToClipboardUseCase and the direct
ClipboardManager usage in EventDebugInfoView are removed.
ClipboardHelper.copyPlainText(text, isSensitive, onSuccessOnOldDevice)
is now the only entry point, and AndroidClipboardHelper is the only
class using ClipboardManager.
Copy actions from the views are moved to their Presenter through new
events, or to the Node when there is no Presenter. A ToastHelper is
introduced so that Toasts are kept where they were used before.
Snackbars are kept where they were already used.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Use the password keyboard type, mark the field as a password for
autofill, and submit the reset with the IME "Done" action, matching
the login password field.
The recovery key was copied without EXTRA_IS_SENSITIVE, so Android 13+
showed it in the clipboard preview and keyboards could store it in
their clipboard history.
Add an isSensitive option to CopyToClipboardUseCase and
Context.copyToClipboard, and set it when copying the recovery key.
* Allow displaying only unread notifications
Add `FeatureFlags.ShowAllActivityInRoomList` (enabled by default, to match the current behavior) that, when disabled, will display the unread messages of a room instead of unread notifications if no unread notifications are found
* Restore UI changes to the badges, `RoomSummaryRow` and `HorizontalFloatingToolbar`
* Fix `NavigationBarIcon`: use `BadgeBox` component.
* Adjust padding in `RoomSummaryRow` to 6.dp
* Fix other indicators not displaying a dot anymore
* Update screenshots
---------
Co-authored-by: ElementBot <android@element.io>
* Make `StrictMode` more lenient for network on main thread violations
`rustls-platform-verifier-android:0.2.0` performs the certification revocation checks in whatever thread called the Rust code that triggered the network request. In our codebase, sometimes this is the main thread through `MainScope`.
This would usually be fine if we were using suspend APIs, since it would just wait for a result and not block the main thread. However, the cert verification logic uses some `HttpUrlConnection` calls under the hood that are fully blocking and this triggers `NetworkOnMainThreadException`, which in turn make the revocation fail.
With these changes, we log those issues but don't make them break the certificate verification. That said, we should revert this logic once a fix lands in the verifier.
* Make the `StrictMode` weaker only for release and nightly builds
This way we can fix the issues when we detect them in debug builds.
* Fix `org.matrix.rustsdk.Android.init` not being called immediately in `PlatformInitializer`
This must be called before `platformService.init(tracingConfiguration)`
* Add `penaltyDialog`, to check if it's useful or just annoying
Replace the hand-written runningFold in RootFlowNode.observeRemovedSessions() with the existing withPreviousValue() helper, as done in IncomingVerificationRequestObserver.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- Clear the listener when RustSessionVerificationService is destroyed.
- IncomingVerificationRequestObserver removes the listener of the clients which are not in the MatrixSessionCache anymore.
- Remove the sessions from the MatrixSessionCache when they are removed from the SessionStore (logout, account deactivation).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* Add remove and clear history buttons to search
* Rename `SearchHistoryResultItem` to `SearchHistoryListItem` and `MessagesSearchResultItem` to `MessageSearchListItem`
Also, add some docs.
* Update screenshots
---------
Co-authored-by: ElementBot <android@element.io>
- Update .idea/kotlinc.xml to Kotlin 2.4.20.
- Remove `-Xannotation-default-target=first-only`: the new annotation
default target rule is stable in Kotlin 2.4, and disabling it now
produces a CLI_ARG_DISABLES_STABLE_FEATURE warning.
- Replace deprecated `KSNode.validate()` with
`validate(enableNewFeatures = false)` to keep the same behavior.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Paparazzi 2.0.0-alpha05.1 ships layoutlib 16.2.3, which fixes the errors this
rule was swallowing. All screenshot tests pass without it.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Recording rewrote every screenshot unconditionally, so renderer noise far below
the verification tolerance produced large "Update screenshots" commits.
Use `app.cash.paparazzi.overwriteOnMaxPercentDifference` to keep screenshots that
are within tolerance. Existing screenshots are no longer deleted before recording;
obsolete ones are pruned afterwards, only when their preview produced no
screenshot at all.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Benoit Marty
ElementBot
renovate[bot]
Jorge Martin Espinosa
Benoit Marty
Bardi Harborow
ganfra