apk-reverse/references/updates-and-forced-upgrade.md

Updates and forced upgrade

Load this whenever the deliverable is a patched build that must keep working over time — which is almost always. A build that is correct on the day you ship it and dead a week later has failed, and the cause is nearly always an update path you did not neutralise.

This is the file that decides whether a patch is durable, and it is cheap: the whole job is usually one or two edits.

Why this is not optional

Three independent failure modes, all of which present as "the mod stopped working" with no obvious link to updates:

1. Forced upgrade. The app checks a version endpoint, sees a newer build, and blocks its UI behind a non-dismissible dialog until the user installs the official (unpatched) package. Your patch is gone.
2. Self-update install. The app downloads an APK and hands it to the package installer. Because the downloaded build is signed differently, the install either fails or — worse — succeeds and replaces your work.
3. Silent "compatibility" downgrade. The server decides the client version is too old and starts omitting fields or returning an error page. No local code changed, so nothing local looks broken.

A fourth case is a resource / hot-update channel: the app fetches a bundle (JS, a Dart/RN patch, a config blob, a plugin APK) that can reintroduce the behaviour you removed. That is a separate code path from version checking — handle it explicitly if the app has one (see §hot-update below).

Step 1: locate the check

There is usually exactly one update service. Find it before patching anything else.

From the client's own vocabulary (works on any runtime):

update / upgrade / new version / check version / force update
版本更新 / 检查更新 / 发现新版本 / 立即更新 / 强制更新

Search those in the app's string table and in class names; on heavy runtimes search the string pool, remembering its encoding (see framework-runtimes.md §string encoding — searching only one encoding misses half your hits, and "nothing found" is usually the encoding, not an absence).

Signals that a version check exists even if you cannot read the strings:

• A network call early in startup whose response contains a version number, a download URL, and sometimes a force / must / minimum flag.
• A stored "last update check time" preference (throttling a check implies one exists).
• The app ships the package installer path or requests REQUEST_INSTALL_PACKAGES.
• A permissions/manifest entry for an "unknown sources" install intent.

Also look for the coupling. Update checks are frequently run from the same startup routine as ad loading and splash dismissal, and a blocking update dialog often suspends those siblings — you may find logging that literally says so ("update dialog showing, skipping X"). That tells you both where the check lives and that your patch must not leave the dialog state machine half-finished.

Step 2: classify the shape

Shape	How it behaves	Where to cut
Optional update	a dismissible prompt with a download button	suppressing the dialog is enough
Forced update	non-dismissible; blocks the app	must be cut at the decision, not the dialog
Silent version gate	no dialog; features degrade or the server 400s	client-side is not fixable — see §the honest answer
Self-update installer	downloads and installs an APK	cut the check, and ideally the install path too
Hot-update / resource patch	fetches a bundle that can restore behaviour	separate route; treat as a data channel

Assume forced until you have evidence otherwise, because that is the case that costs the user the most when missed.

Step 3: patch the decision, not the dialog

Prefer the earliest safe exit over every downstream surface. Supressing the dialog only hides it; the download may still start, and a later code path may still act on the "new version" verdict.

Two layers, in this order:

Layer 1 — make the check itself a no-op. Replace the entry of the update routine so it returns immediately. Nothing is requested, nothing is compared, no dialog state is created. This is the root fix and it removes the network call entirely, which also makes verification trivial (Step 4).

Layer 2 — neutralise the comparison. Somewhere the client compares the server version against its own and branches on the result. Force that branch to the "already current" side. This catches any path that reaches the comparison without going through the entry you patched (a second caller, a manual "check for updates" button, a settings screen).

Layer 2 alone is a valid minimal fix if Layer 1 is awkward; Layer 1 alone is valid if you have confirmed a single entry. Doing both is cheap insurance and is what makes the claim "this build cannot be upgraded into uselessness" defensible.

target routine:  <updateChecker>(...)          -> return immediately (no request, no state)
target branch:   <versionCompare> result       -> force the "no update" side

Do not patch the dialog itself as your primary fix, and do not patch the comparison to lie in the other direction (claiming an update when there is none) — that produces exactly the blocking dialog you are trying to avoid.

What not to touch

• Do not rewrite the app's own version number in the manifest or in a version string. It is the cheapest-looking fix and it breaks things you are not looking at: server-side feature negotiation, analytics, cached asset keys, and the app's own self-comparison. Change the decision, not the identity.
• Do not strip the installer permission unless you have checked nothing else uses it.
• Do not block the update hostname at the transport layer. That is the same class of mistake as blocking ad hosts (pitfalls.md P5): it fails offline/online transitions, needs a helper on the machine, and is not a property of the artifact. It is also not required — the check is local code.

Step 4: verify

Update paths are checked once at launch, so verification is a single clean cold start:

1. Clear logs, cold start, and grep for the update vocabulary. Expect zero hits. Not "quieter" — absent. If the routine still runs, the string will still appear.
2. Watch the screen through startup. The failure mode is a modal, so a sample you did not look at is not evidence (environment.md §look at the screen). A blocking dialog is unmistakable and it will be on screen for a long time.
3. Check the network. With the check disabled there should be no request to the version/update endpoint at startup. This is the strongest signal: it distinguishes "dialog suppressed" from "check never happened".
4. Exercise the manual path if the app has a "check for updates" entry in settings — that is the caller Layer 2 exists for.
5. Confirm what you disabled is only updates. The update routine sometimes shares a bootstrap with other startup work. If you no-op'd a routine rather than its decision, verify that splash dismissal, first-run setup, and the ad/consent flow still complete.

Two-sample rule for the durability claim. If you are asked whether the build survives a server-side version bump, you cannot test that directly. What you can honestly claim is: (a) no version request is issued at startup, and (b) the comparison no longer reaches its "newer" branch. State it in those terms instead of asserting the future.

Step 5: hot-update and resource channels

If the app can fetch a bundle at runtime, version checking is not the only way your change can be undone.

• What to look for: a startup fetch of a signed bundle/zip/config with a version or hash, a local unpack directory, a dynamic plugin loader, or a JS/Dart/RN patch channel.
• Why it matters: even with updates disabled, a remotely fetched config can re-enable a feature, and a fetched bundle can overwrite patched logic in the parts it owns.
• Handle it like a data channel, not like an update: identify what is fetched, whether the patched behaviour is inside that payload, and cut the consumption point if it is. If the patched logic lives in the shipped artifact and the fetched payload cannot override it, say so and move on — that is a finding, not a gap.

Note the flip side: a server-issued configuration is the same category. If the thing you removed was driven by remote config, the client patch holds only while the server keeps sending that config — see references/ad-removal.md §server-driven and references/membership-and-limits.md for the general rule that client-side enforcement can be patched, server-side authority cannot.

The honest answer for silent version gates

If the app degrades because the server decides the client is too old — no local dialog, just missing data or errors on some screens — then there is no client-side fix. The only honest report is:

• the version the client reports to the server (with evidence of where it is read),
• the endpoint that makes the decision (with the observed response),
• and a clear statement that this is server-side authority.

Do not paper over it by forcing the version string at random read sites. If you do change a reported version as an experiment, label it experimental, and remember that a version number is used in more places than the one you are looking at.

Delivery note: always state what was disabled

Update suppression changes behaviour a user can observe ("it never tells me about new versions"). Put it in the delivery notes, in one line, together with anything else you neutralised. If the app also has a legitimate reason to update (security fixes), say that the build will not pick them up automatically.

Step 6: when the check is not where you expect

Three shapes that break the "find the Java comparison and flip it" plan. Recognise them early, because each has a different cheapest remedy.

The check is native

Symptom: you grep the whole dex tree for the version-comparison routine, the update endpoint, or the dialog text and find the method declared, and zero callers. A static native update entry point with no Java caller means the invocation lives in a .so (registerNatives from a static block is the usual giveaway — see code-virtualization-and-custom-linkers.md).

Options, cheapest first:

1. Attack the response, not the check. Block or rewrite the update endpoint at the network layer, or empty the version/config response. The native code still runs and still decides "no update". This needs no native work at all and survives a rebuild — check this before reaching for a disassembler.
2. Send the check a version it likes. If it compares against a value the app itself supplies (a config key, a stored preference, a build field), setting that value is a one-line change.
3. Patch the native comparison. Last, because it is the most expensive and the most fragile.

Do not conclude "unpatchable" from "no Java caller". The gate usually reads a value you can control.

The update hands off to a browser or a WebView

Very common in this category: the dialog's button fires an ACTION_VIEW intent at a download URL, or loads it in an in-app WebView. Two consequences:

• You will not find an installer call in the app, so searching for PackageInstaller, REQUEST_INSTALL_PACKAGES or a download service finds nothing. That is not evidence the dialog is harmless; the browser does the install.
• Logcat truncates the URL. ActivityTaskManager prints dat=https://host/... and elides the rest, so a naive grep gives you a host and no path. Do not build a plan on a truncated URL.

Ways to get the real URL, cheapest first:

Approach	Notes
Hook Intent construction / Context.startActivity and log intent.getDataString()	Most reliable. A truncated log line is a logging limit, not a limit on what you can read
dumpsys activity activities / recents while the browser is still in the stack	Free; works only if the activity is still alive
The browser's own history database (root)	Survives the browser being closed; needs the right DB, and modern browsers may encrypt or prune it
Read the update response instead	Often easier: the URL came from a JSON field you can fetch or hook directly

Deliberately tapping the button is a legitimate probe — but treat it as a measurement, not a side effect: capture the intent (or the screen) in the same window, and know that on some devices a second tap resumes an already-started download rather than re-issuing the intent.

The gate is server-issued with a local fallback

fetchEnabled()-style helpers frequently default to a local value on any failure (non-200, timeout, malformed body, signature mismatch). Two things follow:

• Read the failure branch before you touch anything. If failure ⇒ "no update" or "no ad", then merely making the request fail is a complete fix, and it is far cheaper and more robust than patching the comparison.
• The fallback also tells you how to test offline. Disconnect the device and relaunch: if the gate disappears, the fallback is benign and you have a zero-code workaround as well as a verification signal.

Conversely, if failure ⇒ "must update", failing the request makes things worse, and you must patch the decision instead.

Checklist

• Update vocabulary searched in both string encodings, in the right layer for the runtime
• The single update entry point identified (or its absence established, with evidence)
• Shape classified: optional / forced / silent / installer / hot-update
• Decision-level patch applied, not just the dialog
• Comparison branch neutralised as a second layer
• Manifest version and identity left alone
• Cold start: zero update log lines, no blocking modal, no version request on the wire
• Manual "check for updates" entry exercised
• Startup siblings (splash dismissal, ads, consent, first-run) still complete
• Hot-update / remote-config channel considered explicitly
• Delivery note states what is now disabled