[SiteRelEnby]

Backend PR #359 lets an announcement be aimed at particular clients, filtering on a ?platform= the client supplies. This is the Android side.

Naming ourselves

The filter is: untargeted announcements always, plus targeted ones whose list overlaps what the client named. A client that names nothing gets the untargeted set only. That is the right default for builds that predate this, but it means this app would silently never show an announcement written for it, with nothing anywhere saying why.

getAnnouncements() now sends ?platform=android - the same name the app already calls itself in its client header, and one of the four the server knows.

The default lives on the interface rather than at the call site, so a later caller cannot forget it.

Verified with a real request

Not by reading the annotation back. The platform is a Kotlin default argument on a Retrofit interface, which reaches the proxy through a synthetic method, and a default that failed to apply would look like nothing going wrong at all - no error, just an announcement that never arrives.

The test stands up a bare ServerSocket, makes the call, and asserts the request line is exactly GET /v1/announcements?platform=android. A socket rather than MockWebServer so it costs no new dependency; all it has to do is read one line and answer []. I checked it fails when the parameter is removed rather than trusting that a passing test proves something.

The admin half

Android's admin panel can already write announcements, so without this it could be targeted but not set targeting - and editing an announcement from the phone would have been the only way to touch one without seeing that it was aimed somewhere.

It now has a "Show on" section with the four platforms, a line saying who will see it, and a <platforms> only marker on targeted rows, matching the web admin page. Nothing ticked means everyone, which is both the server's default and what every existing announcement means.

The update path always sends the list rather than omitting it when empty. The server reads an omitted platforms as "leave it alone", so unticking every box had to put [] on the wire or the old targeting would quietly survive a save that looked like it removed it. That is pinned by a test, as is the inverse: an untouched targeting stays out of the patch entirely.

The watch

Deliberately not claimed. The Wear app is its own client and would name itself, so the phone collecting watch-targeted announcements on its behalf would be wrong.

The Wear app does not read announcements at all today, so an announcement aimed at watch currently reaches nobody. Not in scope here.

Tests

Six: the wire check above, the platform name being one the server accepts, platforms decoding, an absent platforms reading as "everyone" rather than "nobody" (the older-server case), [] reaching the wire on clear, and an untouched value being omitted.