Build the APK on GitHub, and survive a Telegram update

[2B-4G10]

CI that produces an installable APK, and making the hooks survive a Telegram release that moves things.

---

1. Build the APK on GitHub (0d9b93e)

There was no CI at all — gradle-publish.yml only fires on release: created, so nothing built on a push or a pull request. Every recent breakage was the kind a build job catches: the unsigned APK that would not install, the missing JUnit dependencies that failed gradle build, the toolchain disagreeing between JDK 17 and 25.

Adds Build APK on push to main, on pull requests, and on manual dispatch, so anyone can get an APK without a local Android SDK.

It builds debug as well as release, which is the point rather than an afterthought. The release signingConfig reads keystore.properties, and CI has no such file, so a release-only job would upload app-release-unsigned.apk — the exact artifact Android rejects with "App not installed". The debug variant is signed with the auto-generated debug key, so every run carries something installable. When the signing secrets (KEYSTORE_BASE64, KEYSTORE_PASSWORD, KEY_ALIAS, KEY_PASSWORD) are configured, the keystore is restored first and the release APK is signed properly instead.

Install instructions are written to $GITHUB_STEP_SUMMARY, so they appear on each run's own summary page with that build's file names, and the README gains a 📥 Download section pointing at the Actions tab.

---

2. Survive a Telegram update (c6ea417)

Hooks address Telegram by plain name — 74 classes, 172 method names — and official Telegram is not obfuscated, so that works right up until a client release moves something. Then the hook is skipped, the app behaves normally, and the only trace is one warning in a log nobody reads until a feature is visibly gone.

findMethodExact demanded an exact parameter-type match, and 52 hook sites pass no types at all, so they only matched a zero-arg method. Telegram adding one parameter killed the hook even though the method was still there.

Bend where bending is safe

findAndHookMethod falls back to XReflect#findMethodCompatibleIfExists when the exact signature is gone, and re-matches by name. The fallback only runs where the hook was already dead, so nothing that resolves today changes behaviour.

A parameter type that no longer resolves is now a wildcard rather than a failure: ClassLoad returns null for a renamed class, and resolveParameterTypes used to reject that outright and take down the whole hook even when the method itself was still present.

Refuse to guess — this is the actual design

A candidate is taken only when it is the single possibility:

Call site	Rule	Why
Passes parameter types	Arity must still match	Keeps the argument positions the callback indexes aligned
Passes none	Any unique signature is accepted	It was written against a no-arg method, so it provably cannot read param.args
Anything ambiguous	Refused	—

Attaching a privacy feature like HideSeen to the wrong overload is worse than that feature being off, because it would look like it works while still leaking. Constructors stay strict for the same reason.

Make the rest obvious

HookHealth reports how the hooks landed, as one line at startup:

hook health: 68 resolved, 2 drifted, 1 missing
  drifted (signature changed, hooked anyway): SharedConfig#setNewAppVersionAvailable
  missing methods (feature inactive): ChatActivity#processSentMessage

A bug report can then name the symbol that moved instead of "stories stopped working". Counts stay exact even when the printed list is capped.

Tests

XReflectDriftTest pins all of it down, because the value here is the refusals — someone later "simplifying" the matcher into a looser one would reintroduce exactly the failure mode this avoids. XReflect is plain reflection with no Android dependency, so these run on the JVM, and CI runs them before building the APK.

Also drops findMethodExact, which had no callers left once the hook path stopped using it.

---

3. Three fixes the workflow found in itself

The workflow ran against its own pull request, which exposed three defects worth keeping:

• 4524960 — builds were named after a commit that does not exist. A pull_request run checks out a synthetic merge of head into base, so git rev-parse HEAD named that, making an APK impossible to trace. Now named after the PR head commit.
• 03230cf — the test counts were invisible. Gradle prints nothing for a passing test task, and a task that finds zero tests succeeds in exactly the same silence — a bad property for a suite whose job is to stop the drift matcher being loosened. Counts now go to the job log as well as the summary, with pipefail so a parser error stays fatal.
• d292414 — the job had no timeout. A run wedged on testDebugUnitTest for 15 minutes having taken 68 seconds on the commit before; with no timeout declared it would have held a runner for GitHub's six-hour default while the PR never reported. Now 30 minutes for the job, 12 for the tests so a wedge is named as such.

---

What this does not do

This does not make the module work on all Telegram versions, and nothing can:

• A renamed method or class cannot be found. Nothing identifies the replacement; that feature stays dead until the name is updated by hand.
• Ambiguous or reordered signatures are left alone on purpose, per the table above.
• The obfuscated forks (Nekogram, Cherrygram) still need their R8 mapping tables regenerated from the target APK per client release. None of this helps there.

Both limits are written into the README under "Surviving Telegram updates".

Test plan

• The project compiles. assembleDebug and assembleRelease both green in CI. generateDexHolder embedded a 2.4 MB classes.dex; zero javac errors or warnings.
• XReflectDriftTest runs in CI, proven from the job log rather than inferred from a green tick: 12 run, 0 failed, 0 skipped, naming com.my.televip.reflect.XReflectDriftTest. Also 11/11 locally against junit 4.13.2.
• Both APKs upload, named after the head commit, with the install instructions rendered on the run summary and the release APK correctly reported as unsigned (no secrets configured).
• Not verified: runtime behaviour on a device. Nothing here has been run against a real Telegram client.
  • Startup log on a current client should read hook health: N resolved, 0 drifted, 0 missing — on a matching client the fallback should not engage at all.
  • Sanity-check that an existing feature still behaves, and that the debug APK installs and loads under LSPosed 1.10+ / Vector 2.2.