sessionPaths keeps pointing at the directories of the account which has
just been logged in, and it was never reset. Adding another account
calls setHomeserver(), whose rotateSessionPath() starts by deleting the
directories of the previous sessionPaths, so the file and cache
directories of the first account were wiped.
finalizeClientCreation() now forgets the session paths once the login
succeeded. It is done there rather than in clear() on purpose: after a
failed attempt the directories are orphaned and must still be deleted by
the rotateSessionPath() of the next attempt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Since the login flows stopped handing their client over to
RustMatrixClientFactory and let finalizeClientCreation() build a fresh
one from the SessionData, two problems appeared.
The client built by loginWithQrCode() was never owned by anyone: it is
not assigned to currentClient, so clear() had nothing to close and the
Rust Client stayed open for the whole app lifetime, holding the session
stores of the freshly logged in account. It is now tracked in
currentClient, and also disposed of when the QR login fails, which is
safe because that flow always builds its own client.
The client of the session was also built while the login client was
still open. Both use the same session paths, so their state and crypto
SQLite stores, and the search index when message search is enabled, were
opened twice at the same time with no cross process lock to protect
them. clear() now runs before the final client is created.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Fix API breaks:
- A new `Mentions` room list filter is available.
- `RoomListService.subscribeToRooms` is now `RoomListService.setRoomSubscriptions`.
- `enableAutomaticBackPagination` moved from `Client` to `ClientBuilder`.
Secrets are never exposed to pull_request runs from forks, so checkEnv.js
throws on MAESTRO_PASSWORD after a full APK build and emulator boot, and the
red check is indistinguishable from a real test failure. The existing guard
checked github.event.pull_request.fork, a field that does not exist on the
pull_request payload (it lives at head.repo.fork), so it was always true.
Gate both jobs at job level on head.repo.full_name == github.repository
(workflow_dispatch still runs), and drop the dead step-level condition.
Fixes#7653
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
With the default (queue: single), a run that finishes Build APK while
another run is already pending in the maestro-test group cancels that
pending run, which then never gets a Maestro verdict for its commit.
queue: max keeps the one-at-a-time constraint (no cancel-in-progress) and
lets up to 100 runs wait, at no runner cost.
Fixes#7654
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The -dontwarn is still required: firebase-messaging ships no consumer rules and
we exclude firebase-analytics from its dependencies. Only rename the file to
consumer-rules.keep and reword the comment, which embedded a local path.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The rule only kept the class, but ShowkaseBrowserActivity instantiates it with
Class.forName(...).getDeclaredConstructor().newInstance(), so R8 was free to
strip the constructor. Also drop the AGP template comments and rename the file
to .keep, for consistency with app/proguard.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The three rules came from a 2022 comment on Retrofit issue #3751. Retrofit
3.0.0 now ships META-INF/proguard/retrofit2.pro, which contains two of them
verbatim and covers retrofit2.Call through its conditional return-type rule.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This is now 7, which is higher than the max value (6) renovate adds by default, so they are *always* prioritised above the rest, even if renovate gets rate-limited.
* Keep the push foreground service alive while notifications are fetched
* Release the push foreground service as soon as results are handed over
---------
Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
* Make sure `enforce_element_pro` is taken into account in FOSS
* Make sure we crate `RustTemporaryMatrixClient` instances with a proper `serverName` value
* Expose the timeline item gestures as TalkBack actions
Long pressing a timeline item opens the action list, and swiping it
starts a reply. Neither gesture is reachable with a screen reader
enabled, so those two actions were unavailable to TalkBack users.
Publish them as accessibility custom actions on the event row, reusing
the existing "Message actions" and "Reply" strings. The reply action is
only offered when the user is allowed to reply, matching the swipe.
* Update screenshots
---------
Co-authored-by: ElementBot <android@element.io>
Benoit Marty
Jorge Martin Espinosa
ganfra
renovate[bot]
Benoit Marty
ElementBot
andreBurnt
Johannes Marbach
hayyaksi
ElementBot
jmartinesp