---
name: project-feedreader-apk-publishing
description: "Peter installs FeeDreader from static.terst.org, not from files I send — publish there on every build, or he silently reinstalls a stale APK and hits a Room downgrade crash"
metadata: 
  node_type: memory
  type: project
  originSessionId: 08c1f89c-4d24-4fb2-9488-0fe155872388
  modified: 2026-09-18T15:40:16.440Z
---

**Peter gets FeeDreader builds from `https://static.terst.org/files/feedreader-debug.apk`**
(on disk: `/site/static.terst.org/public/files/feedreader-debug.apk`), not from APKs sent in
chat. He treats that URL as "the latest build".

**Publish there whenever a new APK is produced.** Copy the debug APK over that path,
`chmod 644`, `chown root:root`. Keep a dated `.bak` of the previous one before overwriting.
Sending the file in chat as well is fine — see [[feedback_feedreader_apk_naming]] — but the
URL is what he actually uses.

**Why this matters (incident 2026-09-18):** the published APK had gone stale since 2026-07-24
while the repo moved on. He downloaded it, installed over his existing data, and the app
crashed on launch:

```
java.lang.IllegalStateException: A migration from 11 to 6 was required but not found
  at androidx.room.RoomOpenHelper.onDowngrade
```

The old APK's `@Database(version = 6)` cannot open an on-disk database at version 11. Room
has no downgrade path and `fallbackToDestructiveMigration` is deliberately NOT enabled in
`AppDatabase.kt` ("since this app already has real data"), so it **throws rather than wiping** —
user data survives intact, the app just refuses to start. Installing a current build over the
top fixes it with no uninstall and no data loss; verified end to end on the API 36 emulator.

**How to apply:** treat "crashes on launch after he installed a build" as a schema-downgrade
suspect first, and check the published APK's date against the repo before anything else.
Reproduce with: install current build → seed data → install the published APK over it →
`adb shell am start -W -n org.terst.feedreader/.ui.MainActivity`.

**Use `am start`, not `monkey`, to test launches on the emulator.** `monkey` gave false
"crashed" and false "launched" readings repeatedly in this session — it reported the foreground
activity as `com.android.settings/.spa.SpaActivity` and the app's pid came back empty even when
the process was healthy. `am start -W` plus a continuously-running `adb logcat -v threadtime`
capture (started *before* the launch) is the only combination that gave truthful results; the
`-b crash` buffer was empty even for a genuine FATAL EXCEPTION.

See [[project_feedreader]] and [[project_feedreader_emulator]].