v2.0.4

fix: start a pairing session knowing nothing about the last one

The notification that peeks over the pairing dialog sometimes did not come
down, and there was no pattern to it - waiting long enough would eventually
bring it back. Three things lined up to cause it.

AdbPortDiscovery keeps its last pairing port after stop() and clears it only
when mDNS reports the service gone, which does not reliably happen when the
dialog closes. begin() then seeded the session from that cache, and
addPairingPortListener hands a new listener the current value immediately -
so a session opened in READY, holding a port adbd had stopped listening on,
before the user had touched anything.

That spent the transition the alert is keyed on. When the real dialog opened
it announced a different port, the phase was already READY, and the service
saw no change worth interrupting for. The prompt arrived silently, over a
dialog it was supposed to peek above. It came back "after a while" whenever
the lost-service event finally landed and dropped the phase, letting the
next discovery count as an arrival.

The stale port was also what the code would have paired against, so this was
one bad attempt away from a failure with no explanation.

A session now clears discovery before starting. A dialog that is genuinely
open is rediscovered in seconds; a closed one is not, which is the right
answer either way. The alert is keyed on the port as well as the phase,
since every dialog gets a fresh one - a second dialog opened without the
phase dropping in between is still a new prompt worth peeking for.

Setup runs once, so its one bad run is the whole impression it leaves.

The toggle also breathes while it works. The first press after setup has to
bring wireless debugging up and wait for adbd to announce itself; a button
that dimmed and sat still read as frozen, and captions do not fix that -
they have to be read, and a still screen has already said "stuck".

Android 16: 9 checks, no failures. 57 unit tests. The stale-port sequence
cannot be staged here - it needs a real pairing dialog to advertise and then
withdraw an mDNS service - so that fix rests on the code, not on a repro.
The pulse could not be photographed either: the toggle completes in about a
second on the emulator, which is shorter than a screenshot round trip.

v2.0.3

fix: name Auto Blocker instead of sending the user to check Wi-Fi

The toggle failed with "무선 디버깅을 켤 수 없습니다. Wi-Fi 연결을 확인한 뒤
다시 시도해 주세요" on a phone whose Wi-Fi was fine. It was always going to
say something untrue there: the engine checks Wi-Fi at the top of the same
method and gives up if it is missing, so reaching that line proves Wi-Fi is
connected. The message contradicted what the code already knew, and cost
someone an afternoon looking in the wrong place.

What actually stops it, on a Galaxy, is 보안 위험 자동 차단 - Auto Blocker.
While it is on, wireless debugging cannot be enabled by anything, this app
included. It was invisible during development because it had been switched
off to allow sideloading in the first place.

That failure has its own type now, so the screen can put up a dialog with a
way to the setting rather than a toast telling the user to go and find it.
There is no documented action that opens Auto Blocker directly, so it opens
the security settings screen and the dialog says which row - a guessed
Samsung component name would resolve to nothing on the builds it guessed
wrong for.

The setup screen carries the same line under its steps. Auto Blocker stops a
first-time user at step 2, silently: the switch just refuses to stay on,
with nothing on screen to explain it, and the app looks broken.

Also fixed in the harness: the notification checks reported zero on a run
where the service had simply never started. It polled for the notification
but never asked for the service again, and start-foreground-service gets
dropped often enough on a loaded emulator that waiting was never going to
help. It reissues the start while it waits.

Android 16: 9 checks, no failures. 57 unit tests.

v2.0.2

build: publish releases to the public download repository

This repository is private now, and a private repository cannot distribute
anything: its release assets and its releases API both answer 404 without a
token, so the app's update check and the download page would both go blind.

The two things want opposite treatment. The source can be hidden. What
users install has to be reachable by anyone, without a credential - there
is nothing to put in an APK that cannot be read straight back out of it,
and a proxy in front of the asset would mean a token living at runtime and
a service to keep alive.

So the build stays here and the result goes to hojin-v/Shit-download, which
is public and already holds the download page. The only token involved is
RELEASE_TOKEN, and it exists only while the build runs.

The app follows the APK: UpdateCheck reads that repository's releases, and
the release page it offers as a fallback is one a user can actually open.

generate_release_notes had to go with it - it composes notes from the target
repository's history, which is now the download page's commits and says
nothing about the release. The tagged commit's own message is used instead,
which is where the reasons have been written all along. That needs the full
history, hence fetch-depth: 0.

Existing installs point at the old location and will not find this. One
manual install bridges it; after that the check works from the new one.

Android 16: 9 checks, no failures. 57 unit tests. Verified against the
now-empty download repository that the check logs HTTP 404 and carries on
without a banner or a crash, and that the page falls back to its own link
rather than showing a version it cannot confirm.