Add simple update flow by wchen342 · Pull Request #4582 · deltachat/deltachat-android

wchen342 · 2026-08-03T18:09:07Z

A very simple self-update flow, starting from device message:

Then a simple progess dialog:

And going into install dialog:

Permission check happens before downloading to avoid wasting a download, other problems like app id mismatch are shown as toasts.

resolve #4575

github-actions · 2026-08-03T18:12:39Z

To test the changes in this pull request, install this apk:

📦 app-preview.apk

r10s · 2026-08-05T15:13:22Z

some quick feedback:

we want to have a button in the update message bubble, similar to webxdc or full-message (we can reuse that probably). button should read "Update Now"
before we open the system settings about "install apk from unknown sources", we want to have a dialog, explaining what is going on: "To install the update, please first allow Delta Chat to install apps in the system settings." buttons: "Open Settings" (string exist as open_settings) and "Cancel".
if possible: when "Open Settings" is hit, set a bool to remember that state and open system settings. when the activity resumes, the bool is set, and the user granted the permission, continue update
if smth goes wrong, better show the error in a dialog. these toast are not good for that, no one can read that fast :)

wchen342 · 2026-08-06T18:31:11Z

I have added the button on message:

And the dialog before opening the settings:

The installation will resume when the user comes back.

The errors are shown in the same dialog now.

adbenitez · 2026-08-10T13:06:10Z

after talking with @r10s wrt the core side of this etc. we also came over some change of requirements:

do not wait for update to be older than 1 week to add the device message, we can better control this server-side
after update is finished, remove the device message, otherwise it will stay "update available" even after user updated, which is confusing. Since the app is restarted after upgrade, I guess one idea to know if it was upgraded is to save the versionInteger + device-msg ID in some preferences right before giving the apk to the system installer, then on app start check that preference and if set, and current app's version number >= the set version number then remove the corresponding device message using the existing APIs to remove messages given the msg ID and clear the stored preferences

about that last point: I also realized that we are adding that device message for every selected profile, better do it only in one profile, and in the rest set it to null as we do already in ConversationListActivity.addDeviceMessages(), maybe move AppUpdate.addUpdateDeviceMsg(context); there instead of doing it in ConversationListFragment

r10s · 2026-08-10T14:14:58Z

then we probably can also drop release_timestamp? that would make providing/checking the json by hand much easier, and one think less to care/think about :)

still, it makes sense to do the update check only once per day or every some hours, at a somehow random time

wchen342 · 2026-08-10T14:17:03Z

then we probably can also drop release_timestamp? that would make providing/checking the json by hand much easier, and one think less to care/think about :)

It may be useful later so I say we just keep it, it basically costs nothing.

adbenitez · 2026-08-10T16:21:05Z

we are adding that device message for every selected profile, better do it only in one profile, and in the rest set it to null as we do already in ConversationListActivity.addDeviceMessages()

It may be useful later so I say we just keep it, it basically costs nothing.

it is not about cost, it is about annoyance, if you have, for example, 5 profiles, you will have to deal 5 times with a device message chat with the same unread message, also for removing it later is much easier because you have to only remove it in 1 place

wchen342 · 2026-08-10T18:36:06Z

Strange, github quoted the wrong message. I was replying to the timestamp thing @r10s mentioned.

github-actions · 2026-08-10T18:37:55Z

To test the changes in this pull request, install this apk:

📦 app-preview.apk

adbenitez · 2026-08-10T18:38:06Z

Strange, github quoted the wrong message. I was replying to the timestamp thing r10s mentioned.

ahh! wrt that the thing is that core will just not provide the field

the whole format will change so better wait in that regard to just use the core api, not much to do here than removing the whole mock data with timestamp and stuff

wchen342 · 2026-08-10T18:39:18Z

I updated the update flow to show only in the active profile. Also the message shall remove itself after a new version is installed now. The one-week check is also removed.

- remove device message after update

github-actions · 2026-08-10T18:50:51Z

To test the changes in this pull request, install this apk:

📦 app-preview.apk

r10s · 2026-08-10T21:27:23Z

i did the core part at chatmail/core#8557 - but please wait for replacing MOCKUP by real calls until things are settled there; there are some open ends to be discussed

link2xt · 2026-08-12T09:32:31Z

+    if (context == null || activity == null) return;
+
+    PackageInfo info = context.getPackageManager().getPackageArchiveInfo(localPath, 0);
+    if (info == null || !context.getPackageName().equals(info.packageName)) {


For other reviewers: this is the place where we check that downloaded APK is an update and not something entirely unrelated.

r10s · 2026-08-13T09:59:13Z

Also the message shall remove itself after a new version is installed now. The one-week check is also removed.

as we have the hook for that now, let's also add a message "Successfully updated to v1.2.3" - the update needs to be triggered manually by the user, not giving feedback or only implicit feedback (app restarted, message deleted) is not great.

this is also what eg. systems are doing on manual updates, also other apps, eg. here is firefox:

the link to the changelog is not needed tho, if we have smth to say, we anyway add a device message.

to be clear: that message shall only be added if the user started the update with the new manual flow. for completely automated updates from stores, it is not needed - and confusing, as the user usually does not even know

adbenitez · 2026-08-13T10:03:58Z

@r10s this is really not needed, the system already gives feedback that the app got updated after the update finishes, see attached screenshots of an apk update process, showing a message afterwards in-app only makes sense if you are going to announce what is new / changelog, otherwise you are just stating the same again:

wchen342 · 2026-08-13T10:24:10Z

@r10s @adbenitez I kind of agree with adb here. Although I think we can re-purpose the device message we have now to show new changes. Currently that message is static and doesn't do much after a user have installed Delta.

r10s · 2026-08-13T14:41:21Z

k, if that is the normal flow, i am fine for now with not saying smth in device chat after installation (only removing existing "New version available" message)

@link2xt

> we aim to inform about updates for installations outside of any appstore soon. > > there is already a PR on android at deltachat/deltachat-android#4582, however, the information about "update available" is a mockup there. > > in general, there are 3 ideas around about how to gather the "update available" infomation - (1) checking a central url, (2) let contacts provide information, (3) let relay provide information. on various one-to-one discussions, outcome is that (3) is the most reasonable way to go. this PR is about reading update information via IMAP metadata from the relay. it is up to the UI to call `get_app_version()` at a reasonable time and frequency, see comment in the code. when called, `get_app_version()` iterates over all known profiles and relays and checks for version information, returning the newest for the given scope. we do not use an event, as that is tricky wrt changes - we do not know if other relays report later a newer version. we also do not cache anything, to prevent bad relays avoiding us to update permanently. also it is easier :) <details> <summary>outdated notes and questions</summary> - ~~it is up to the clients to get the needed information, we could let core filter, but it seems easy enough the other way round, and may have debug advantages, one can iterate etc.~~ EDIT: we now filter in core, this also makes the jsonrpc part easier, see review comments - when is IMAP METADATA actually read? when are they ready? is that really the correct place? i am up to change that, but beware, this is not really my expertise, so someone else may need to take over :) EDIT: see below, IMAP METADATA is read on connection, before fetching starts, usually fast enough - relay part is missing. once the format is settled and discussed shortly here, that should be done soon as well. but this is definitely not my expertise and needed to be done by someone else :) - key for IMAP METADATA is `/shared/vendor/deltachat/appversions` - shall we continue use `deltachat` for compatibility or so? `chatmail` seems to be more correct EDIT: we stay with the current </details> relay counterpart issue: chatmail/relay#1037 cc @link2xt @Hocuri @hpk42 --------- Co-authored-by: holger krekel <holger@merlinux.eu>

r10s · 2026-08-13T14:55:05Z

ftr, the core PR and relay PR are merged, and this PR should use the new API get_app_version("deltachat", "gplay"), returning an json as

{
    "versionInteger": 754,
    "versionString": "2.57.0",
    "downloadUrl": "https://github.com/deltachat/deltachat-android/releases/download/v2.57.0/deltachat-gplay-release-2.57.0.apk"
}

for testing: this is already deployed on nine.testrun.org, so faking a lower versionInteger should start the update flow (that should not be part of the PR, just mentioning that so one can test :)

wchen342 requested review from adbenitez and r10s August 3, 2026 18:09

adbenitez added the wait-for-core Issue/PR is waiting for core release label Aug 5, 2026

wchen342 force-pushed the wch423/app-update branch 2 times, most recently from 84725e2 to fc8e409 Compare August 6, 2026 18:29

wchen342 self-assigned this Aug 7, 2026

wchen342 added 2 commits August 10, 2026 15:35

Add simple update flow

8459c84

Add more details to the dialog

68774b6

r10s reviewed Aug 10, 2026

View reviewed changes

Comment thread src/main/AndroidManifest.xml Outdated

wchen342 force-pushed the wch423/app-update branch from fc8e409 to ea07f61 Compare August 10, 2026 18:34

- Make update message appear on single account

96582b5

- remove device message after update

wchen342 force-pushed the wch423/app-update branch from ea07f61 to 96582b5 Compare August 10, 2026 18:47

r10s mentioned this pull request Aug 10, 2026

feat: client version information chatmail/core#8557

Merged

link2xt reviewed Aug 12, 2026

View reviewed changes

Uh oh!

Uh oh!

Conversation

wchen342 commented Aug 3, 2026

Uh oh!

github-actions Bot commented Aug 3, 2026

Uh oh!

r10s commented Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wchen342 commented Aug 6, 2026

Uh oh!

adbenitez commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

r10s commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wchen342 commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

adbenitez commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wchen342 commented Aug 10, 2026

Uh oh!

github-actions Bot commented Aug 10, 2026

Uh oh!

adbenitez commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wchen342 commented Aug 10, 2026

Uh oh!

github-actions Bot commented Aug 10, 2026

Uh oh!

r10s commented Aug 10, 2026

Uh oh!

link2xt Aug 12, 2026

Choose a reason for hiding this comment

Uh oh!

r10s commented Aug 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

adbenitez commented Aug 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wchen342 commented Aug 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

r10s commented Aug 13, 2026

Uh oh!

r10s commented Aug 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

r10s commented Aug 5, 2026 •

edited

Loading

adbenitez commented Aug 10, 2026 •

edited

Loading

r10s commented Aug 10, 2026 •

edited

Loading

wchen342 commented Aug 10, 2026 •

edited

Loading

adbenitez commented Aug 10, 2026 •

edited

Loading

adbenitez commented Aug 10, 2026 •

edited

Loading

r10s commented Aug 13, 2026 •

edited

Loading

adbenitez commented Aug 13, 2026 •

edited

Loading

wchen342 commented Aug 13, 2026 •

edited

Loading