WebXDC preview and message rows were constructing page objects without a
lifecycle owner that released the backing ZipFile. Keep ZipFile
ownership inside active sessions, close previews after metadata and icon
reads, and make session removal close pages explicitly.

Avoid constructing long-lived WebxdcPage instances during message
binding. Use cached file metadata for the initial button label, refresh
the manifest title in the background, and load icons through the
existing file attachment executor.

When the legacy telecom settings component is missing on Android 17,
Cheogram falls back to the telecomui activity. Android can still deliver
an early DIALLER_INTEGRATION callback for the failed legacy launch
before the real fallback result arrives.

Use a separate fallback request code and ignore that bogus legacy
callback while the telecomui result is still pending. Keep the final
phone account settings launch deferred until the fallback flow returns
so the deeper telecomui screen stays first in the task.

Persist the request code and in-flight flag across savedInstanceState so
the guard survives if Android kills and recreates the activity mid-flow,
matching the existing pending-intent persistence.

Seems com.android.server.telecom.settings.EnableAccountPreferenceActivity was
named com.android.server.telecomui.settings.EnableAccountPreferenceActivity in
Android 17 beta: https://issuetracker.google.com/issues/476293144

Add logging around the onboarding dialler-integration flow so we can see which
system activity branch runs and what ACTION_CHANGE_PHONE_ACCOUNTS resolves to
on-device.

turns out that `android.widget.AbsView` calls the listener immediately
after setting it

from cherry-pick of f96f58acd1ce1e1a232991c6be283d8109a48ae7

(cherry picked from commit e8d62b34e4de5c138869538a0670e06258443358)

(cherry picked from commit dfccdce61fb98e847245f5bed3c1945474b1bbd2)

Null-guard getDisplayName() and use compareTo instead of equals so
the return value satisfies anti-symmetry, previously violated by
examples like this:
```
- A: displayName "alice", jid z@example.com
- B: displayName "Alice", jid a@example.com
- C: displayName "alice", jid m@example.com
```

* 'no-such-method-in-geohelper' of https://git.secluded.site/cheogram-android:
Don't rely on newer URLEncoder overload

`onTextDeleted` is called from a single-threaded executor. the zero-arg
overload of `storeNextMessage` reads from the `EditMessage` component,
but `onTextDeleted` should obviously never read a non-null message, so
there's no reason to coordinate it with the UI thread.

To match the long ago change to JMP MMS limit

Can't provoke the race, but my theory about
https://todo.sr.ht/~singpolyma/soprani.ca/599 is that it's caused by `o
== page1.get()` (or `page2.get()`) evaluating to `true` when
`page1.get() == null`, causing the item to stick around in the dataset,
e.g., during device rotation or some other situation where the view is
destroyed, and breaking ViewPager's internal bookkeeping

Android's ViewPager caches the active pointer id from ACTION_DOWN and
later calls findPointerIndex(mActivePointerId) on MOVE events. When
the OS delivers a MOVE whose pointer set no longer contains that id
(a known multi-touch race), findPointerIndex returns -1 and getX(-1)
throws IllegalArgumentException from native code, crashing the app:

java.lang.IllegalArgumentException: invalid pointerIndex -1 for
MotionEvent { action=MOVE, ... }
at android.view.MotionEvent.nativeGetAxisValue(Native Method)
at android.view.MotionEvent.getX(MotionEvent.java:2655)
at androidx.viewpager.widget.ViewPager.onInterceptTouchEvent(ViewPager.java:2087)

SafeViewPager wraps onInterceptTouchEvent and onTouchEvent in a
try/catch and returns false on the exception, letting children handle
the event and letting the pager recover on the next clean DOWN.
Subsequent commits route the three ViewPager instances in the app
through this class.

A couple of places have implemented basically this exact workaround,
e.g., https://github.com/signalapp/Signal-Android/blob/main/app/src/main/java/org/thoughtcrime/securesms/components/viewpager/HackyViewPager.java

Old Android releases do not provide the URLEncoder overload that takes a
Charset, so a received geo URI could crash as soon as its notification
label was built. Go back to the older UTF-8 overload so the same label
encoding does not depend on an API that's missing at runtime.

* 'investigate-activity-not-found' of https://git.secluded.site/cheogram-android:
Show toast when can't open privacy policy

* 'handle-no-doc-activity-found' of https://git.secluded.site/cheogram-android:
Handle missing backup location picker

manually checked that the delete query works even when the rows are in
the SqliteBlobTooBigException range

`null` was to `ConversationPage` in `destroyItem` when
`ViewPager.dataSetChanged`'s POSITION_NONE branch cleaned up a dormant
null in `mItems`. The null originates from `instantiateItem`'s
bounds-check branch (`position-2 >= sessions.size() -> return null`),
which ViewPager stores via `addNewItem` and later passes back to
`destroyItem` during cleanup.

Deterministically tested fix by the first call to `instantiateItem`
should return `null`, after which a `notifyDataSetChanged` via
tapping another command. Resulted in same crash as the report.

* 'dont-linkify-invalid-urls' of https://git.secluded.site/cheogram-android:
Don't linkify invalid links

Catch ActivityNotFoundException when launching the backup location
picker. Devices without an OPEN_DOCUMENT_TREE handler now get the
existing no_application_found toast instead of crashing from the
preference tap.

`Message.getLinks` wasn't broken, but I thought it was at first, and
then I had already written the test, so here it is.

On wide screens, Android re-uses the ViewPager + TabView
in between conversations, which means `Conversation.onDestroyView`
doesn't get called, which results in `mCurrentTab` getting set for
previously opened chats. This manifested as [0]

[0]: https://todo.sr.ht/~singpolyma/soprani.ca/554

the stack trace manifested as:
```
Version: Cheogram debug-local+free
Manufacturer: OnePlus
Device: OnePlus6
Timestamp: 2026-04-01 21:27:32 -0400
java.lang.IndexOutOfBoundsException: Index 1 out of bounds for length 1
at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
at jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266)
at java.util.Objects.checkIndex(Objects.java:385)
at java.util.ArrayList.get(ArrayList.java:434)
at eu.siacs.conversations.ui.ManageAccountActivity.lambda$onCreate$3(ManageAccountActivity.java:140)
at eu.siacs.conversations.ui.ManageAccountActivity.$r8$lambda$fcEx2bGWBsQPp04OkU82pOGEvUg(Unknown Source:0)
at eu.siacs.conversations.ui.ManageAccountActivity$$ExternalSyntheticLambda0.onItemClick(D8$$SyntheticClass:0)
at android.widget.AdapterView.performItemClick(AdapterView.java:330)
at android.widget.AbsListView.performItemClick(AbsListView.java:1274)
at android.widget.AbsListView.onKeyUp(AbsListView.java:3511)
at android.widget.ListView.commonKey(ListView.java:2498)
at android.widget.ListView.onKeyUp(ListView.java:2371)
at android.view.KeyEvent.dispatch(KeyEvent.java:3471)
at android.view.View.dispatchKeyEvent(View.java:16521)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1982)
at android.widget.ListView.dispatchKeyEvent(ListView.java:2346)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1987)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1987)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1987)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1987)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1987)
at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1987)
at com.android.internal.policy.DecorView.superDispatchKeyEvent(DecorView.java:462)
at com.android.internal.policy.PhoneWindow.superDispatchKeyEvent(PhoneWindow.java:1971)
at android.app.Activity.dispatchKeyEvent(Activity.java:4557)
at androidx.core.app.ComponentActivity.superDispatchKeyEvent(ComponentActivity.kt:96)
at androidx.core.view.KeyEventDispatcher.dispatchKeyEvent(KeyEventDispatcher.java:85)
at androidx.core.app.ComponentActivity.dispatchKeyEvent(ComponentActivity.kt:110)
at androidx.appcompat.app.AppCompatActivity.dispatchKeyEvent(AppCompatActivity.java:604)
at androidx.appcompat.view.WindowCallbackWrapper.dispatchKeyEvent(WindowCallbackWrapper.java:59)
at androidx.appcompat.app.AppCompatDelegateImpl$AppCompatWindowCallback.dispatchKeyEvent(AppCompatDelegateImpl.java:3397)
at com.android.internal.policy.DecorView.dispatchKeyEvent(DecorView.java:376)
at android.view.ViewRootImpl$ViewPostImeInputStage.processKeyEvent(ViewRootImpl.java:8034)
at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:7873)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:7259)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:7316)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:7282)
at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:7448)
at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:7290)
at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:7505)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:7263)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:7316)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:7282)
at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:7290)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:7263)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:7316)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:7282)
at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:7481)
at android.view.ViewRootImpl$ImeInputStage.onFinishedInputEvent(ViewRootImpl.java:7721)
at android.view.inputmethod.InputMethodManager$PendingEvent.run(InputMethodManager.java:5053)
at android.view.inputmethod.InputMethodManager.invokeFinishedInputEventCallback(InputMethodManager.java:4430)
at android.view.inputmethod.InputMethodManager.finishedInputEvent(InputMethodManager.java:4421)
at android.view.inputmethod.InputMethodManager.-$$Nest$mfinishedInputEvent(Unknown Source:0)
at android.view.inputmethod.InputMethodManager$ImeInputEventSender.onInputEventFinished(InputMethodManager.java:5030)
at android.view.InputEventSender.dispatchInputEventFinished(InputEventSender.java:181)
at android.os.MessageQueue.nativePollOnce(Native Method)
at android.os.MessageQueue.next(MessageQueue.java:387)
at android.os.Looper.loopOnce(Looper.java:189)
at android.os.Looper.loop(Looper.java:317)
at android.app.ActivityThread.main(ActivityThread.java:8934)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:591)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:911)
```
notice that this required tab navigation, as the footer doesn't seem
visible, although maybe possible to hit it with your thumb idk. this is
especially tricky when the footer is invisible, i.e., when there aren't
any PSTN gateways configured

String.format with %d uses the default locale's numeral system.
On Persian (fa) locale this produces ۶۵۵۳۴ instead of 65534,
causing an SQLite error.

Extract the expression into truncatedAttributesColumn() so it
can be tested under a non-default locale, and replace
String.format with concatenation which always uses ASCII digits.

The RFC specifies a minimum iteration count of 4096 only as a "SHOULD".
Therefore, requiring 4096 on the client side is technically not fully in
line with the spec. However, in the existing ecosystem, the servers that
we tested all use 4096 or more.

Previously we used a custom protocol extension to optionally use pending
intents instead of an 'application' extra; nowadays the UnifiedPush spec
supports pending intents officially (and we can stop accepting the
insecure 'application' extra)

beyond that we could theoretically get stack overflow exceptions due to
the recursion in our parser

This commit breaks logging in on servers that announce a -PLUS variant for
SCRAM but do not support XEP-0440.

On servers that do not support XEP-0440, we previously decided to use no
channel binding because picking "none" was better than picking an
unsupported one and failing the login.

However, this behaviour also required us to indicate that we did not
support channel binding; otherwise, the server, seeing an unknown binding
mechanism, would fail our login.

This was a decision made for the broadest possible compatibility with the
pre-0440 ecosystem.

Note that the y flag wasn't the only security layer. Conversations also
uses pinning (if you logged in once with -PLUS, it won't fall back) and
XEP-0474 (basically a fancy version of the y flag).

In addition there is a setting in Conversations to always require Channel
Binding. This will also automatically be turned on for conversations.im
and quicksy.im.

It has now been two years since XEP-0440 was released for ejabberd and
Prosody, and our compatibility concerns have shifted: if you want to have
-PLUS on your server, please update the server to support XEP-0440.

- ConversationGetMucOptionsRaceTest is in its own file to make the
instrumentation barriers a little easier to see and enforce
- It simulates basically the following situation:
i. On app startup, all accounts connect to all MUCs, which
eventually triggers joinMuc, which calls
Conversation.resetMucOptions.
This happens on account's individual XMPP connection Thread.
ii. At the same time, on the UI thread, we bind
ConversationsOverviewFragment, which eventually leads to
ConversationAdapter.onBindViewHolder, which calls getMucOptions.
iii. Conversation.resetMucOptions is not synchronized, so it can
run after the null-check in getMucOptions, resulting in a null
return value.
- Used AtomicReference instead of synchronizing resetMucOptions
because joinMuc is run on a directExecutor associated with the
XmppConnection thread. While the synchronized getMucOptions was
called right after this in the existing code, the documentation for
directExecutor has this to say:
When a ListenableFuture listener is registered to run under
directExecutor, the listener can execute in any of three possible
threads:
- When a thread attaches a listener to a ListenableFuture that's
already complete, the listener runs immediately in that thread.
- When a thread attaches a listener to a ListenableFuture that's
incomplete and the ListenableFuture later completes normally,
the listener runs in the thread that completes the ListenableFuture.
- When a listener is attached to a ListenableFuture and the
ListenableFuture gets cancelled, the listener runs immediately
in the thread that cancelled the Future.
- (This is applicable, since directExecutor uses in
XmppConnectionService are extensively attached to ListenableFuture)
The docs continue:
A specific warning about locking: Code that executes user-supplied
tasks, such as ListenableFuture listeners, should take care not to
do so while holding a lock. Additionally, as a further line of
defense, prefer not to perform any locking inside a task that will
be run under directExecutor: Not only might the wait for a lock
be long, but if the running thread was holding a lock, the
listener may deadlock or break lock isolation.
- Altogether, AtomicReference seems much more aligned with how Google
intends directExecutor to be used.

Anyway, here's the stacktrace that reported this error:
```
2026-02-20 10:41:09.089 7610-7610 AndroidRuntime com.cheogram.android E FATAL EXCEPTION: main (Ask Gemini)
Process: com.cheogram.android, PID: 7610
java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String eu.siacs.conversations.entities.MucOptions.getName()' on a null object reference
at eu.siacs.conversations.entities.Conversation.getName(Conversation.java:1068)
at eu.siacs.conversations.entities.Conversation.getAvatarName(Conversation.java:1784)
at eu.siacs.conversations.ui.util.AvatarWorkerTask.setContentDescription(AvatarWorkerTask.java:135)
at eu.siacs.conversations.ui.util.AvatarWorkerTask.loadAvatar(AvatarWorkerTask.java:105)
at eu.siacs.conversations.ui.adapter.ConversationAdapter.onBindViewHolder(ConversationAdapter.java:255)
at eu.siacs.conversations.ui.adapter.ConversationAdapter.onBindViewHolder(ConversationAdapter.java:33)
at androidx.recyclerview.widget.RecyclerView$Adapter.onBindViewHolder(RecyclerView.java:7846)
at androidx.recyclerview.widget.RecyclerView$Adapter.bindViewHolder(RecyclerView.java:7953)
at androidx.recyclerview.widget.RecyclerView$Recycler.tryBindViewHolderByDeadline(RecyclerView.java:6742)
at androidx.recyclerview.widget.RecyclerView$Recycler.tryGetViewHolderForPositionByDeadline(RecyclerView.java:7013)
at androidx.recyclerview.widget.RecyclerView$Recycler.getViewForPosition(RecyclerView.java:6853)
at androidx.recyclerview.widget.RecyclerView$Recycler.getViewForPosition(RecyclerView.java:6849)
at androidx.recyclerview.widget.LinearLayoutManager$LayoutState.next(LinearLayoutManager.java:2422)
at androidx.recyclerview.widget.LinearLayoutManager.layoutChunk(LinearLayoutManager.java:1722)
at androidx.recyclerview.widget.LinearLayoutManager.fill(LinearLayoutManager.java:1682)
at androidx.recyclerview.widget.LinearLayoutManager.onLayoutChildren(LinearLayoutManager.java:747)
at androidx.recyclerview.widget.RecyclerView.dispatchLayoutStep2(RecyclerView.java:4737)
at androidx.recyclerview.widget.RecyclerView.dispatchLayout(RecyclerView.java:4459)
at androidx.recyclerview.widget.RecyclerView.onLayout(RecyclerView.java:5011)
at android.view.View.layout(View.java:25626)
at android.view.ViewGroup.layout(ViewGroup.java:6460)
at android.widget.LinearLayout.setChildFrame(LinearLayout.java:1891)
at android.widget.LinearLayout.layoutVertical(LinearLayout.java:1729)
at android.widget.LinearLayout.onLayout(LinearLayout.java:1638)
at android.view.View.layout(View.java:25626)
at android.view.ViewGroup.layout(ViewGroup.java:6460)
at androidx.coordinatorlayout.widget.CoordinatorLayout.layoutChild(CoordinatorLayout.java:1213)
at androidx.coordinatorlayout.widget.CoordinatorLayout.onLayoutChild(CoordinatorLayout.java:899)
at androidx.coordinatorlayout.widget.CoordinatorLayout.onLayout(CoordinatorLayout.java:919)
at android.view.View.layout(View.java:25626)
at android.view.ViewGroup.layout(ViewGroup.java:6460)
at android.widget.FrameLayout.layoutChildren(FrameLayout.java:332)
at android.widget.FrameLayout.onLayout(FrameLayout.java:270)
at android.view.View.layout(View.java:25626)
at android.view.ViewGroup.layout(ViewGroup.java:6460)
at android.widget.LinearLayout.setChildFrame(LinearLayout.java:1891)
at android.widget.LinearLayout.layoutVertical(LinearLayout.java:1729)
at android.widget.LinearLayout.onLayout(LinearLayout.java:1638)
at android.view.View.layout(View.java:25626)
at android.view.ViewGroup.layout(ViewGroup.java:6460)
at androidx.drawerlayout.widget.DrawerLayout.onLayout(DrawerLayout.java:1273)
at android.view.View.layout(View.java:25626)
at android.view.ViewGroup.layout(ViewGroup.java:6460)
at android.widget.FrameLayout.layoutChildren(FrameLayout.java:332)
at android.widget.FrameLayout.onLayout(FrameLayout.java:270)
at android.view.View.layout(View.java:25626)
at android.view.ViewGroup.layout(ViewGroup.java:6460)
at android.widget.FrameLayout.layoutChildren(FrameLayout.java:332)
at android.widget.FrameLayout.onLayout(FrameLayout.java:270)
at android.view.View.layout(View.java:25626)
at android.view.ViewGroup.layout(ViewGroup.java:6460)
```

ConcurrentModificationException can only be triggered by (a) obviously,
multiple threads modifying the same collection or (b) one thread which
modifies the thread while iterating over it (see [here](https://docs.oracle.com/javase/8/docs/api/java/util/ConcurrentModificationException.html)). Assuming that `systemTags` doesn't alias `this.systemTags`, it must be (a). Also, the stacktrace we got comes from inside `old.equals`. consider:
```java
final JSONArray old = this.systemTags;
this.systemTags = new JSONArray();
final JSONArray old = this.systemTags;
...
this.systemTags.put(...)
!old.equal(...)
```
and we get ConcurrentModificationException bc Thread 2's `old` alias's
thread 1's `this.systemTags`

The patch fixes this bug by making suring that no references escape
function scope, so no aliasing can occur.

This can work around if your local resolver strips DNSSEC, but also it
means resolution is bonkers slow and might even take forever / fail if
DNS queries are blocked (because you're on TOR VPN or similar). So if
recursive DNSSEC fails, just fail DNSSEC and fall back to regular DNS lookups.