The test was in `libraries.mediapickers`, while `PickerType` is in
`libraries.mediapickers.api`.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
It was the only file of the `startchat/impl` module in the
`features.startchat` package.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Some test sources were in `features.call`, `features.call.ui`,
`features.call.utils` and `features.call.notifications`, while the code
they test is in the corresponding `features.call.impl.*` packages.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The namespace was `libraries.usersearch`, without the `.test` suffix, while
the sources are in `libraries.usersearch.test`.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The namespace was `libraries.push.pushstore.impl`, while the sources are in
`libraries.pushstore.impl`. Also update the `adb uninstall` hint of the
instrumentation test accordingly.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The matrixmedia modules were using the `libraries.matrix.ui.media` package
(shared with the matrixui module) and `libraries.matrix.ui.media.*`
namespaces. Use `libraries.matrixmedia.api`, `libraries.matrixmedia.impl`
and `libraries.matrixmedia.test` instead, matching the module paths.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
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>
The permission is granted from the system settings, outside of the app,
so nothing triggered a recomposition of FullScreenIntentPermissionsPresenter
when the user came back. The "Enhance your call experience" banner kept
being displayed until something else caused a recomposition.
Check the permission again with LifecycleResumeEffect, as done in
BatteryOptimizationPresenter, and add a test for this case.
Some modules were using package names or namespaces inherited from copy-paste
or from older module names (e.g. `features.logout.impl` in the deactivation
module, `features.api` in the migration api module, `sessionstorage` in the
cachestore module), or containing typos (`roomaliasesolver`,
`roomdetetailsedit`).
Move the sources to the package matching their module, update the imports, and
rename the impacted screenshots accordingly.
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>
Benoit Marty
Benoit Marty
ElementBot
renovate[bot]
Bardi Harborow
Jorge Martin Espinosa
ganfra