Synapse deletes sliding sync connections that have been unused for 7 days. When
an OEM battery manager has kept the application frozen for longer than that, the
next sliding sync request is answered 400 M_UNKNOWN_POS.
The Rust SDK handles that: it resets `pos` and, in offline mode, restarts the
sync. When that recovery gives up, the sync service ends up in the Error or
Terminated state and stops for good, and it is then up to the application to
call start() again. Element X iOS does it, we do not: SyncOrchestrator only
restarts the sync service when its state is Idle, so the sync stays dead for the
rest of the process lifetime.
Nothing recovers from there. The sync never reaches Running, so
waitForE2eeInitializationTasks() never returns, the session verified status
stays Unknown, and the FTUE is stuck on WaitingForInitialState. Clearing the
application data is the only workaround.
Restart the sync service when it is in the Error or Terminated state, with an
exponential backoff from 1s to 30s to avoid hammering a failing homeserver. The
backoff is only reset once the sync service has been running for a while, since
startSync() moves the state to Running right away.
Fixes#7689
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
emptyNode() renders nothing at all, which is fine for a placeholder that is left
within a few frames, but makes the application look frozen when the wait can
last, or never end.
Add a delayBeforeShowingContent parameter to emptyNode(): when it is finite, a
progress indicator and a "Loading…" label fade in after that delay, reusing the
existing DelayedVisibility helper. It defaults to Duration.INFINITE, so the
splash screen keeps rendering an empty canvas.
Use a one second delay on the two placeholders which are not guaranteed to be
left: the FTUE one, rendered while waiting for the session verified status, and
the LoggedInFlowNode one, rendered while the FTUE state is unknown.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Try improving renovate issues with Maven Central rate limiting
Try not to make too many concurrent requests to Maven Central
The logs display rate limit responses followed by OK responses, which could mean we're hammering the Maven Central repo with too many concurrent requests
* Try not hitting Maven Central for `androidx` packages
* Update dependency org.matrix.rustcomponents:sdk-android to v26.09.08
* Fix API breaks:
- There's no `SyncServiceBuilder.withProfilesExtension()` method anymore. This is now enabled unconditionally in the SDK.
- Timeline filters no longer use the `org.matrix.rustcomponents.sdk.TimelineEventFilter` FFI wrapper, but the `uniffi.matrix_sdk_ui.TimelineEventFilter` type directly. This also changes the underlying types used for inclusion/exclusion.
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Jorge Martín <jorgem@element.io>
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 PR metadata checks move to a new PR Checks workflow, and the lint,
ktlint and detekt reports are now surfaced as inline annotations from the
quality workflow. This removes the danger-js dependency, its ad-hoc npm
installs and the need for the ElementBot token, so the checks also run on
pull requests from forks.
Co-Authored-By: Claude Opus 5 (1M context) <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>
Benoit Marty
ElementBot
ganfra
renovate[bot]
Jorge Martín
Benoit Marty
ganfra
ElementBot
andreBurnt