The raw push rules returned by the SDK are a single long line of json, which is
hard to read on a phone. Re-encode the content with a pretty printer using a two
space indentation before handing it to the file viewer.
Parsing to a JsonElement and re-encoding preserves the order of the keys, so the
rules are still listed in the order the server returned them. Content which
cannot be parsed is passed through unchanged, so that a malformed payload remains
viewable.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Add a "Push rules" item in the Notifications section of the developer options,
above "Push history". It displays the raw push rules of the account, which were
only available as a rageshake attachment so far.
The content is read using NotificationSettingsService.getRawPushRules(), then
rendered by the new FileViewerEntryPoint, so that the screen looks like the media
viewer rendering a file, with Share and Download actions on a
push_rules<userId>.json file. The user id contains a colon, which is not a valid
file name character on all the file systems, so it is replaced by an underscore.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Introduce io.element.android.libraries.mediaviewer.api.FileViewerEntryPoint, a
reusable screen which renders content that is not a Matrix media the same way the
media viewer renders a file, with Share and Download actions.
The caller provides a filename, a mime type and the whole content as a String.
The node writes it to a temporary file in the cache directory, then reuses
LocalMediaView (so text content goes through TextFileViewer) and LocalMediaActions
for sharing and saving on disk. The node is contributed to AppScope so that the
screen can be used from any graph, since MediaViewerNode itself is bound to
RoomScope and depends on the timeline data sources.
Also route MimeTypes.Json to TextFileView in LocalMediaView, so that a json file
is rendered as text instead of falling back to the generic file card.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sharing from another app listed Element X once, with no way to pick a
conversation: the Direct Share row never showed any.
The app already publishes a long-lived, conversation-categorised shortcut per
room, which is most of what the sharing shortcuts API needs. The part that was
missing is the declaration that ties those shortcuts to the share intent: the
launcher activity had no `android.app.shortcuts` meta-data, so there was no
`<share-target>` for the system to match them against.
It now ships one, matching the activity that already receives ACTION_SEND, and
the shortcuts carry the category it names.
The system offers these from Android 10 onwards, where sharing shortcuts are
handled natively. Reaching further back would additionally need the
androidx.sharetarget library, which is not added here.
Part of #3835
Editing the caption of a media message dropped all of its formatting: bold,
links and the rest came back as plain text, and saving wrote that plain text
over the formatted caption.
The composer was being opened on the plain caption. Editing a message body
already starts from its HTML when rich text editing is on, and the caption
path was the only one that did not - it read `captionOrNull()` and never had
the caption's HTML to read, because the timeline content only kept the
already-parsed `formattedCaption`.
Media contents now carry the caption's HTML alongside the parsed one, the
same way text contents carry `htmlBody`, and editing a caption starts from it
when rich text editing is on. The save path already sent the composer's HTML,
so nothing changes there.
Part of #6730
Deleting a message that headed a thread took the thread with it: the "N
replies" summary under the message disappeared and there was no way back to
the replies, which are still there.
Every branch of the timeline content mapper passes `MsgLikeContent`'s thread
information on except the redacted one, which returned a bare
`RedactedContent` and dropped it. The thread summary lives on
`MsgLikeContent` next to `kind`, so it survives the redaction; only the app
was throwing it away. `RedactedContent` now carries the thread info like the
other contents do, and `EventTimelineItem.threadInfo()` reads it.
A deleted message that still heads a thread is also left out of the "N
removed messages" group, which would otherwise hide the summary again as soon
as three deletions ended up next to each other.
Part of #7397
Upgrading over an older install crashed before the login screen with
`SQLiteException: no such column: SessionData.position`. The session, cache
and push databases were opened at their new schema version but their tables
were never migrated.
`SqlCipherDriverFactory` overrides `AndroidSqliteDriver.Callback.onUpgrade` so
the database key can be replaced, and never called through to the base
implementation - which is the only thing that runs `schema.migrate`. Every
SQLDelight migration in the app was skipped as a result.
The override now calls `super.onUpgrade` after the re-key, so a database that
crosses the re-key version is still re-encrypted before its tables are
migrated. It moved out of an anonymous object into a named `MigrationCallback`
so the behaviour can be tested.
Part of #7509
The room list preview prefixes the sender's name unless the room is a
direct message. A room that was created as a group and later converted to
a direct message is not marked as one by the server, so its preview kept
naming the only other person in it on every message, while iOS did not.
The prefix now depends on how many people are actually in the room rather
than on the direct message flag, which is the behaviour asked for in the
issue: no name while only two people can be talking, the name back as
soon as a third joins.
Part of #1548
While the homeserver is unreachable but the device still has a working
network, the app showed no indication at all: the syncing chip is hidden
as soon as the SDK reports the session offline, and the offline banner
only appears when the device itself has no connectivity. A blocked or
down server was therefore indistinguishable from a quiet, healthy one.
The chip now has three states rather than a boolean, and the third says
"Server unreachable" for exactly that case. When the device has no
network the chip stays hidden, because the offline banner already says so
and two overlapping messages would be worse than one.
Part of #4099
A session whose recovery state is INCOMPLETE has not got the secrets it
would need to sign another device, so accepting an incoming verification
request from it can only fail. The screen offered "Start verification"
anyway, and the user learnt otherwise at the end of the flow.
Show the design's alert step instead — "Verification with this device is
currently unavailable" — with only the Ignore action, and leave the
request unacknowledged in every other respect.
Part of #5344.
The developer option passes its value through to the widget URL verbatim,
so it has to be the URL of the page that joins a room rather than the
deployment root. That is not obvious from the field, and hughns asked for
it to be written down in docs/ rather than expanded inline in the app,
because the path depends on how the deployment was hosted.
Part of #4475.
The gallery gave no indication of how old the screenshots on the page were,
which is one of the remaining items on the GitHub Pages improvement list.
The generator now writes the time it ran alongside the screenshot data, and the
page renders it in the footer next to the existing links.
The doc told the reader to add disableSslVerification() to
RustMatrixClientFactory.create(), which has not built the client for a long
time; getBaseClientBuilder() is where the chain lives, and it covers both the
login client and the restored session client.
It also only described the emulator's own proxy setting, while the app already
follows the device's global proxy through DefaultProxyProvider, which is the
only way to do this on a physical device.
The timeline renders a message with the sender's raw Matrix ID whenever the
SDK has no profile for them, even though the room member list the same screen
already holds usually knows their display name and avatar.
The timeline item factory now falls back to the room member for a sender whose
profile is not resolved, both when the item is first built and when the member
list arrives afterwards, so the name and the avatar settle on the display name
instead of staying on the ID.
The member suggestions were emitted in whatever order the room member list
happened to be in, so a member who only matches somewhere in the middle of
their name could be offered above one whose name starts with the query.
Matches are now ordered by how well they match: display name prefix first,
then user ID localpart prefix, then any other match. The sort is stable, so
members of equal rank keep the order the member list gave them.
The @room suggestion was also matched case sensitively, so typing @Ro or
@ROOM dropped it while @ro kept it. It now matches the query the same way
the members do.
Benoit Marty
Benoit Marty
ElementBot
hayaksi1
Benoit Marty
Benoit Marty